I discovered an issue yesterday where Wildfire drove my load up quite a bit. (from “around 0” to “around 10”) My preliminary investigation of it has turned up the following information:
I was running the yahoo transport (xmpppy project) as an external component to my jabber server
Upon closing both sessions, the load immediately dropped to 0 like it was supposed to.
I wanted to go ahead and post a start to this. If I have some time to, I’'m going to try to duplicate precisely what caused this. (and see if I can find a way to be able to reproduce it trivially)
Aha, thanks, I keep forgetting about that. Every time Gato asks for more information I can’‘t make it show it’'s head again. =) And when it shows, I forget what to do to get it going. lol
Herre’‘s the output from the sessions screen. Note that it’'s treating aim, msn, and yahoo as outgoing sessions and is “stuck” in a pissed off mode. The moment I sever those connections (close) the load drops.
Typically this happens when I start wildfire, am logged in, and then start the transports. I think that something is getting confused in the time period between. Like I log in, Wildfire sees that it is not aim.jabber.vorpalcloud.org, Wildfire tries to do an s2s connection, before I sever the connection PyAIMt connects and claims aim.jabber.vorpalcloud.org, load and confusion ensues.
took you more than one thread dump while Wildfire was using much CPU? “sun.misc.Unsafe.unpark” looks interesting but this could be just normal. As you can close the connections which cause the trouble I wonder if you did also take one then.
Ya know, no, I didn’‘t take one after I got things running. Didn’'t think about that.
I did find out that I can damn near duplicate this behavior on command now. I think that when I log in to my account before the python transports have connected, the aim.jabber.* and friends jids are treated as external (s2s) refs. As such, wildfire gets bogged down in trying to connect to them externally or even tracks/caches that they are an external ref. Then the python transports connect and all of a sudden there’‘s this weird internal jid that’‘s referenced in the external cache and it’'s confused. I believe, if this is an accurate assessment, that simply setting it up so that when an “external component” connects that it wipes the s2s cache entry for it.