Msn transport going offline

hey, im using openfire 3.3.0 and gateway plugin 1.1.2

we’re seeing a situation where the msn gateway is reporting itself as unavailable to new clients when they send status probe’s to it. This behavious seems to start after a given time span. We’re still trying to work out how long and what is happening at that time so I’ll update when / if I get anymore information. But if anyone has any idea’s that could lead to some light being shed that would be a huge benefit.

Thought: it would be good to have an admin page that showed the availability of the gateway plugin. I’ve looked at the settings page and I can see it is activiated and the test claims to work - but clearly something else is happening and there is no page to really ‘display’ what the status is of the gateway.

If I restart the gateway plugin everything works for a while.

Thanks,

Mike

So - it just fell over.

Basically it falls over spews lots of cyclic logs and seems to screw up the logging. As the 10mb file limit is reached in the logger it rotates the file spewing the same log, but after the 5th rotation (so debug_1 -> debug_5 .log are full up) debug.log is never created.

Here is an excerpt of the logs:

2007.10.01 22:17:50 session 562 caught exception java.lang.NullPointerException

2007.10.01 22:17:50 MSN: Exception occurred for HIDDEN@hotmail.com : java.lang.NullPointerException

2007.10.01 22:17:50 MSN: Unknown error: java.lang.NullPointerException

java.lang.NullPointerException

at org.jivesoftware.openfire.gateway.protocols.msn.MSNSessionListener.exceptionCau ght(MSNSessionListener.java:53)

at net.sf.cindy.impl.AbstractSession$1.doRun(AbstractSession.java:264)

at net.sf.cindy.impl.AbstractSession$DispatchObject.run(AbstractSession.java:395)

at net.sf.cindy.impl.SimpleDispatcher.dispatch(SimpleDispatcher.java:35)

at net.sf.cindy.impl.AbstractSession.dispatch(AbstractSession.java:249)

at net.sf.cindy.impl.AbstractSession.dispatchException(AbstractSession.java:258)

at net.sf.cindy.impl.AbstractSession$DispatchObject.run(AbstractSession.java:397)

at net.sf.cindy.impl.SimpleDispatcher.dispatch(SimpleDispatcher.java:35)

at net.sf.cindy.impl.AbstractSession.dispatch(AbstractSession.java:249)

at net.sf.cindy.impl.AbstractSession.dispatchException(AbstractSession.java:258)

at net.sf.cindy.impl.AbstractSession$DispatchObject.run(AbstractSession.java:397)

at net.sf.cindy.impl.SimpleDispatcher.dispatch(SimpleDispatcher.java:35)

at net.sf.cindy.impl.AbstractSession.dispatch(AbstractSession.java:249)

at net.sf.cindy.impl.AbstractSession.dispatchException(AbstractSession.java:258)

at net.sf.cindy.impl.AbstractSession$DispatchObject.run(AbstractSession.java:397)

at net.sf.cindy.impl.SimpleDispatcher.dispatch(SimpleDispatcher.java:35)

at net.sf.cindy.impl.AbstractSession.dispatch(AbstractSession.java:249)

at net.sf.cindy.impl.AbstractSession.dispatchException(AbstractSession.java:258)

at net.sf.cindy.impl.AbstractSession$DispatchObject.run(AbstractSession.java:397)

at net.sf.cindy.impl.SimpleDispatcher.dispatch(SimpleDispatcher.java:35)

at net.sf.cindy.impl.AbstractSession.dispatch(AbstractSession.java:249)

at net.sf.cindy.impl.AbstractSession.dispatchException(AbstractSession.java:258)

at net.sf.cindy.impl.AbstractSession$DispatchObject.run(AbstractSession.java:397)

at net.sf.cindy.impl.SimpleDispatcher.dispatch(SimpleDispatcher.java:35)

at net.sf.cindy.impl.AbstractSession.dispatch(AbstractSession.java:249)

at net.sf.cindy.impl.AbstractSession.dispatchException(AbstractSession.java:258)

at net.sf.cindy.impl.AbstractSession$DispatchObject.run(AbstractSession.java:397)

at net.sf.cindy.impl.SimpleDispatcher.dispatch(SimpleDispatcher.java:35)

at net.sf.cindy.impl.AbstractSession.dispatch(AbstractSession.java:249)

at net.sf.cindy.impl.AbstractSession.dispatchException(AbstractSession.java:258)

at net.sf.cindy.impl.AbstractSession$DispatchObject.run(AbstractSession.java:397)

at net.sf.cindy.impl.SimpleDispatcher.dispatch(SimpleDispatcher.java:35)

at net.sf.cindy.impl.AbstractSession.dispatch(AbstractSession.java:249)

at net.sf.cindy.impl.AbstractSession.dispatchException(AbstractSession.java:258)

at net.sf.cindy.impl.AbstractSession$DispatchObject.run(AbstractSession.java:397)

at net.sf.cindy.impl.SimpleDispatcher.dispatch(SimpleDispatcher.java:35)

at net.sf.cindy.impl.AbstractSession.dispatch(AbstractSession.java:249)

at net.sf.cindy.impl.AbstractSession.dispatchException(AbstractSession.java:258)

at net.sf.cindy.impl.AbstractSession$DispatchObject.run(AbstractSession.java:397)

at net.sf.cindy.impl.SimpleDispatcher.dispatch(SimpleDispatcher.java:35)

at net.sf.cindy.impl.AbstractSession.dispatch(AbstractSession.java:249)

at net.sf.cindy.impl.AbstractSession.dispatchException(AbstractSession.java:258)

at net.sf.cindy.impl.AbstractSession$DispatchObject.run(AbstractSession.java:397)

at net.sf.cindy.impl.SimpleDispatcher.dispatch(SimpleDispatcher.java:35)

at net.sf.cindy.impl.AbstractSession.dispatch(AbstractSession.java:249)

at net.sf.cindy.impl.AbstractSession.dispatchException(AbstractSession.java:258)

at net.sf.cindy.impl.AbstractSession$DispatchObject.run(AbstractSession.java:397)

so a bit more notice on this.

When I restart the gateway the debug.log is never created. I’ve now rolled back to 1.1.0 and other than the lack of features things seem to be cool.

mike

The debug log is never created? That’s not really something that the plugin itself has anything to do with. It passes logging off to openfire core.

Right,

So what I seem to have found is that very big writes to the log file result in the logger not rolling files enough and then crashing. The crash seems to prevent the rest of the server from working correctly.

The cyclic exception would cause all the files to rotate within a second. Once there was debug_1 -> debug_5 no debug.log would get created for writing.

To stop this I put NPE checks before the debug statements in the Gateway code and now it seems fine. I guess finding out why the NPE is happening is also a good path to persue.

I find it odd that no one else has run into this before!!! Anyone? Anyone???

I mean this is a pretty crazy debug log endeavour and would likely easily have been noticed.

I really want to move JML away from Cindy anyway… to MINA. I started on it but got sidetracked and created a branch of my work. Anyone want to finish it up? Anyone? I have virtual candy to offer! =)

I’m getting pretty familiar with the code atm. Infact we’ve blocked out a chunk of my time to completely learn the Gateway Plugin and start “enterprising” it - so if you feel this migration falls into that sort of category then let me know.

I don’t know about “enterprising” it. It would just be handy overall. chuckle There sure are going to be a lot of forks of the IM Gateway plugin at this rate. =) Not that I mind; it’s kind of neat!

our primary goal is to increase concurrency in the product. As an example, the fix that I sent you a while back to verify credentials before registering them had a line in it that paused the main transport thread. Net effect was that the transport was limited to supporting a set number of people signing up. We moved that process into its own thread and now can sign up a whole host of people - first getting confirmation that their credentials are correct!

huge plus for us - I can certainly put the patch in the post to you if you wish?

The other one that we want to start working on is the gateway registration screen - it basically crushes mysql and the main openfire java thread when you click on it and have as many (but way far from enough to make us happy) users on the system.

The logger fix is another example of something that we want to get working nicely/better.

Mike

Well… I mean … most of the stuff you’ve brought up I have entirely different methods of doing that are on the roadmap. I did not agree with the method of verifying the account before approving the registration before, for example. =) I’m always interested in looking at patches, but to date we seem to be going different directions.