You need to have all this if you follow this approach.If you are on the same server you might not have to create the user.
A different approach is to use the scoped-context.
You will find an example here jboss-eap-quickstarts/ejb-multi-server at master · jboss-developer/jboss-eap-quickstarts · GitHub
Have a look to the main-app which call the other applications with different approaches.
Thanks for the link. I certainly learned a great deal from your quick start - thanks.
I examined the quick start in some detail and I'm a little confused on what actually happens when I do a JNDI lookup?
As you know, the web application references two outbound connections: remote-connection-war-ejb-1, and remote-connection-war-ejb-2.
It seems that each outbound connection is ultimately tied to a specific remote port, which implies a specific server?
However the JNDI name references the enterprise application (which is deployed to all the servers in the server-group).
So the question is what actually happens when I perform the lookup? Are the outbound ports used as part of the lookup process, and does that mean only the servers for those particular ports will be considered? What happens when the EJB is in a cluster? The comments say "a list of members is provided after successful connection" ?
1 of 1 people found this helpful
Inside the application archive you will have a jboss-ejb-client.xml (a EJB server application). A standalone client use *.properties
The EJBClientContext will hold connections to the servers specified by the different outbound-connections (or even the properties file connections).
If you do a lookup only the proxy class is instanciated, there is no server action (therefor you did not know whether a server is available to handle this specific ejb).
Now, if you invoke a method, the EJBCLientContext will check which server is able to handle this invocation and pass the invocation to that server
- if there is no server you will see a IllegaleState (EJBCLIENT000025) now
- if there is a cluster for that EJB you will receive a cluster-view from that server (for the following invocations), the context will start async to create connections to that servers
So if I am understanding this correctly, at the point of method invocation, the EJBClientContext will query each remote port in turn to establish which one is able to handle the invocation. I am guessing that the first successful response wins, and (I am hoping) that this mechanism is not needed upon subsequent method calls (I.e. there is some client-side caching).
In the case of your example, I am thinking that in the non-clustered case, only one of the servers will ever be queried (app-twoA) because the port of the other server is not in the list (app-twoB).
In the clustered case, I am guessing that the client will query the one node first (because that is the only node the client knows about - hopefully it is up), which will return information about other nodes in the cluster? It is not clear how this information is used (is there any concept of load distribution?)
Let me know if I am misunderstanding something. Thanks!
1 of 1 people found this helpful
This is correct so far.
The client decide according the the lookup name which server is able to handle the request and it will be known at client side for further invocations.
A clustered server will send the other members back to the client and the default is a RandomRobin balancing, there is a bit client side configuration for that.