java.lang.NullPointerException
at sfs2x.client.controllers.system.ResSetUserPosition.handleResponse(ResSetUserPosition.java:57)
at sfs2x.client.controllers.SystemController.handleMessage(SystemController.java:124)
at sfs2x.client.core.SFSProtocolCodec.dispatchRequest(SFSProtocolCodec.java:144)
at sfs2x.client.core.SFSProtocolCodec.onPacketRead(SFSProtocolCodec.java:50)
at sfs2x.client.core.SFSIOHandler.handlePacketData(SFSIOHandler.java:298)
at sfs2x.client.core.SFSIOHandler.onDataRead(SFSIOHandler.java:131)
at sfs2x.client.bitswarm.BitSwarmClient.onSocketData(BitSwarmClient.java:402)
at sfs2x.client.bitswarm.BitSwarmClient.access$2(BitSwarmClient.java:396)
at sfs2x.client.bitswarm.BitSwarmClient$3.dispatch(BitSwarmClient.java:113)
at sfs2x.client.core.EventDispatcher.dispatchEvent(EventDispatcher.java:60)
at sfs2x.client.core.sockets.TCPSocketLayer.callOnData(TCPSocketLayer.java:194)
at sfs2x.client.core.sockets.TCPSocketLayer.handleBinaryData(TCPSocketLayer.java:187)
at sfs2x.client.core.sockets.TCPSocketLayer.access$7(TCPSocketLayer.java:185)
at sfs2x.client.core.sockets.TCPSocketLayer$NettyIOHandler.messageReceived(TCPSocketLayer.java:354)
at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:100)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:545)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:540)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:274)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:261)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:350)
at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:281)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:201)
at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
I think we should understand the cause of the exception. Also are you running the latest SFS2X 2.8.4? We have added a couple of fixes related to switching MMORooms that may cause problems to clients.
We have added a couple of fixes related to switching MMORooms that may cause problems to clients.
Which API version are you using please?
1.3.2 Java Client API, which is latest
I think we should understand the cause of the exception.
In the load testing client, some times when I tried to run multiple clients (>50) I got this exception. Looks like MMO proximity list update has been dispatched for some room user(suppose User 1) regrading the users(User 2 and User3...) who left the room. But in between that time interval if the user(User1) it-self disconnect then I got this exception.
Currently I set the Proximity list update time interval is 20millisecond.
The strange part is that the line of the error doesn't correspond to any code.
As to how to intercept the Exception, it can't be done because it happens in an I/O thread over which you have no control.
However whether you catch the NPE or not doesn't make a difference. In the end the null value would prevent the event to be fired anyways.
Lapo wrote:The strange part is that the line of the error doesn't correspond to any code.
As to how to intercept the Exception, it can't be done because it happens in an I/O thread over which you have no control.
However whether you catch the NPE or not doesn't make a difference. In the end the null value would prevent the event to be fired anyways.
So, can you please suggest something to overcome the same?
Not knowing the cause of the problem, nor the precise line where the code is failing, it's difficult to answer.
It may be due to the asynchronous nature of the updates from MMORoom although we have spent quite a lot of time testing this aspect and at the moment we're not aware of any bugs.
Additionally I am not convinced this is a bug either. As I alluded in the previous post it is possible that the client is receiving an update for an MMORoom he's no longer in. If this is the case, and I am speculating, then the exception is essentially not causing any harm, besides showing up in the logs.
If you have a reproducible case that we can test, we'll be glad to investigate this further.
Lapo wrote:Not knowing the cause of the problem, nor the precise line where the code is failing, it's difficult to answer.
It may be due to the asynchronous nature of the updates from MMORoom although we have spent quite a lot of time testing this aspect and at the moment we're not aware of any bugs.
Additionally I am not convinced this is a bug either. As I alluded in the previous post it is possible that the client is receiving an update for an MMORoom he's no longer in. If this is the case, and I am speculating, then the exception is essentially not causing any harm, besides showing up in the logs.
If you have a reproducible case that we can test, we'll be glad to investigate this further.
Thanks
Thanks Lapo, I will try to prepare a scenario, where you can able to reproduce this issue.
Lapo wrote:Thanks.
I should also have asked this: does the exception cause unexpected behaviors in the app?
I haven't checked this. Because we are using SFS Java Client (1.3.2) only for load testing, where I just need to track the time duration.
In the application we are using SFS Flash Client, we need to check the same using SFS Flash client to see whether we are getting similar kind of exception there or not. Also whether that causing any weird behavior in application or not.
