[
https://issues.apache.org/jira/browse/OPENEJB-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevan Miller resolved OPENEJB-1239.
-----------------------------------
Resolution: Fixed
Committed revision 918990.
We'll now discard a connection on any IOException. We could be a bit more
fine-grained in our retry logic. If a write operation fails prior to writing an
entire message, we could add automatic retry logic (that isn't conditional).
The whole message would never be sent. So, there's no chance that the server
would have actually processed the invocation.
However, this error occurred on final flush. So, depending on the underlying
socket implementation, the entire message could have been sent -- we've written
the data to the outputstream, so it's out of our hands. And thus a retry might
perform a duplicate operation.
Tests look good for me.
> Bad client connection is never getting discarded from pool
> ----------------------------------------------------------
>
> Key: OPENEJB-1239
> URL: https://issues.apache.org/jira/browse/OPENEJB-1239
> Project: OpenEJB
> Issue Type: Bug
> Affects Versions: 3.1.x
> Reporter: Kevan Miller
> Assignee: Kevan Miller
> Fix For: 3.1.3
>
>
> If I lookup a Stateless Session bean and invoke a method from a long running
> client then kill the server, a subsequent invocation by the client fails
> (Client.java gets an error flushing the OutputStream. However, if I then
> restart the server, the client keeps grabbing the stale connection (which is
> not removed from the pool). The connection remains in the pool for some
> amount of time. But does eventually get cleaned up (after a socket timout
> period, I suppose).
> When the server is down, the Client receives an IOException for the flush at
> line 162. We handle the error, but as long as retry is false, the connection
> will not be removed from the pool. write() operations on the OutputStream are
> not failing. Good chance that this behavior is environmental. So, on
> different OS's (this test is on Windows), we may see a different error that
> is cleaning up the connection.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
