tomee-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevan Miller (JIRA)" <>
Subject [jira] Resolved: (OPENEJB-1239) Bad client connection is never getting discarded from pool
Date Thu, 04 Mar 2010 14:19:27 GMT


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:
>             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 ( 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.

View raw message