Weird Issues with IM Gateway not loading

We have a number of users now who for whatever reason do not get any of the IM gateway icons the first time they load up spark. In order to solve the problem, they must close spark, and re-login to the jabber server and then their transports are available.

Has anyone else had this problem? I currently do not have STUN configured, but this happens both internally on the local network and also externally when users try to login from home.

Hi Aaron,

That is bizarre but I must admit I would be surprised if it’‘s the plugin that’'s causing it and not Spark.

That said, when you say load up Spark, are you referring to when they register the first time, or when they first run it and already have an account, or every time after a reboot or something that they fire it up?

Daniel

Well, let’'s see if I can explain this without confusing you.

It does not seem to matter if its the first time spark is loaded, the first time the user has logged in to jabber, or if its an existing user.

Internally, it seems to happen after reboots. One user reported to me that constitantly whenever he reboots his laptop, he has to start spark up twice before the transport loads. However, if he hibernates instead of shutdown it works on the first shot.

Alternativly, for users off campus it is consistent that you have to load spark twice before the transport loads.

Nonetheless, its a strange problem (at least we have work around, even thought its annoying)

I would agree that it’'s entirely possible that this is a spark issue, and not related directly to the plugin. However, the plugin is the area where we notice it.

Part of the reason I would lean towards Spark is that initial list of transports is not “up to” the plugin to send back to Spark. For any server, when a component connects, a disco query is done against it to see what features it has and those features are relayed back to anyone who does a disco request for the entire server. So the information is taken in by the server and the plugin isn’'t even really involved at that point.

The caveat there is that in 1.1.0, I actually do intercept and filter the disco response if you don’‘t have access to the particular transport. but i would guess that you are running 1.0.2 in which I’'m not really even involved in the disco response spark is getting from the transport.

It doesn’‘t make a lot of sense as to why it’'s behaving that way to me.