This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes EJB and other Java EE Technologies and the fly likes how to identify the calling server instance Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "how to identify the calling server instance" Watch "how to identify the calling server instance" New topic
Author

how to identify the calling server instance

Mahesh Bhatt
Ranch Hand

Joined: Sep 15, 2004
Posts: 88
We have a cluster C1 of servers A, B, and C and a cluster C2 of servers X, and Y. If a clustered bean from server B calls a method M1 on a clustered bean on cluster C2. Now from the code in method M1, we want to print the server name from where this call was made. In this example, it should print that the call was made from server B. Which API can we use to get the name of the calling server?


Impossible is I M Possible
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Hi prashant,

This is a pretty original request and probably not many people really tried something like that in practice. I�m no exception though and I cannot give you a straight answer, but if you�d allow me I�d try to explain you my reasons why I believe that you can�t. First of all your EJBs in the cluster A use cluster-aware RMI stubs in order to invoke remotely beans residing in Cluster B. These cluster-aware stubs maintain a list of all available server instances in the cluster B ant they also implement the load balancing algorithm used for redirecting requests to the next available server instance (in the cluster B). Notice that the beans in cluster A cannot control or predict to which server instance (in the cluster B) they will be sending the next RMI request. From the target beans� perspective they might only have access to information that the RMI protocol provides. Hence they are capable of retrieving input parameters (after demarshalling) and they could retrieve all information regarding the clients request within the boundaries that the RMI protocol provides. And here there is my bet: for performance reasons I believe that RMI protocol doesn�t send any address related information over the network. I guess that RMI is minimizing the network traffic as much as possible. Hence I�m not sure if you can get the ip address of the server sending the request, but I might be wrong though. I guess you have to look into RMI little bit deeper. Even worse, assuming the information is sent over the network, your bean should have access to its own stub in order to get it. I really don't believe that your container vendor will allow you that.
Ultimately you might think about implement an ad-hoc solution, passing the ip address as an input parameter from beans in cluster A to the beans in cluster B, but from a designing perspective this will be against all odds. You can also implement an audit process that logs specific client information (probably using an underlying database) and have the target bean receiving these information, but this might be too complex and will raise performance issues as well. Again these are just my thoughts and I hope that I gave you an idea about the beast you�re wrestling with here :-)
Regards.


I think, therefore I exist -- Rene Descartes
Mahesh Bhatt
Ranch Hand

Joined: Sep 15, 2004
Posts: 88
Yes, I think it is a major issue. Anyways thanks a lot for the details.
I really appreciate the help.

Regards
Prashant
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
You're very welcome prashant.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: how to identify the calling server instance
 
Similar Threads
lookup bean on one server in cluster
Stateless EJB and Cluster Problem in weblogic 9.2
overloading vs overriding
OverLoading && Overrriding confused with output
Objects available for GC..