On Wed, 9 Dec 2020 at 16:37, akabhishek1
<mailbox.abhishek.ku...@gmail.com> wrote:
>
> Hi Robbie,
>
> Thanks a lot for details insight and correction. Test case is working fine
> now with 0.56-SNAPSHOT.
> I am able to generate invalid message which continously throw 'Cannot decode
> String in UTF-8' error.
>
> The good thing is - I am able to generate "Suspected deadlocked threads"
> error repeatedly with Old(0.45.o) jar. I used invalid message .
>
> Steps to generate error - I need to do enable/disable queue and WiFI ON/OFF
> couple of times to get this error. I have not found consistent pattern yet,
> but couple of retries helps to generate this error.
>
> I did similar testing with New "0.56.0-SNAPSHOT" jar. Unfortunatelly I am
> getting same "Suspected deadlocked threads" error with new jar.
>
No, you are actually getting a fairly different scenario this time.
Previously the deadlock involved locks in your application and a
delivery lock within the client, which was being held when firing the
exception listener, and is also needed to close things down. We
removed that client lock from being in play here, which your result
shows is the case; your new result only involves locks outside the
client, within your application, but now being acquired in different
orders. By pairing the invalid message causing failure before
onMessage (which is really quite unexpected) with disconnecting the
actual connection in full, I think you managed to get multiple calls
to the exception listener. In those your handling then acquires these
application locks in different orders and thus upon which it can then
deadlock.
If your reaction to the ExceptionListener firing is always to close
the connection and reconnect, I would suggest that you use an
AtomicBoolean as a gate within your handler (which per previous mail,
should ensure it only operates on a single connection) such that only
a single attempt can be made to clear up and reconnect, thereby
removing the chance for your locks to be acquired in different orders,
e.g:
if (exceptionFired.compareAndSet(false, true)) {
// Do cleanup work
}
> Can you please check attached thread dump
> "ThreadDumps_Deadlock_56-SNAPSHOT.txt", if you find anything from your side.
>
> ThreadDumps_Deadlock_56-SNAPSHOT.txt
> <http://qpid.2158936.n2.nabble.com/file/t396358/ThreadDumps_Deadlock_56-SNAPSHOT.txt>
>
> I am also trying to find root cause from my side.
>
> Regrads,
> Abhishek Kumar
>
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
