Late unavailable presence can knock a newer session out of a chatroom

Here are the appropriate log messages for this with the port numbers highlighted.
At around 2008-10-31 10:00:00 I simulated a disconnect by dropping the network connection of the first session.
At 2008-10-31 10:21:17 my most recent session was knocked out of the chatroom it had joined:

=INFO REPORT==== 2008-10-31 09:57:54 ===
I(<0.233.0>:ejabberd_listener:112) : (#Port<0.446>) Accepted connection {{proxyipaddress},3756} -> {{serveripaddress},5222}

=INFO REPORT==== 2008-10-31 09:57:58 ===
I(<0.236.0>:extauth:73) : extauth call '["auth", "myusername", "ejabberd-service",
"mypassword"]' received data response: [0,1]

=INFO REPORT==== 2008-10-31 09:57:58 ===
I(<0.402.0>:ejabberd_c2s:560) : ({socket_state,tls,{tlssock,#Port<0.446>,#Port<0
.448>},<0.401.0>}) Accepted authentication for myusername

=INFO REPORT==== 2008-10-31 09:57:59 ===
I(<0.402.0>:ejabberd_c2s:805) : ({socket_state,tls,{tlssock,#Port<0.446>,#Port<0
.448>},<0.401.0>}) Opened session for myusername@ejabberd-service/cl-xmpp

=INFO REPORT==== 2008-10-31 10:01:38 ===
I(<0.233.0>:ejabberd_listener:112) : (#Port<0.459>) Accepted connection {{proxyipaddress},3834} -> {{serveripaddress},5222}

=INFO REPORT==== 2008-10-31 10:01:42 ===
I(<0.236.0>:extauth:73) : extauth call '["auth", "myusername", "ejabberd-service",
"mypassword"]' received data response: [0,1]

=INFO REPORT==== 2008-10-31 10:01:42 ===
I(<0.409.0>:ejabberd_c2s:560) : ({socket_state,tls,{tlssock,#Port<0.459>,#Port<0
.461>},<0.408.0>}) Accepted authentication for myusername

=INFO REPORT==== 2008-10-31 10:01:45 ===
I(<0.409.0>:ejabberd_c2s:805) : ({socket_state,tls,{tlssock,#Port<0.459>,#Port<0
.461>},<0.408.0>}) Opened session for myusername@ejabberd-service/cl-xmpp

=INFO REPORT==== 2008-10-31 10:21:17 ===
I(<0.402.0>:ejabberd_c2s:1297) : ({socket_state,tls,{tlssock,#Port<0.446>,#Port<
0.448>},<0.401.0>}) Replaced session for myusername@ejabberd-service/cl-xmpp

Badlop and I had the following conversation:

I've modified the Lisp xmpp client that I'm using to be more verbose.

When my client connects/authorizes/creates a session, it starts out by sending presence to the server:

It gets a strange response, as if its username were in lower case from the same username in uppercase:

And vice versa:

It then sends a message to a server that controls room access via xmpp messages. This server is just another xmpp-client, but is an administrator on the ejabberd server.
The message my client sends asks to be invited to the chatroom. The server does the following:

Next my client joins the room:

And receives the confirmation:

At some point later, the "Replaced session for" message is logged for the old session and my new session receives the 2 messages:

It seems strange the mixed case messages I'm getting. My usernames are always in uppercase, never in lowercase.
I'll try and look into that aspect a little more as it seems confusing.

I've been able to replicate this using pidgin. I think the reason I don't get a conflict is because the control-server sents the invite...

I'm still not sure what is happening with the mixed case usernames in some of the messages... I did see that when I use Psi it tries to change any username I type in to lowercase. I'm using a case-sensitive external auth script.

I thought I would be able to get around this problem if I made sure that I used unique nicknames in the chatroom for the new ejabberd session.

I was however mistaken. It seems that ALL chatroom entries for an ejabberd user JID are signed out, rather than just the ones for the particular ejabberd session that has terminated.

I thought about using unique resources for the subsequent logins but that won't work for 2 reasons:
1) I have explicitly set max_user_sessions to 1.
2) My business logic requires that a user can have only 1 session. I really had hoped that as soon as the new session is created the old session can no longer affect anything.

This seems to be a problem for long lived sessions... I imagine that lots of other applications must maintain connectivity after network downtime...

I think that this situation can be remedied if ejabberd sends the unavailable presence to the chatrooms before trying to send the unavailable presence to the users JID and not after.

As a follow-up for anybody that is interested:

First, a quick note on multiple sessions using different resources:
It should be possible for 2 resources on the same basic JID to enter a room and share a nick.
Example scenario:
I connect from home and join a room.
I connect from work and join the same room.
I want to be able to see the messages at home and at work, while at the same time not show up as two separate nicks.

This is outlined in XEP-0045 section 7.1.10:
"However, if the bare JID of the present occupant matches the bare JID of the user seeking to enter the room, then the service SHOULD allow entry to the user, so that the user has two (or more) in-room "sessions" with the same roomnick, one for each resource."

Unfortunately this is not working in the current release of ejabberd as outlined here: http://www.ejabberd.im/node/3258

To accomplish my goal of not having my subsequent session kicked out, I used a combination of unique resources and unique room nicknames. When the first session is replaced, the second session is not affected.
If you are trying to maintain 1 session per username, then it is also vital to set max_user_sessions to 1.