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

BUG : EM streams messed up when one of many in-script connections closed. #169

Open
mistergibson opened this issue Dec 15, 2019 · 2 comments

Comments

@mistergibson
Copy link

Background:

I am attempting to support mutliple xmpp client objects running in the same script. I need, for my use case, for this to work without conflicts. I can get the client objects to connect under their respective jids and send chat messages. However, if I disconnect just ONE of those client objects -- ALL traffic of ALL clients gets utterly hosed in EM. In fact, it appears that EM is actually shut down for no good reason, and I have to hacky-hack a restart - not that it helps the messed up streams any.

So:

I'm wondering if there is a method I should override for alternate behaviour when closing streams such that EM will be left running happily along as before? I will need that situation to sustain support for the other connected client objects. Also, do you know of a smoother way to restart EM if it is buggered for any reason (just wondering).

@paradisaeidae
Copy link

XMPP connections are opened as bi-synchronous/bidirectional xml streams.
Opened at each end, the root level.
If the xml is broken, the stream breaks, connection unwinds.
Very strong level of connection rigor.
This requires a fine granularity of processing with a connection.
I'm unsure of the finer detail myself. Still learning here.
Though seeing the language architecture of Erlang produce robust xmpp server the 'Erlang application' is a fine grained encapsulation of such.
The EM listener is a port level listener.
I've not read the code though it appears Erlang beams are able to listen per connection.
Might be each connection has a stack?
So, pushing the abilities of Ruby to get this.
Some have fun trying!
https://github.com/igrigorik/em-synchrony
There may be somewhere there a rescue might be placed.
Find the line 'This is dangerous territory - you've been warned.'

@mistergibson
Copy link
Author

Well, as a work-around I overrode unbind method to do everything but shutdown EM, and it works fine now:

    def unbind
        # Fix bug where closing connection stops EM for ALL Client Instances.
        # call_handler_for(:disconnected, nil) || (EM.reactor_running? && EM.stop)
        call_handler_for(:disconnected, nil)
        true
    end

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