Hi,
I recently updated our application to use Wildfire 2.6.0a and Smack 2.2.0. It takes now up to 15s to login to the server. It works but why did it got so slow?
After tracing the packets, it looks like that the client (smack) is waiting after the server sent the following packet.
Using an other client like psi the login stuff takes less than a second.
any idea?
Thanks
guido
Hey guido,
Is this problem happening all the time or randomly? Are you using any particular server/client configuration? One thing you can try in order to isolate the problem is: 1) try using plain connections and not TLS and 2) try using the old iq:auth mechanism instead of SASL. This will help us identify where is the delay happening.
BTW, you may also want to try using Spark (based on Smack) and see how it works.
Regards,
– Gato
Hi, thanks for your answer.
The problem occurs randomly but more on the frequent side of 15s. How can I disable the tls stuff. I tried it with:
connConfig = new ConnectionConfiguration(servername, 5222);
connConfig.setTLSEnabled(false);
connConfig.setSASLAuthenticationEnabled(false);
but it does not swich back to the old auth method.
thanks
guido
Hi all,
I’'m also having the same results as guido.
The delay lies in the first time we execute the code:
con = new XMPPConnection(“host”);[/i]
It takes up to 15s for me too. The login works perfectly fine. It seems that the client takes around 15s to negotiate a XMPP connection with the server. I’'m working on localhost by the way.
I also found out that if the first time you execute con = new XMPPConnection(“host”);[/i] fails (say if you turn the server off) and you ‘‘reconnected’’ to the server again (after you turn the server on) executing the same code, it connects in less than a second.
Hi guido!
I think I have the answer to your problem.
If you have use XMPPConnection(String serviceName)[/i] to connect to your wildfire server, then you will have some delay time conncting to the server because this method tries to perform a DNS lookup for the ip and port number according to the API.
The time is most probably spent on that.
Use XMPPConnection(String host, int port)[/i] instead and that should solve you problem.
thanks for the answers, but the problem still persits. I can use localhost as server name which should not get any delay in dns resolution but I still have the delay of 15s. Any other ideas. I’'m still looking for a way to force the smack client using the old auth method.
guido
I’‘m still stuck with this problem. I’'m using latest smack and wildfire code.
o Is there a way I can tell smack to use the old auth digest mechanism?
o Am’'I the only one having seen this problem?
guido
Message was edited by: guido
Hi, I think I have the same problem.
I create multiple client connections with my application. When I connect the first client, I have to wait 15-20 seconds at xcon = new XMPPConnection(hostname);[/i]. The next clients use less then 1 second at xcon = new XMPPConnection(hostname);[/i].
Maybe it has something to do with the static variables that get set the first time you execute xcon = new XMPPConnection(hostname);[/i].
This happens all the time, not random.
Message was edited by: C.Leeuwen
Set the port dude.
Use xcon = new XMPPConnection(hostname,5222); instead of just the hostname. Read the above posts.
That doesn’'t matter…
Hi,
I wonder if you are hitting an IPv6/DNS problem. If it tries to get the IPv6 address this could take some time if none is available. You could try to add “-Djava.net.preferIPv4Stack=true” as a JVM parameter (just like -Xmx64m) to make sure that java does not try an IPv6 lookup of the host address.
LG
Hey LG,
That’‘s a good one. It would be useful to use a profiler to detect where the delay is. DNS look ups may probably the reason of this problem in which case the solution is out of scope of Smack unless you use other XMPPConstructors that don’'t use DNS look ups.
Regards,
– Gato
Thanks for the replies, but this doesn’'t solve the problem… It still take the same amount of time to connect the first client. When I cycle trough my code with my debugger (NetBeans) and i reach the following line:
xcon = new XMPPConnection(hostname);[/i]
It takes most of this 15 seconds, after this time it will continue at:
public static boolean DEBUG_ENABLED = false;
private static List connectionEstablishedListeners = new ArrayList();
static {
// Use try block since we may not have permission to get a system
// property (for example, when an applet).
try {
DEBUG_ENABLED = Boolean.getBoolean(“smack.debugEnabled”);
}
catch (Exception e) {
// Ignore.
}
// Ensure the SmackConfiguration class is loaded by calling a method in it.
SmackConfiguration.getVersion();
}[/i]
Any other ideas?
Gr.
Carlo
Hmm… it seems to happen whenever i call xcon[/i] for the first time, no matter what method I call from it.
The method for DNS solving is
DNSUtil.HostAddress address = DNSUtil.resolveXMPPDomain(serviceName);[/i]
am I right? This line does not take more then 2 seconds.
Hi,
could you create a or even more stack traces of your application while it hangs like described here http://www.jivesoftware.org/community/entry.jspa?externalID=521&categoryID=20 ? You should be able to see in which line the thread is “locking/waiting”.
LG
I switched the way i set up my threads, now its a max of 3 seconds waiting time.
Thanks for all the help!
Gr.
funny thing, today I hardy could reproduce the 15s again. Just once in 20 tries it needed 15s to connect. Same code, same machine. Hmmmmm
guido
Hi all,
i would like to come back to this question, as I still have this problem sometimes. I recently updated to latest wildfire and smack but still the same problem. I did a thread dump but I do not see where is exactly hangs. Anyone an Idea? The following tread dump was taken while loggin in with smack to wildfire which took 15s or more.
Full thread dump Java HotSpot™ Client VM (1.5.0_06-b05 mixed mode):
“http-8080-Processor1” daemon prio=1 tid=0x083f1ef8 nid=0x48f0 in Object.wait()
at java.lang.Object.wait(Native Method)
at org.olat.instantMessaging.SmackInstantMessagingImpl.createClientController(Smac kInstantMessagingImpl.java:61)
at org.olat.gui.control.OlatUpperRightCorner.init(OlatUpperRightCorner.java:62)
This method seem to be the place where the time (15s) wait is coming from. It written that this is a rare thing, but in my case it’'s traps almost alwasy in this “rare” case. It calls the “connectionIDLock.wait(waitTime * 3);” stuff where the waitTime is 5s. it has to do with TLS but I do plain text auth. and plain text messaging (sever + client are on the same server).How can I disable TLS? Thanks.
from: PacketReader.java in the smack.jar
/**
Starts the packet reader thread and returns once a connection to the server
has been established. A connection will be attempted for a maximum of five
seconds. An XMPPException will be thrown if the connection fails.
@throws XMPPException if the server fails to send an opening stream back
for more than five seconds.
*/
public void startup() throws XMPPException {
readerThread.start();
listenerThread.start();
// Wait for stream tag before returing. We’'ll wait a couple of seconds before
// giving up and throwing an error.
try {
synchronized(connectionIDLock) {
if (connectionID == null) {
// A waiting thread may be woken up before the wait time or a notify
// (although this is a rare thing). Therefore, we continue waiting
// until either a connectionID has been set (and hence a notify was
// made) or the total wait time has elapsed.
long waitTime = SmackConfiguration.getPacketReplyTimeout();
long start = System.currentTimeMillis();
while (connectionID == null && !done) {
if (waitTime <= 0) {
break;
}
// Wait 3 times the standard time since TLS may take a while
connectionIDLock.wait(waitTime * 3);
long now = System.currentTimeMillis();
waitTime -= now - start;
start = now;
}
}
}
}
catch (InterruptedException ie) {
// Ignore.
}
if (connectionID == null) {
throw new XMPPException(“Connection failed. No response from server.”);
}
else {
connection.connectionID = connectionID;
}
}
I’'ve fixed this bug and posted the patch here: http://www.jivesoftware.org/community/thread.jspa?threadID=21075&tstart=0
It’'s already in the current nightly version.