I recently upgraded to the newest version of jive messenger. However, here’'s my problem some user can log in using (trillian, gaim) but they may or may not seen if any other users are log. If I go to the jive admin user screen, I see them log in and can send messages. Users using Pandion cannot even log in. Any suggestions?
Hey Jeb,
Can you tell us a little more about your setup? Are you using shared groups? Users added contacts to their contact list manually? Any error in the log files? Sample of XML packets sent and received from the server, etc.
Thanks,
– Gato
I’'m having a similar problem here.
I’'m running Mandriva 2005LE with jdk-1.5.0_04 and jive_messenger_2_2_2.
Jive Messenger runs as user jive.
I’'m not using shared groups.
All users added manually.
I’'m using MySQL.
I have PyAIMt, PyICQt, PyMSNt and proxy65 external components.
I’'ve installed the search plugin.
I’'m using Psi-0.10-test2 as my client.
I currently have two users (cdugal & test).
User cdugal has ~30 contacts, almost all of which are on different servers.
User test has 1 contact on a different server.
So, I’'ll try to describe the problem as I see it:
After I restart Jive Messenger, or wait a long time, and set cdugal to be online, I am authenticated and my roster is transferred. Very little other information is transferred (I have not verified the consistency of the quantity of the information sent over, but contact presence is not sent to Psi). Jive Messenger during this time does not respond to any requests (Messenger seems to hear but not talk back). The only time that I’‘ve been able to get Messenger to talk to Psi is by sending an administrative message to all users (this does not make Messenger send any other information to Psi though). But, while cdugal’'s account is essentially useless, I can log in as test, and have it work properly. After ~10 minutes of waiting, Messenger finally sends the presence information to Psi and starts responding normally.
I have noticed that if I go to the Server Sessions in the Admin Console, the list of servers takes ~10 minutes to load…
A couple interesting errors are:
2005.09.21 12:08:05 org.jivesoftware.messenger.handler.IQHandler.process(IQHandler.java:71) Internal server error
java.lang.IllegalArgumentException: IQ must be of type ‘‘set’’ or ‘‘get’’.
at org.xmpp.packet.IQ.createResultIQ(IQ.java:321)
at org.jivesoftware.messenger.handler.IQVersionHandler.handleIQ(IQVersionHandler.j ava:54)
at org.jivesoftware.messenger.handler.IQHandler.process(IQHandler.java:48)
at org.jivesoftware.messenger.IQRouter.handle(IQRouter.java:213)
at org.jivesoftware.messenger.IQRouter.route(IQRouter.java:73)
at org.jivesoftware.messenger.PacketRouter.route(PacketRouter.java:65)
at org.jivesoftware.messenger.net.SocketReader.processIQ(SocketReader.java:258)
at org.jivesoftware.messenger.net.ServerSocketReader.access$001(ServerSocketReader .java:45)
at org.jivesoftware.messenger.net.ServerSocketReader$1.run(ServerSocketReader.java :76)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java: 650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
2005.09.21 12:41:58 org.jivesoftware.messenger.net.SocketReader.run(SocketReader.java:145) Connection closed before session established
Socket[addr=/208.245.212.98,port=53265,localport=5269]
Hey Cliff,
Thanks for the detailed bug report. The problem you are describing is generated by the fact that the process that is attending the user connection is the one that is trying to reach the remote servers to find the status of the contacts. Since connecting to remote servers is taking too long the user’'s client becomes unresponsive. We are planning to fix this problem and as a temporary solution JM-409 was created and a fix will be available soon. Anyway, if the delay is originated inside the gateways then you will have to wait for the final fix.
Thanks,
– Gato
Hey Cliff,
You can download the next nightly build and check if the problem has been fixed. Remember that this is a temporary solution and not the final fix. You can configure the system property “xmpp.server.read.timeout” with any number of milliseconds. The server will use that property as a timeout for waiting for a connection to be established or get data from the remote server.
Regards,
– Gato
Hi,
I am also seeing similar behaviour. Running on Windows NT4 SP6 I can run the server and connect from clients on other machines using Kava or Jeti and see both users in the admin console but the users cannot see or send to each other. I can send a broadcast message which goes to both users but they can’‘t talk to each other. This is an internal network with no internet access. I’'d be very grateful for an assistance in getting this up and running.
Ian
You can download the next nightly build and check if the problem has been fixed.
Thanks for the quick response and fix.
I will install it this weekend and report back.
Sorry about taking so long to get back.
Anyhow, after removing a Yahoo! transport from another server from my roster, and upgrading my Messenger, things worked reasonably well without the fix you mentioned, so I left it as that. My roster stays interactive while Messenger is searching for other servers now, so I can wait for it to be populated.
Out of curiosity, what exactly was/is the problem? Is it that communications are handled sequentially?
Hey Cliff,
We finally implemented the final solution. Jive Messenger will now try to establish connections to remote servers in another thread so clients won’'t have an unresponsive behavior. You can read more about the problem we had in this issue JM-416. JM 2.3.0 beta 1 includes this fix so people should upgrade to that version.
Regards,
– Gato
Thanks for the insight Gato,
Like I said, things are working reasonably well now, which is great. If I understand you correctly though, remote servers are contacted sequentially, even in the separate thread. Is it possible to have the remote servers contacted concurrently so that a slow server doesn’'t slow down all the requests following it?
Hey Cliff,
We are using a publisher/consumer solution for the asynchronous mode. In this solution we have many user threads queueing the s2s requests and we have many threads processing the queued requests. It is possible to configure the property “xmpp.server.outgoing.threads” to control the number of processing (i.e consumer) threads.
Regards,
– Gato
Thanks for the tip!
Doing a bit of googling, I’'ve found xmpp.server.processing.threads (default 50) in addition to the xmpp.server.outgoing.threads (default 20) that you mentioned. Would xmpp.server.outgoing.threads > 50 require a xmpp.server.processing.threads > 50 to work properly too? Also, are there any other related properties I should maybe look at tweaking?
Cliff,
Those two properties are unrelated. The property xmpp.server.processing.threads[/i] specifies the number of threads used for processing the packets sent by remote servers (i.e. incoming session related). And the xmpp.server.outgoing.threads[/i] property specifies the number of threads used for consuming packets to be sent to remote servers that need to create a new outgoing session (i.e. outgoing session related).
My goal is to include a nice page in the admin console for the next release so admins can easily configure these parameters.
Regards,
– Gato
So, xmpp.server.processing.threads should be more tuned to the server’‘s performance, while xmpp.server.outgoing.threads should be more tuned to the network’‘s performance. I think I’'m slowly getting this stuff.
Thank-you for all the help!
Yep. We could say that for servers with high incoming load from remote servers the xmpp.server.processing.threads[/i] might have to be increased. And the opposite applies for the other property. For servers that need to establish many connections at the same time with remote servers the xmpp.server.outgoing.threads[/i] might have to be increased. Although, I think that the second case must not be that common.
Regards,
– Gato
One more quick question: is there xmpp.server.outgoing.threads per client session, or for all the connected clients combined?
The xmpp.server.outgoing.threads /i property is for all the connected clients combined. However, the xmpp.server.processing.threads[/i] property is per incoming session.
Regards,
– Gato