I want to clarify something you said to be sure I understand.
You have instrumented your client and EJB code to display timestamps so you know when your EJB returns on the server side and when you client regains control after the return from the remote EJB call, is that right?
As you alluded to, there is a lot of "plumbing" between the return in your EJB on the server and the return to your client. A good first step will be to find out whether the delay actually occurs on the server side or on the client side or some of each.
One thing you could try: Capture thread dumps from the server and the client during the delay if you can catch it right then. That will shed some more light on exactly what each side is doing. Another possibility: Use a network sniffer such as WireShark or some equivalent to track exactly when network messages are leaving and arriving at each end.
Once the app client is running the app client container (ACC) itself is largely out of the picture, although various services (security, transactions, remote EJB calls via the ORB, queue access, etc.) continue to be very much in the picture.
If you are able to narrow this down to a small section of logic, as you described you're in the process of doing, that will help quite a bit as well.
Thanks for your continuing detective work on this.
- Tim
[Message sent by forum member 'tjquinn' (tjquinn)]
http://forums.java.net/jive/thread.jspa?messageID=340053