A bit of an update.
We turned off the memory tweaks - just removed the file - to get back to square one and watch.
In addition, we completly disabled the subscription plugin we had been using, as well as disabling external components (that were not in use)
We have lasted longer, with only intermittant memory errors. We have 560-580 active connections, with only 14 memory errors. Interestingly, it was two series of 7 events within minutes of each other, followed by periods of no errors.
I did notice that these errors are also showing up in the stderror.log file on the log directory - with additional detail. The entries in this log have a one to one relationship with the memory items in the error log. Perhaps they have additional ‘‘clues’’ for those better at Java environments.
Exception in thread “Client SR - 13346867” java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Unknown Source)
at com.sun.jndi.ldap.Connection.(Unknown Source)
at org.jivesoftware.wildfire.ldap.LdapManager.checkAuthentication(LdapManager.java :346)
at org.jivesoftware.wildfire.ldap.LdapAuthProvider.authenticate(LdapAuthProvider.j ava:93)
at org.jivesoftware.wildfire.auth.AuthFactory.authenticate(AuthFactory.java:127)
at org.jivesoftware.wildfire.net.SASLAuthentication.doPlainAuthentication(SASLAuth entication.java:336)
at org.jivesoftware.wildfire.net.SASLAuthentication.handle(SASLAuthentication.java :172)
at org.jivesoftware.wildfire.net.SocketReadingMode.authenticateClient(SocketReadin gMode.java:117)
at org.jivesoftware.wildfire.net.BlockingReadingMode.readStream(BlockingReadingMod e.java:136)
at org.jivesoftware.wildfire.net.BlockingReadingMode.run(BlockingReadingMode.java: 62)
at org.jivesoftware.wildfire.net.SocketReader.run(SocketReader.java:123)
at java.lang.Thread.run(Unknown Source)
Thanks again.
Pat