Jive

Openfire Openfire Support
1

Hi,

I’'ve installed jive and configured to authenticate using AD(LDAP). It worked for 2 days but now when I try to log using Padion it stays trying to connect without any response.

This error occur only for some users, other still can connect correctly.

When I go to web administration tool the user that stays trying to connect appears online.

I’‘ve tryed to install Exodus to test if the error was a bug in Pandion but in Exodus the problematic users don’'t connect to.

How do I solve this problem?

2

have you tried to kill problematic session in Admin Console or just exit pandion client and launch it again after some time?

3

Oi Patrick,

When using Exodus, could you press F12 to open the debugger window and tell us which are the received and sent XML packets? Are other users still able to log in? Which operating system are you using? I may ask you to obtain a thread dump of the server. Let us know if you need help getting that information.

Obrigado,

– Gato

4

Exodus:

Using specified Host/Port: quimera.sjes.gov.br 5223

SENT: <stream:stream to=“sjes.gov.br” xmlns=“jabber:client” xmlns:stream=“http://etherx.jabber.org/streams” xml:lang=“pt_BR” version=“1.0” >

RECV: Setting reconnect timer to: 19

5

I’'ve restarted pandion and the computer many times…

It happens with more than one user

6

When I digit the wrong password in pandion the Jive responds that the password is invalid.

But with the right password it st waiting a response.

I’‘ve use ethereal to see the packets and i’'ve seen many packets with TCP checksum incorrect.

I think it is not network because every other application is working well. I use the ssh to administer the server where jive is installed and it funcitons well.

7

I’'m using windows XP and windows 2000 to run pandion and linux fedora core 3 to run jive.

For some user it functions, for other no.

8

Patrick,

In order to get a thread dump you will need to execute a kill -3 . Could you send me your dump by email so I can check it. Remember to generate the thread dump when clients cannot connect to the server. The dump should be generated in the nohup file or in the stdout file.

Could you try using url=http://www.jivesoftware.org/builds/messenger/dailybuilds/jive_messenger_2005 -05-22.tar.gzthis nightly build[/url]? I assume that you are using JM 2.1.3 and many problems have been fixed since that version.

Thanks,

– Gato

9

I’'ve used the command

kill -3

but where the dump is saved? nothing was saved in logs/stdoutt.log.

The checksum errors appears in the packet sent in the direction from pandion to jive.

10

nohup.out can be in jive_messenger installation directory or in jive_messenger/bin… cant remember, that’‘s if you areusing it with root, and in /home/jive if launching it with jive user. My linux server is at work so i cant guarantee i’'m 100% right, but you cant figure it out by yourself;)

But, if you are using 2.1.3 please do upgrade before going further, i had such strange disconnections with 2.1.3 too. Now with 2.1.4 n.build this problem seems to dissapear.

11

Have you received the nohup.out?

12

Hey Patrick,

I see 3 thread dumps in the file that you sent me. The first dump shows that there were 3 connected users with no problems. The second dump shows 4 connected users with no problems and a 5th user waiting for LDAP to answer. The last dump shows only 1 connected user (with no problems).

So I assume that the problem was captured with the second thread dump. Since a thread dump is just a snapshot of the JVM in a moment I’'m not sure how the “waiting for LDAP to answer” situation evolved. It would be great if you can take two snapshots (i.e. thread dumps) with a couple of minutes between them when a user is waiting forever so we can see how the situation evolved. If nothing has changed (i.e. Jive Messenger keeps waiting for LDAP to answer) then we will have to check the status of the TCP connection between Messenger and the LDAP server. If the connection seems ok then you will have to check the LDAP server status to figure out why nothing is being returned.

Anyway, I will check if we can specify a read timeout so if nothing is received from the LDAP server then a SocketException will be thrown.

Regards,

– Gato

13

I don’'t think this is the problem.

When Pandion waits for a response and I enter the Web Administration Tool in the sessions page I see the client as online. So, the authentication is ok.

But Pandion receives no response.

I think that the wait state you see in the second dump was because this dump i’'ve created just after clicking in the reconnect button of Pandion.

14

Of the five user that were online in the dump just 2 could access pandion normally. The other 3 had stayed waiting forever.

15

I’'ve sent an email with two attachments.

The first is the network dump collected with ethereal in SSL connection. In this case the client waits forever.

The second is the net dump with normal connection. In this case no response is returned from Jive and Pandion quits connection.

16

No solution til now?

17

I’'ve discovered the pandion feature that monitors the traffic.

So, this is the traffic before pandion stays waiting… maybe it’‘s pandion’'s bug.

SENT: <?xml version="1.0"?>

SENT: <stream:stream to=“sjes.gov.br” xmlns=“jabber:client” xmlns:stream=“http://etherx.jabber.org/streams”>

RECV: <stream:stream xmlns:stream=“http://etherx.jabber.org/streams” xmlns=“jabber:client” from=“sjes.gov.br” id=“f6a8c2fb” xml:lang=“en”>

SENT: jespdb

RECV: jespdb

SENT: jespdbPandion< password>

RECV:

SENT:

SENT:

RECV:

SENT:

SENT:

RECV:

RECV: < /iq>

18

Patrick,

According to the Pandion traffic I see that Pandion sent a packet to the server asking for the user roster and the server never replied (see id=“sd10”). Could you check all the log files. Maybe we could find that a packet was dropped or some other error.

Regards,

– Gato