Have a look into the JBoss source code
This might solve your problem :-)
i've done this before an uncommented this interceptor. Unfortunately is this interceptor not working correct. I've created an entry in the bug database with the result, that this interceptor was implemented in a dirty way and will be removed in future versions. So this is no solution for us.
Adrian Brock commented on JBAS-1626:
I disagreed with this interceptor when it was first written
but let it pass because it is not enabled by default.
It was put there by the guy (who now works on ActriveMQ)
that wrote the buggy ILs that couldn't detect that a client crashed.
We no longer use those ILs.
It is a big security concern (to me) that one client can hijack another
client's subscription. It is certainly not spec compliant.
If you are telling me it does not work, I am more likely to delete it
than fix it.
There are no tests for this behaviour in the testsuite.
So unless you can provide a fix yourself, I am going to close
this as "Won't Fix" and remove the interceptor from the codebase.
We are also experiencing the same problem, using HTTPIL in jboss-3.2.3. So I suspect that invocation layer is still 'buggy'?
I am hesitating to install this ClientReconnectInterceptor, because of the change in semantics.
My new question is : would a ClientMonitorInterceptor also work? The idea is that this interceptor would close the stale connection (the connection won't be used because the client side has thrown away it's side). And thus recovering the client id.