If a standalone client defines a couple of connections, nevertheless whether the approach use the jboss-ejb-client.properties, the JBoss EJBClientContext API or the scoped-context, all connections are established before the client business code continue. This might take unnecessary long in some environments. Reduce the connection timeout might not be an option, in that case it happen sporadical that the connection is not established due to latency. There are two major use-cases: - need to establish named connections i.e. defined remote.connections=one,two,three,four to start the business at minimum one and three are needed - need to have at least one established connection The initialization should be improved - by having properties to allow such lazy named or unnamed initialisation - by initialising all connections in parallel to reduce the wait time in total
jaikiran pai <jpai> made a comment on jira EJBCLIENT-82 A pull request containing an implementation for this has been issued. The pull request adds the feature where a user can configure a particular (or all) connection configurations to be marked as lazy (or eager). By default, connections listed in the configuration will be created eagerly like before. However, users can use the following property style to mark a particular connection to be lazy: {code} # This marks the connection named "connection-name" to be connected lazily remote.connection.<connection-name>.connect.eager=false {code} Furthermore, all connections listed can be defaulted to lazy by using: {code} # All listed connection configurations will by default be lazily connected due to this property remote.connections.connect.eager=false {code} The *.connect.eager property accepts a value of either true or false.
Assigning jpai EJB issues to david.lloyd. Please re-assign to Cheng or others as needed.
backport to 1.0.x branch https://github.com/jbossas/jboss-ejb-client/pull/125
PR merged in 1.0.x https://github.com/jbossas/jboss-ejb-client/commit/75a882b32b8d9c3705c0e29ba5d32cfd25e4a00b
Verified with EAP 6.4.5.CR1.
Retroactively bulk-closing issues from released EAP 6.4 cumulative patches.