Red Hat Bugzilla – Bug 976654
[GSS](6.4.z) Slow startup of standalone ejb-clients if not all defined server-connections are available
Last modified: 2017-01-17 06:46:51 EST
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 <firstname.lastname@example.org> 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:
# This marks the connection named "connection-name" to be connected lazily
Furthermore, all connections listed can be defaulted to lazy by using:
# All listed connection configurations will by default be lazily connected due to this property
The *.connect.eager property accepts a value of either true or false.
Assigning email@example.com EJB issues to firstname.lastname@example.org. Please re-assign to Cheng or others as needed.
backport to 1.0.x branch
PR merged in 1.0.x
Verified with EAP 6.4.5.CR1.
Retroactively bulk-closing issues from released EAP 6.4 cumulative patches.