On Thu, 3 Dec 2020 at 18:36, akabhishek1 <[email protected]> wrote: > > Hi Robbie, > > Thanks for quick reply. I referenced your test case and tried to generate > "Illegal invocation from MessageListener callback" error. > At this moment, I am not able to generate this error neither "Suspected > deadlocked threads" error. > > So, I can't confirm that this fix is working or not. > > Please find attached sample test class ConnectionTest.java > <http://qpid.2158936.n2.nabble.com/file/t396358/ConnectionTest.java> . I > tested with both library "45.0" and "0.56.0-SNAPSHOT", And test cases are > failing for both jar versions. > So definitely, I am missing something .
A few things. You are trying to use the same invalid-payload my test uses, but you are in fact sending something that is very different and perfectly valid, so it presumably won't generate the TextMessage decode failure, and be successfully received, failing the test. When you send a BytesMessage with the client it is annotated as such, and will always be treated as a BytesMessage on receipt, so that payload is perfectly valid then. The client cant generate the exact payload I used in my test. You might be able to directly replace the body Section on the text message facade with some reflection to get closer to the same payload. You could also do what I said in my earlier mail and use larger multi-frame messages with unicode characters. You could even reduce the connections maxFrameSize to lower the threshold for multiple frames being required to receive a message, causing more frames and increasing the chance of the cross-frame decode issue in the old client. The newer proton-j used in the new client wont throw that failure though and so wont cause the delivery failure, you would have to use dependency management to downgrade the new client to use e.g 0.33.7. You look to be trying to perform essentially exactly the same test I did. If you succeed it should of course give the same result. I was expecting you to test what you are doing when you see the error, having encountered two different ways of doing so. You will certainly never reproduce the deadlock with the test as it only has 1 connection/session rather than 2+ needed, and has no application-level lock for them to compete over before trying to close the others and form the block. (It won't matter here, but I also noticed you have a somewhat amusing and contradictory set of URI options: "&jms.forceSyncSend=true&jms.forceAsyncSend=true"...sync wins due to the impl). > > Is that possible for you to suggest correction in attached > "ConnectionTest.java" ? So I can generate error and proceed further for > testing. > > Regarding last reported 3 issues - I will try to replicate these issues in > independent project and share details with you. I dont see a need. The second of your points isn't an issue at all and your expectation was simply wrong, again likely in large part due to the misleading error description used by Service Bus. The others are server side behaviours. > As we are upgrading library, so we want to make sure that existing(0.45.0) > positive functionalities should match with latest jar (0.56.SNAPSHOT). > > > Regards, > Abhishek Kumar > > > > > -- > Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
