Hi Jeff,
a “kill -3 wildfire-pid” does not kill the process, it should write to STDERR or STDOUT and thus you should find it in nohup.out. I’'m sure that the JVM parameters will help you for some time but they just hide the problem for some more time. So a javacore will be really helpful.
If you hit a new bug then it will be fixed for Wildfire 3.2.x, so you’'d need to update to 3.2.x to get it fixed.
LG
I am beginning to believe that upgrading could be my only option, however who has the time anymore. This server went production three weeks ago, and has had nothing but issues since. Partly our fault I belive due to undocumented amont of users, … I will look into it at a later time, but until then I guess I will keep it limping along.
Hi Jeff,
well, upgrading is one thing and spending time on fixing errors another one. I’'m sure that using 3.2.0 is a bad idea as it contains bugs, 3.2.1 should fix some of them. If it does work now with these JVM parameters you may really want to keep it running as it is as the NIO stuff is quite new within Wildfire - but if it crashes again …
A thread dump of your current installation would really help so one can make sure that 3.2.x solves the problem.
LG
Hey LG,
it2000 wrote:
…I’'m sure that using 3.2.0 is a bad idea as it contains bugs, 3.2.1 should fix some of them…
I wouldn’'t say that Wildfire 3.2.0 is an unstable release. We have been using it in jivesoftware.com for a while and it has been running quite fine. The following issues were found in Wildfire 3.2.0 and have been fixed for Wildfire 3.2.1. FYI, Wildfire 3.2.1 will be released tomorrow so people planning to update to Wildfire 3.2.0 may want to wait one day more.
Regards,
– Gato
Ok, well currently Ihave 3.2 on the test box looking at it. Problem is that this issue didn;t surface until WiFi is under Load. It would prolly be easier to upgrade to 3.1.1 as that doesn;t require the java upgrade or anything. THis box is Production now, so all changes have to go through the Corporate process… :-s heh…
Will go ahead and do the 3.2.1 upgrade when it comes out. I have found this, the magic number is 1101. When Ihave 1101 users log in, that is when the PyMSNt transport starts dropping off. I remember something about limited connections through that transport IF there were certain short comings in regards to polling, and Ithink Twisted, but Ihave the latest on those so Iam a bit befuddled… Also, WiFi is still not updating status of the Py Trans, even when I kill the process and allow it to rest for 4 minutes…
Hey Jeff,
Just a correction to your post. Wildfire 3.2.* does not require Java 6. It can be safely used with Java 5. However, since Java 6 is faster than Java 5 we are now bundling Java 6 with Wildfire but you can use another Java 5 JVM with Wildfire.
Regards,
– Gato
Hi Gato,
I agree that Wildfire 3.2.0 is stable but the NIO stuff is new. That’'s probably not the only reason why 3.2.1 gets released 2 weeks after 3.2.0 but I would not use it for >100 users within this month. Probably because I also know what a “corporate change process” is, and that it contains usually also a quality check. As long as the memory issues do not occur any more upgrading to 3.1.1 is more save than using 3.2.x. Taking a look at 3.2.x is of course necessary.
@ Jeff: Is it possible that the user which runs PyMSN has an “open files” limit (ulimit -a)?
First I thought you were using the Gateway Plugin but it did require 3.1.0 and the current version requires 3.2.0
LG