[ejabberd] Concurrent BOSH connection issue

paul tinson paul.tinson at gmail.com
Mon May 27 08:47:56 MSK 2013

I know this is an old thread so if i should start a new one please let me

I have been looking at this again, and i still have no clear idea what the
issue is.
I have switched from BOSH to a standard connection TCP connection and the
problem is also present.

So far i have compared the entries in the session table and they are
identical, I have looked through the code and see that conflicting resource
is checked and should be dealing with this situation.
Correct me if i am wrong but the check is doing a select on the session
table with the full user including the resource and returning the SID if
one exists. If one does then the resource conflict code should take the
configured action, I have set it to closeold, which is the default anyway.

When this happens the only way i have been able to clear it is to empty all
objects from the session table, using kick_session doesnt work even when
the only session showing is the 'stuck' one.
The above is a brutal hack but i havent had any luck just deleting the
specific record using the SID as the key.

If i try and get user_sessions_info on the stuck connection it throws a
stack trace, which i think is because its trying to get the fsm event state
for the given PID which doesnt exist.. Because its really closed.

At this point I am looking for any ideas to help trouble shoot this as i
cant see any reason for it to be behaving like this.

I am running the following:
erlang: R14B04
ejabberd: 2.1.11

On Fri, Dec 7, 2012 at 8:36 AM, paul tinson <paul.tinson at gmail.com> wrote:

> >
> > When a new session auths and is added to the session table should it
> > be able to insert that sessions record when one already exists for the
> > same user/resource combination?
> >
> According to ejabberd_sm.erl new connections are checked in the
> session table to see if they already exist.
> Since i can see the session in the table with a simple dump of that
> table while the user is connected it seems the duplicate session
> checking might not be catching all cases.
> Ill throw some debug into sm parts doing the session checking and see
> if i cant work out what is going on.
> Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.jabber.ru/pipermail/ejabberd/attachments/20130527/610c2e25/attachment.html>

More information about the ejabberd mailing list