-
Notifications
You must be signed in to change notification settings - Fork 54
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
context deadline exceeded #193
Comments
python simple_recv.py -a 127.0.0.1:5672/examples -m 5 these simple python programs works with same router configuration. |
When we are separating the above go program to sender and receiver, it works fine. |
@jhendrixMSFT Any pointers? |
Your program looks fine, i.e. nothing obvious as to why |
@jhendrixMSFT |
Separated sender and receiver logs router-n2r5m:/amqp # ./amqp-send |
sender.go
recv.go
|
Thanks for the info. From the logs, I assume this is the separated sender/receiver which works fine, yes? I see that the sender sends the transfer frame and receives a disposition frame, indicating that the peer accepted the transfer and is now settled. If you can consistently repro the failure case, can you please send the debug log for that? At this point I see no clear reason why the sender would time out. |
@jhendrixMSFT see this comment |
Thanks, I completely overlooked that. From that log, the sending link never received a flow frame from the peer during attach. The flow frame includes the available link credit of the peer, and until credit has been issued, the sender is not allowed to send any message. For whatever reason, the peer never sends a flow frame, so the sender's context times out (in the success case, you can see that the sender received a flow frame indicating that the peer has 250 link credit). How can I install the necessary broker to repro this? I can't repro it using the .NET broker or ActiveMQ 5.16.3. |
@jhendrixMSFT 2022-11-16 04:19:42.169325 +0000 SERVER (info) [C5] Accepted connection to 0.0.0.0:amqp from 127.0.0.1:42088 |
To get the docker image then we can put a go compiler, and test code inside docker. |
According to the spec, a Is there any way to dump the complete frame data, or maybe use some other tool to capture the network traffic? One other thing to try first, can you add |
Also, your use of qpid-dispatch makes me wonder if this is related to #135 which also reports problems when running under qpid-dispatch. |
logs : router-n2r5m:/amqp # |
Thanks for trying, was skeptical it would help but was a simple test. |
Thanks for the trace. I'm currently at a loss to explain the behavior. You can see the proper flow of AMQP frames, just like in the text logs. Four seconds later, an empty keep-alive frame is sent (as expected). At five seconds you can see the beginnings of closing the TCP connection, presumably due to the context timing out and the app exiting (I assume this is where the framing error is coming from, but not 100% sure yet). |
The Python example you cited runs the sender and receiver separately? |
Yes those python examples are from qpid-proton and those run separately. |
I've been rereading the investigation thus far and there are a few points that don't add up which makes me wonder if there's another piece to the puzzle that we're overlooking. Earlier you mentioned that "through another program I can able to see the data reaching the other side" (I assume this is the "Hello!" message). When you reran the test with debug logging enabled (this one), did you still see data reaching the other side? If so then I can only guess that the data is coming from elsewhere as there was no transfer frame sent in that log, i.e. there would be an entry that contains "TX(link): Transfer". |
the whole problem started from here redhat-cne/cloud-event-proxy#150 |
In the sample program, it's just the one sender program talking to the qpid-dispatcher? What's on the receiving side of the dispatcher? |
This is the sample program, nothing else. |
This example is direct copy of go-amqp example. |
you should be able to reproduce the problem by creating qpid docker container which I mentioned earlier, and then running this sample program. |
IS this sample program correct? sender is waiting in a single thread to to send, before the receiver who gives link credits. I am able to reproduce the same problem with separate receiver and sender, by giving zero credits during attach. |
This SDK only supports the creation of AMQP clients. You can't send a message to "yourself" using this SDK. When you create a client, it must connect to a broker process (ActiveMQ, Azure Service Bus/Event Hubs, etc). Please see the conceptual model in the spec for more info on this. |
To clarify the above, if qpid-dispatcher removes the need for a dedicated broker (I skimmed some of the docs but know very little about it), then you are correct that you can't have the sender and receiver on the same goroutine. |
Closing as I believe we've found the solution. Please ping back if I'm mistaken. |
Env:
When we are running the sample program
amqp://router.router.svc.cluster.local is the qpid kubernetes service with "internalTrafficPolicy: Local"
root@cp-baremetal-ptpstack-1:/go/src/github.com/redhat-cne/amqptest# ./amqp-test
2022/11/11 07:26:50 Sending message:awaiting send: context deadline exceeded
root@cp-baremetal-ptpstack-1:/go/src/github.com/redhat-cne/amqptest#
Here test program is running in a pod and qpid-dispatcher router also running in another pod in same node.
test amqp-client/server will be directly connected to qpid router.
Router configuration is
through another program I can able to see the data reaching the other side, bi-directional data exchange is happening, but send() returns context deadline exceeded. Any idea why this happens?
I tried with newer versions of go-amqp, but same error.
The text was updated successfully, but these errors were encountered: