Issue 50 in activemessaging: STOMP ignores configuration "reliable"
codesite...@google.com
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 50 by maarten.vanberkel: STOMP ignores configuration "reliable"
http://code.google.com/p/activemessaging/issues/detail?id=50
What steps will reproduce the problem?
1. Configure reliable: false in broker.yml
2. Stop your message bus
3. Try to publish a message
What is the expected output? What do you see instead?
Expected: No retries.
Actual output: connect to xxxx failed: Connection refused - connect(2) will
retry(#0) in 5
What version of the product are you using? On what operating system?
0.6.1
Suggested patch:
replace line 21 of lib/adapters/stomp.rb with:
cfg[:reliable] = true if cfg[:reliable].nil?
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
codesite...@google.com
Comment #1 on issue 50 by maarten.vanberkel: STOMP ignores
configuration "reliable"
http://code.google.com/p/activemessaging/issues/detail?id=50
Created a patch file for the suggested patch.
Attachments:
issue_50_fix_for_ignoring_reliable_configuration.patch 525 bytes
codesite...@google.com
Comment #2 on issue 50 by kookster: STOMP ignores configuration "reliable"
http://code.google.com/p/activemessaging/issues/detail?id=50
this reliable/unreliable thing is an ugly vestigial bit of code.
I thin it was really for debugging - to make the poller die right away
instead of
continuing to retry when tetsing out the config in development. I think it
would be
best to get rid of it. It's confusing, and I don't think necessary given
the logging
will show any errors.
codesite...@google.com
Comment #3 on issue 50 by maarten.vanberkel: STOMP ignores
configuration "reliable"
http://code.google.com/p/activemessaging/issues/detail?id=50
Hmm, I think that any web requests that send out messages should be able to
handle
the exception when the broker is down. Waiting a few seconds before
retrying will
cause a cascading effect because all request handlers will be occupied for
much too
long. Users are not willing to wait seconds for a request to be responded
to and will
refresh the page.
Anyways, maybe the 'reliable' thingie should be implement more properly,
but I still
think this fix should be applied so the reliable configuration parameter
can actually
be used :-)