-
Notifications
You must be signed in to change notification settings - Fork 128
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
Trying to publish a message inside the 'connected' signal fails on reconnect. #41
Comments
@alaendle sorry, was on vacation! hmm this does indeed look like a bug, I'll try to repro on my end here and see what's going on. |
@alaendle can you post your whole code here? It looks like you're never declaring the exchange? |
@alaendle ah, I think I understand your issue. Yeah it looks like there is currently a problem if you try publishing when not properly connected. I wonder if maybe you'd be interested in helping out with this feature? The exchange would have to maintain an internal list of pending messages to send, which would be published upon connection and the channel being established. |
@alaendle so I took a first stab at supporting pending sends on this branch. The work is incomplete because of other issues I uncovered with certain reconnect scenarios, but the code there does indeed resend the data on reconnect, solving your problem. I won't have time for this for a few days, but I'll try to get around to completely fixing the issue. |
@mbroadst please excuse the late response, was also on vocation. Will take a look at your work now... |
I still have a problem in my original scenario. If I just shutdown and restart rabbitmq (v3.6.1) I couldn't publish messages after reconnecting... the opened flag never switches back to 'true', because channel#openOk is never received. The new log...
|
The problem seems to have its cause in the fact that during reconnect the channel numbers change - so the maps pointing to the frame handler methods (in this case QAmqpClientPrivate::methodHandlersByChannel) are no longer correct. So two solutions come to my mind - a) don't change channel numbers, b) don't rely on channel numbers while looking for registered handlers. I did a short proof-of-concept implementation of b) and it seems to work - but for sure this isn't a fully fledged solution to the problem...
|
@alaendle are you using the code in that branch or the code in master? The issue initially with the code in master is that As for |
@mbroadst Don't want to stress you, for sure we could/should improve the behaviour step-by-step. I just played around with the code in the 'pending-sends' branch and thought it might help to update this issue with the 'new' behaviour I've experienced. Also I'm aware about what it takes to maintain an open-source project over years - so let me take this chance, to just thank you for sharing the code and your support. |
If I create a simple sender that just publishes a message on 'connected' it fails during re-connecting. Just take a look at the following sample (a small modification of the sender-example):
If I now restart the broker the client tries to publish before a channel is established:
For me it seems like this is a bug, but maybe I'm just making wrong assumptions about the API of qampq. If I was unclear or if you need more information just let me know. Thanks in advance for any assistance or any hint how to work around this problem.
The text was updated successfully, but these errors were encountered: