| Summary: | A client fails to receive replies from reconnected server instances | ||
|---|---|---|---|
| Product: | JacORB | Reporter: | Matej Sekoranja <matej.sekoranja> |
| Component: | ORB | Assignee: | Mailinglist to track bugs <jacorb-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | acaproni, hsommer, jacorb, joseph.h.schwarz, matej.sekoranja |
| Priority: | P5 | ||
| Version: | 3.4 | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: | Client/server code that demonstrates the problem. | ||
Thanks for the report (and excellent test case). As a workaround could you try setting jacorb.connection.client.disconnect_after_systemexception=false ? (In reply to Nick Cross from comment #1) > Thanks for the report (and excellent test case). As a workaround could you > try setting jacorb.connection.client.disconnect_after_systemexception=false ? The workaround works. Thank you. What's the downside of this workaround? "Memory leak" since the connections are kept in a cache forever? The connection will be held open by the delegate until it is released (i.e. call _release()). I'll look into solving this for the next release. I think the Delegate will need to handle the closed transport better. Fixed by SHA f4610e63a46a50f614cade893c546af466694001 |
Created attachment 429 [details] Client/server code that demonstrates the problem. A PERSISTENT, USER_ID POA configured server that runs on a fixed port causes a reconnection failure to the clients. In fact clients do reconnect and send a request the server, however they are unable to receive any responses. This can be reproduced deterministically on 3.4. Version 2.2.4 does not suffer from this problem. Only client side is affected (running 2.2.4 client against 3.4 sever works). I've created a simple isolated code that shows the problem with detailed instructions in README (attached). In short: 1. Start a server. 2. Start a client. 3. A client sends a request to the server, gets response back. Waits until you press ENTER key. 4. While the client is waiting, you restart the server. 5. Press ENTER key. 6. The client sends a request to the server, the server receives it. 7. Client gets no response back (blocks). ----- Detailed analysis: When the server shuts down the client detects a connection loos, however it keeps a connection objects in a ClientConnectionManager connection pool; meanwhile the server gets restarted. When the client tries to invoke an two-way operation on the server, it founds an instance in its ClientConnectionManager connection pool. It checks the connection status, detects it's not connected, successfully reconnects and sends a request to the server. However, a receiver task (MessageReceiver) is not restarted what makes the client unable to receive any responses from the server.