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

if [email protected]? @conn.disconnect => connection was forcibly closed by the remote host #110

Open
georgy7 opened this issue May 19, 2015 · 2 comments

Comments

@georgy7
Copy link

georgy7 commented May 19, 2015

How to check of connection was closed by remote host?
I'm trying to make a thread, that receive stomp messages and another stuff and reconnect, when the connection is down. But I could not determine, when it is down.

[email protected]? => true
@conn.poll => nil (as if queue has no messages)

So, when I interrupt and try to disconnect, I got exception.

@conn.disconnect if [email protected]? =>
An existing connection was forcibly closed by the remote host..

I don't want to remove this exception. I want to know if connection was already closed before @conn.disconnect. Is there a way to do this?

@georgy7
Copy link
Author

georgy7 commented May 19, 2015

I use the hash:

hash = {
  :hosts => [host],
  :reliable => false,
  :max_reconnect_attempts => 1,
  :max_reconnect_delay => 1.0,
  :start_timeout => 1.0,
  :connect_timeout => 0,
  :connread_timeout => 1.0,
  :hbser => true,
  :stompconn => true
}
@conn = Stomp::Connection.new(hash)
@conn.subscribe @stomp_destination, { :ack => 'client' }

@gmallard
Copy link

gmallard commented Jul 8, 2015

I am not sure there is a way to accomplish what you want with 'poll'. (At least as it is currently written.) The socket was apparently 'not ready' (or already nil).

I think you would need to actually issue 'receive' (or 'disconnect') in order to see the exception.

Sorry. I will think about this some more, and let you know if I come up with any further ideas.

Re: your connect hash ....... since you have reliable => false, those max_reconnect_xxxx parameters are ignored. Hope you know that.

You might think about reliable => true, with other appropriate parameters, which should trigger the gem to attempt to failover and/or reconnect.

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

2 participants