Hi,
I’m using gateway 1.1.0 beta 2 - when I put the jar file into the plugins directory it can take a very long time for all the components to register with jabber. Do you have any idea’s why this might be happening? Taken from the debug.log
2007.08.23 17:05:04 Registering component for domain: icq
2007.08.23 17:11:45 Received iq packet: <iq type=“get” id=“237-2” from=“component.chat.mike.com” to=“msn.chat.mike.com”><query xmlns=“http://jabber.org/protocol/disco#info”/></iq>
2007.08.23 17:11:45 msn: Sending packet: <iq type=“result” id=“237-2” from=“msn.chat.mike.com” to=“component.chat.mike.com”><query xmlns=“http://jabber.org/protocol/disco#info”><identity category=“gateway” type=“msn” name=“MSN Transport”/><feature var=“http://jabber.org/protocol/disco#info”/><feature var=“http://jabber.org/protocol/disco#items”/><feature var=“jabber:iq:gateway”/><feature var=“jabber:iq:register”/><feature var=“jabber:iq:version”/><feature var=“jabber:iq:registered”/></query></iq>
2007.08.23 17:11:45 Component registered for domain: msn
So it took like 6 minutes for the icq to register…
I’m afraid I really don’t have any idea why that would be happening. I can’t really speak for beta 2 anymore. =)
err, thanks…
Is it possible that you are creating a list of all the users on particular transports. Registering them in some list/hashmap and then registering the transport with openfire? This would make sense because at the same time that the registration is taking place both java and mysql are working overtime.
Registration uses openfire’s internals to update the user’s roster (if necessary) just in terms of the transport entry. (which is skipped if you use Spark to register) That would update mysql if you weren’t using Spark. (but one change) Your transport roster is non-persistent, so no interation with mysql. (except for yahoo and irc which pull a pseudo roster to handle some things that the service itself doesn’t handle… simple is included in that too come to think of it) Either way, I run it with openfire and mysql and don’t see major slowdown.
This is a step before registration.
This is the deployment of the gateway plugin. How many users do you have in your gatewayRegistration table? We have quite a few, nearly 100k and the initial load of the gateway plugin takes a long time (no one is connected to openfire whilst the gateway plugin deployment is taking place). When the gateway plugin registers the transports (aim, icq and msn in our case) with openfire’s disco service does it do something like caching all the gatewayRegistration stuff in memory?
Mike
Ah, no, there is no pre-caching that occurs when you first load the plugin or the transports themselves fire up.
peculiar then.
on my dev system (some 40 accounts) loading exactly the same plugin takes only a few seconds. Doing it on our live server takes 11 minutes.
I guess the best test would be for me to take a copy of the db, put it on our dev hardware (essentially the same spec) and then disable all the transports. Enabling them one by one and restarting the gateway after each one has been enabled.
Mike
Mine did this too on last reboot, having just installed 1.1.1
Not really sure what to tell y’all.
daniel,
how many gateway registrations do you have in your test setup?
Could it be you dont see the issue because you dont have all that much data?
It’s possible, but I’ve spoken to folk who have far more than even you say you have and they haven’t reported such issues. Very little occurs when the transport first starts up, but there is one thing that could potentially be causing something. Well there’s another issue where IRC isn’t shutting down well and it takes a long time for it to finish shutting down and it causes the new plugin to not start back up within my patience timeframe. I don’t yet know what’s going on there. If you don’t have IRC enabled though that won’t be an issue. That said, when the transport comes up it probes everyone who’s registered to see if they are logged in to try to auto-log them in. I think I’m going to add an option to disable that if the server admin so-chooses. GATE-331 How many users do you have that are actually registered with the transports? (I couldn’t tell if you were telling me total users on system, or total registered with gateway plugin)
dayjah wrote:
err, thanks…
Is it possible that you are creating a list of all the users on particular transports. Registering them in some list/hashmap and then registering the transport with openfire? This would make sense because at the same time that the registration is taking place both java and mysql are working overtime.
snap fingers That’s -EXACTLY- what’s happening! I just read over my code again and the transport starts up and it goes to send presence probes to everyone. To do that it has to get the full list of registrations and so… there you go. If you don’t care about everyone being automatically logged back in after a plugin restart, then the option I’m about to add should do the trick for you.
Go ahead and set:
plugin.gateway.tweak.noprobeonstart
to true in your system properties.
When 1.1.2 comes out, it should see that and NOT probe everyone on start. (is there a point in me giving you a build to test? doesn’t this only really effect you when you have to upgrade the plugin?)
hey -
yeah this problem only rears it’s head on our live system.
atm I have enough issues with old gateway releases - not sure I have time to test new ones
Thanks,
Mike