Skip to content
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

Support RECEIPT for SUBSCRIBE operations #40

Open
rp42 opened this issue Dec 13, 2017 · 6 comments
Open

Support RECEIPT for SUBSCRIBE operations #40

rp42 opened this issue Dec 13, 2017 · 6 comments

Comments

@rp42
Copy link

rp42 commented Dec 13, 2017

As far as I can tell go-stomp doesn't support receipts for subscribe operations. I haven't seen a SubscribeOpt for this. When I manually add the header using stomp.SubscribeOpt.Header, I do see a RECEIPT from from the server, but this looks to close the Subscription's channel in go-stomp.

I'm working with a system where you subscribe to a topic and then trigger an operation that posts messages to the topic. Unless I add a sleep in, I can lose the initial messages that are posted.

@worg
Copy link
Collaborator

worg commented Dec 14, 2017

@rp42 Do you have an example using the receipt SubscribeOpt.Header?

@rp42
Copy link
Author

rp42 commented Dec 15, 2017

Here you go:
main.go.gz

The subscription channel gets closed when go-stomp receives the subscription receipt from what I can work out, so there is no way of receiving the messages from the subscription. If I remove the header then the subscription works ok, but doesn't wait for the server to process the subscribe frame.

@c-bg
Copy link

c-bg commented Jul 22, 2019

At the developers, thanks a lot for this nice library.
I have exactly the same problem as reported by @rp42 . @rp42 , could you tell me how you solved this problem in the end?
Thanks a lot for your help in advance.

@rp42
Copy link
Author

rp42 commented Jul 22, 2019

It was a while ago now, but I think we stuck with using a time delay to ensure that the message had been processed by the server. This was acceptable for our real world use case, but it made the test cases run a bit slow.

@c-bg
Copy link

c-bg commented Jul 23, 2019

okay, I see. thanks a lot for your prompt reply!

@c-bg
Copy link

c-bg commented Aug 29, 2019

I think I found the reason: The subscription has its own readLoop method that closes the channel whenever it receives any receipt, if I see correctly:

} else if f.Command == frame.RECEIPT {

Could @thomaslee or @worg or anyone who knows the purpose of these lines comment on this? :)
Thanks a lot for your help in advance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants