error logged from es5.3.2

[pk1981]

Hi

from our log, we found a new type of exception from es5 that we have not seen before. it happens several times. could you please explain to me what it means and how it happens?

Thanks,
Zili Weng


java.lang.Exception: <no original exception provided, fill-in to provide stack>
at com.electrotank.electroserver5.entities.managers.R oomEventFactory.createAndLogError(RoomEventFactory .java:462)
at com.electrotank.electroserver5.entities.managers.R oomEventFactory.createAndLogError(RoomEventFactory .java:450)
at com.electrotank.electroserver5.entities.managers.R oomEventFactory.generateLeaveErrorResponse(RoomEve ntFactory.java:423)
at com.electrotank.electroserver5.entities.managers.R oomManager.leaveRoom(RoomManager.java:1011)
at com.electrotank.electroserver5.servers.registry.tr ansactions.LeaveRoomTransaction.execute(LeaveRoomT ransaction.java:31)
at com.electrotank.electroserver5.servers.registry.tr ansactions.SinglePersonTransaction.execute(SingleP ersonTransaction.java:34)
at com.electrotank.electroserver5.servers.registry.tr ansactions.SinglePersonTransaction.execute(SingleP ersonTransaction.java:16)
at com.electrotank.electroserver5.servers.registry.tr ansactions.TransactionHandlerImpl.processMessage(T ransactionHandlerImpl.java:170)
at com.electrotank.electroserver5.servers.registry.Re gistryEndpoint.doReceive(RegistryEndpoint.java:213 )
at com.electrotank.electroserver5.servers.registry.Re gistryEndpoint.receive(RegistryEndpoint.java:97)
at com.electrotank.electroserver5.servers.gateway.Gat ewayEndpoint.write(GatewayEndpoint.java:74)
at com.electrotank.electroserver5.servers.gateway.Gat ewayEndpoint.write(GatewayEndpoint.java:86)
at com.electrotank.electroserver5.servers.gateway.tra nsactions.ClientMessageToRegistryForwarder.forward (ClientMessageToRegistryForwarder.java:31)
at com.electrotank.electroserver5.protocol.netty.Mess ageHandler.messageReceived(MessageHandler.java:79)
at org.jboss.netty.channel.SimpleChannelUpstreamHandl er.handleUpstream(SimpleChannelUpstreamHandler.jav a:75)
at org.jboss.netty.channel.DefaultChannelPipeline.sen dUpstream(DefaultChannelPipeline.java:558)
at org.jboss.netty.channel.DefaultChannelPipeline$Def aultChannelHandlerContext.sendUpstream(DefaultChan nelPipeline.java:777)
at org.jboss.netty.channel.Channels.fireMessageReceiv ed(Channels.java:296)
at com.electrotank.electroserver5.protocol.netty.Bina ryProtocolHandler.messageReceived(BinaryProtocolHa ndler.java:63)
at org.jboss.netty.channel.SimpleChannelHandler.handl eUpstream(SimpleChannelHandler.java:95)
at org.jboss.netty.channel.DefaultChannelPipeline.sen dUpstream(DefaultChannelPipeline.java:558)
at org.jboss.netty.channel.DefaultChannelPipeline$Def aultChannelHandlerContext.sendUpstream(DefaultChan nelPipeline.java:777)
at org.jboss.netty.channel.SimpleChannelHandler.messa geReceived(SimpleChannelHandler.java:149)
at com.electrotank.electroserver5.protocol.netty.Comp ressionHandler.messageReceived(CompressionHandler. java:54)
at org.jboss.netty.channel.SimpleChannelHandler.handl eUpstream(SimpleChannelHandler.java:95)
at org.jboss.netty.channel.DefaultChannelPipeline.sen dUpstream(DefaultChannelPipeline.java:558)
at org.jboss.netty.channel.DefaultChannelPipeline$Def aultChannelHandlerContext.sendUpstream(DefaultChan nelPipeline.java:777)
at org.jboss.netty.channel.SimpleChannelHandler.messa geReceived(SimpleChannelHandler.java:149)
at com.electrotank.electroserver5.protocol.netty.Mess ageFlagsHandler.messageReceived(MessageFlagsHandle r.java:27)
at org.jboss.netty.channel.SimpleChannelHandler.handl eUpstream(SimpleChannelHandler.java:95)
at org.jboss.netty.channel.DefaultChannelPipeline.sen dUpstream(DefaultChannelPipeline.java:558)
at org.jboss.netty.channel.DefaultChannelPipeline$Def aultChannelHandlerContext.sendUpstream(DefaultChan nelPipeline.java:777)
at org.jboss.netty.channel.Channels.fireMessageReceiv ed(Channels.java:296)
at org.jboss.netty.handler.codec.oneone.OneToOneDecod er.handleUpstream(OneToOneDecoder.java:71)
at org.jboss.netty.channel.DefaultChannelPipeline.sen dUpstream(DefaultChannelPipeline.java:558)
at org.jboss.netty.channel.DefaultChannelPipeline$Def aultChannelHandlerContext.sendUpstream(DefaultChan nelPipeline.java:777)
at org.jboss.netty.channel.Channels.fireMessageReceiv ed(Channels.java:296)
at org.jboss.netty.handler.codec.frame.FrameDecoder.u nfoldAndFireMessageReceived(FrameDecoder.java:327)
at org.jboss.netty.handler.codec.frame.FrameDecoder.c allDecode(FrameDecoder.java:305)
at org.jboss.netty.handler.codec.frame.FrameDecoder.m essageReceived(FrameDecoder.java:207)
at org.jboss.netty.channel.SimpleChannelUpstreamHandl er.handleUpstream(SimpleChannelUpstreamHandler.jav a:75)
at org.jboss.netty.channel.DefaultChannelPipeline.sen dUpstream(DefaultChannelPipeline.java:558)
at org.jboss.netty.channel.DefaultChannelPipeline$Def aultChannelHandlerContext.sendUpstream(DefaultChan nelPipeline.java:777)
at org.jboss.netty.handler.codec.oneone.OneToOneDecod er.handleUpstream(OneToOneDecoder.java:69)
at org.jboss.netty.channel.DefaultChannelPipeline.sen dUpstream(DefaultChannelPipeline.java:558)
at org.jboss.netty.channel.DefaultChannelPipeline$Def aultChannelHandlerContext.sendUpstream(DefaultChan nelPipeline.java:777)
at org.jboss.netty.channel.SimpleChannelHandler.messa geReceived(SimpleChannelHandler.java:149)
at com.electrotank.electroserver5.protocol.netty.HexL oggingHandler.messageReceived(HexLoggingHandler.ja va:24)
at org.jboss.netty.channel.SimpleChannelHandler.handl eUpstream(SimpleChannelHandler.java:95)
at org.jboss.netty.channel.DefaultChannelPipeline.sen dUpstream(DefaultChannelPipeline.java:558)
at org.jboss.netty.channel.DefaultChannelPipeline.sen dUpstream(DefaultChannelPipeline.java:553)
at org.jboss.netty.channel.Channels.fireMessageReceiv ed(Channels.java:268)
at org.jboss.netty.channel.Channels.fireMessageReceiv ed(Channels.java:255)
at org.jboss.netty.channel.socket.nio.NioWorker.read( NioWorker.java:343)
at org.jboss.netty.channel.socket.nio.NioWorker.proce ssSelectedKeys(NioWorker.java:274)
at org.jboss.netty.channel.socket.nio.NioWorker.run(N ioWorker.java:194)
at org.jboss.netty.util.ThreadRenamingRunnable.run(Th readRenamingRunnable.java:102)
at org.jboss.netty.util.internal.DeadLockProofWorker$ 1.run(DeadLockProofWorker.java:42)
at java.util.concurrent.ThreadPoolExecutor$Worker.run Task(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (Unknown Source)
at java.lang.Thread.run(Unknown Source)

[tcarr]

The error is being triggered by a user sending a LeaveRoomRequest. I don't know what the edge case is that is triggering this. The only change I can see that was made in the way LeaveRoomRequest was handled, between 5.3.1 and 5.3.2, is that we fixed a null pointer event that was happening when the core server tries to remove a user from a room that does not exist but from a zone that does exist.

RoomManager.leaveRoom(RoomManager.java:1011) is a RoomNotFound error. So in general the problem is that the LeaveRoomRequest was for a room that doesn't exist.

[tcarr]

In looking more closely at the RoomManager and RoomEventFactory source code, the client does get an error message delivered. The server logs are set to show the full trace because it is useful for debugging. There are a lot of RoomEventFactory full traces like that, at the WARN level. For a game in production, you probably just want to set your log4j.properties file so that the logging for RoomEventFactory is at the ERROR level.

If your game is still in the development stage, check that your client is actually in the room that it is trying to leave.

[chengen]

If client is trying to leave a room that doesn't exist, would it cause other problems with client/server communication?
I would think the server just logs that and send a notice to client, and the client ignores that and everyone just move on. Is that correct?

[tcarr]

It depends on why the client sent the LeaveRoomRequest for that roomId and zoneId. If there is a bug on the client so that it was remembering the wrong roomId and zoneId (or just using 0, 0 as default) and the user wanted to leave some other room instead, that user might end up getting public chat messages or plugin message events from the room it thought it left, and end up very confused.

If the client sent two LeaveRoomRequests, or a LeaveRoomRequest after a plugin kicked all users out of the room and destroyed the room, then this is safely ignorable.