-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sent message never receives DISPOSITION #270
Comments
There should be no differences in encoding and handling settles between Windows/OSx. The code actually is the same at uAMQP level. Windows uses SChannel for TLS. Also it uses WinSock for socket APIs. openssl can be tested also on Windows with a bit of a headache. There is an option in C shared (use_openssl I believe) which will let you use openssl on Windows. It requires an env var with the path where openssl headers and lib exists and then it would allow debugging with openssl on Windows. However before investing in any of that, can you get a full log on Windows and OSx so we can compare? Cheers, |
Thanks @dcristoloveanu! I also thought it must be related to the OpenSSL TLS layer - however that wouldn't explain why I can run it successfully on Debian, which also uses OpenSSL (unless it has something to do with running debian from a docker container on Windows). The payload in both cases is a single message of 256000 characters. My Windows output looks like the following:
I will edit this post to add the OSX output as soon as I get home to my Mac :) |
Okay, here is the output from my Mac. Notice that after the TRANSFER frames, nothing further is received however the client continues to poll the connection which, after 2 minutes or so, sends an empty frame to keep the connection alive - this in turn seems to reveal that the connection is in fact in an invalid state which initiates a client shutdown.
|
PR merged, closing. |
This issue isn't related to the PR :) |
Oops, not intentional :-) |
Hi @dcristoloveanu
I'm seeing some interesting behaviour I'm hoping you may have some insight into.
My understanding is that max supported messages size is 256kb (maybe this depends on a service).
By default I configure my session/links with the max message and window size - and I have run tests that send a 256kb payload in a message successfully on Windows and Debian. In the logs, I can see the payload divided into 4 frames, followed by the response disposition like so:
However when I run the same code on OSX (and, according to user report, Ubuntu as well), the message appears to transfer without any error, however never receives a DISPOSITION frame. This happens to any message over about 128kb in size. My code simply continues to poll the connection indefinitely. No other errors/warnings are logged. I inspected the wire-encoded message on both Windows and OSX and can see no apparent difference between them.
I am going to test the same scenario on another service (this was first seen when sending to Event Hubs, I will now test against Service Bus). I will also contact the service teams to check whether they have any logs to indicate whether the message was ever even received.
But in the meantime if you know of anything I can check, or any thoughts as to what might cause this that would be fantastic.
Thanks!
The text was updated successfully, but these errors were encountered: