server hangs on infinite loop


I'm using an embedded tigase server for testing an embedded tigase client.
sometimes when the client closes it prints an ugly "Socket closed" exception.
This time, two minutes after the client closed, the server reported an infinite loop and hanged.

TLSIO.writeBuff() WARNING: Infinite loop detected in writeBuff(buff) TLS code, tlsWrapper.getStatus(): NEED_READ

I closed the process more than an hour later.



MessageRouter name may cause configuration errors


since I updated to the trunk it seems an error has been introduced. I'm not sure when it appeared since I didn't update for some time.

I had a look at the way the server is initializing and it appears the bootstrap is affected by component names. If the MessageRouter is initialized before the Configurator, then the configuration of the server is totaly wrong (my instance doesn't even start).

In my case, I used a custom UserRepository / AuthRepository, and all components appeared to use the default server config instead of my "--user-db" and "--auth-db" parameters.


MUC locked room issues


it seems there are a few issues with the MUC components when the room are locked (not configured) :

I join an unexisting room, it will be created and send back a "201" status (configuration required).

1 ) A user trying to join this room should receive an error (http://xmpp.org/extensions/xep-0045.html#enter-locked), the server is not sending anything. Some clients will end up hanging, because they expect an answer, be it an error or a confirmation.

2 ) I don't configure the room, and leave it or disconnect (send an unavailable presence), the room is not destroyed.


MUC problem when a user is using more than one resource

Hey !

I was playing with my XMPP client, and I noticed there is an error when a user is connected to the same room with multiple resources.

If a user connects to a room with different resources AND different nicknames, when one of this resources turns "unavailable", the presence is not broadcasted to other MUC users.

If the user connects to a room with different resources but is using a single nickname, the behavior is ok. Since the presence should only be broadcasted when the last resource becomes unavailable.