We don’‘t know why or how, but for some reason Wildfire occasionally just “stops working.” Clients don’'t interact with it.
I’‘ll get around to troubleshooting this, but since we have a pretty universal testing widget in play for our network (hostmon), it’'d be nice to have a test for Wildfire service functionality running as well – something to restart services when they fail, and let us know.
We generally vbscript or jscript – does anyone know what would work to adequately determine whether Wildfire is being responsive to a client? What kind of widget would work to test it?
I’'m curious to see why you are having this problem in first place. Which version of Wildfire are you using? Do you see any error in the log files? Can you get a thread dump of the Java Virtual Machine and post the content of the dump? Under linux/unix you will need to execute kill -3 [process id]. The info will be stored in your stdoout file which is probably your nohup file.
The best test I can think of would be to connect to the server (port 5222) and issue an opening XML stanza, then immediately disconnect after getting the proper reply.
There’‘s a lot of stuff in the logs, but unfortunately I don’'t know when the server stopped responding to clients. Log entries obviously continued; the service was still working.
One thing I’'m noticing is a lot of entries like this:
] Groups () include non-existent username (tlittle)
The log data is quite correct; this user no longer exists.
What method is there, in WIldfire, for purging the local database of records of users who no longer are in our Active Directory? LDAP integration is great until this kind of thing starts to stack up.
I wouldn’‘t mind a manual process, for that matter – so long as I could automate it using our own widgets. Just wondering if there’'s something integral to Wildfire to clean things up.
Thanks for the tip one testing. I’'ll see what I can do.
Alas, the problem surfaced again, and I don’‘t know when. Rats. Seriously, since I have no idea what I’'d be looking for in which logs, my only recourse is to commit some time – frequent moments – to determine a narrow enough period in which to look for errors when the problem recurs.
Meanwhile, though, what of the stale users? Is there any automatic way to deal with them, so I don’'t get so many entries like this:
2007.02.03 15:57:25 Exception thrown when searching for userDN based on username ‘‘tiffany smith’’
org.jivesoftware.wildfire.user.UserNotFoundException: Username tiffany smith not found
An LDAP-referenced system really needs a way to say to itself, “Ah! That user doesn’‘t exist anymore. Well then, I’'ll not trouble myself with her.”
http://localhost:9090/index.jsp should display something like “Java Memory 16.51 MB of 126.62 MB (13.0%) used”, I wonder if you have really 50% or only 10% free.
@: UserNotFoundException - You can add users to your roster which do not exist and as it is your roster the server will likely not modify it. This works also with users registered on remote servers and a remote server can never modify your roster.
Anyhow JM-65 is the 2nd issue on http://www.igniterealtime.org/roadmap.jsp so one may vote for it to become #1 - "Your vote counts! We prioritize work on new features and improvements based on community feedback. ".
12 of 493 for memory. That’‘s never been very high. This isn’‘t at all deployed; we’'re only testing. We would LIKE to deploy Wildfire to all our users, but the continuing buginess is preventing that.
As for this:
“You can add users to your roster which do not exist and as it is your roster the server will likely not modify it.”
that’‘s not really the problem. No one is adding users. In fact, the usernames that are showing up as instances of the error have never been on the system, nor have they ever been added by anyone manually to a roaster. They’‘re showing up only because Wildfire read them from LDAP, apparently added them to the user base, and now that they’‘re no longer in our directory Wildfire’‘s not finding them in an LDAP search which, apparently, it’'s doing.
What mechanism is there for Wildfire to purge stale user records when those users are no longer in the directory?
Finding LDAP users is only a part of directory integration. Purging users no longer in the directory is no less important.
For all I know this error is harmless from a standpoint of reliable Wildfire function. But a “clean” LDAP integration woujld address deletions from the directory as well as additions to it.
I too am experiencing this problem with the server not responding to clients after a couple of days. I was using wildfire 3.1.1 on a linux box for a long time with no problems… So I upgraded to wildfire 3.2.0 and it worked fine for a couple of days. Then it stopped responding to clients. I figured since it was an old box and needed to be rebuilt anyways… i moved the server over to a windows 2003 box. Now i have the same problem where every 2 days or so i have to stop the wildfire service and restart it so that it starts to respond again. I am using PSI 0.10 as our client and it seems like I am connected… i see that people are on and i appear to send messages but they never see them of course and when i shut down PSI and try to log back in… it never connects.
the linux box used Gentoo and MySQL with AD/LDAP and the windows 2003 box uses MSSQL wiht AD/LDAP
Let me know what I can do to help you guys better understand what is going on and I will do what i can
Is any of your clients connecting through port 5223? JM-970 was reported and fixed. If that is not your case then we will need a thread dump of your JVM to find out what’'s going on. Execute kill -3 [processid] to get a thread dump. The info will be stored in the stdout (prob your nohup.out file).
Yep… that is me then, we use port 5233 … sorry about that… I need to learn how to search through JM issues better… Just saw this post and it seemed so much like my problem that I figured I would add to it…
Noticed in the JM that is says the old SSL connection… is there a better way to connect using PSI and wildfire?