Ramesh wrote:
> Binod,
> In the stop () method of the inboundresourcepool , if there are
> connections in use then we wait for the timeout duration ( configured
> in spec now) or until the resource is returned back to the pool (
> whichever happens first). All would be fine if the resource is put
> back to the pool before the timeout ends, but if we timeout, then we
> proceed with releasing the resource though it still maybe in use ( or
> blocked).
>
> Right now, what we can do is before calling destroy on a resource , we
> can add a check to see if the resource is free ( or busy), if its free
> then we can call destroy, if its busy ( we will encounter a busy
> resource definitely if the connectionsInuse >0), then we have to
> decide on what we do with it, because in all probability the
> afterDelivery would through an exception ( just like the one we are
> seeing), we can just ignore this exception and continue, Well, we
> tried out best by waiting for the timeout interval but still if it
> cannot be released then we just leave it there and bring the pool back
> to a saneful state.
destroying our serversession implementation contains two things.
1. Destroy the JMS provider part (i.e close the session).
2. do afterDelivery etc.
I think, we should (atleast attempt to) close the session. afterDelivery
may not be required
as we know (by now, as timeout exceeded) that transaction related to MDB
is anyway stuck.
> I dont think a per-resource timeout will help our situation any better
> because , its better the current way where we are giving all the
> resources 180 ( or whatever is configured) seconds to get end
> sanefully rather than give each one around 10 seconds.
Looked at the logic completely now... You are right. The current logic
seems fine.
Look like all we need to do is to make the timeout configurable and do a
little stricter
exception handling.
thanks,
- Binod.
>
> Please let me know your thought, i will fix it accordingly
>
>
> Thanks
> - Ramesh