Problem Description:
In Normal case, when application starting, the org.rzo.yajsw.app.WrapperManagerImpl#reconnect will make connection to Controller and try to authorize the connection by wrapper.key.
However, in my application, what i found is the Controller regularly received some wrong message(a 'null' string message);
And the org.rzo.yajsw.controller.jvm.ControllerHandler#channelRead method treat it as a org.rzo.yajsw.Constants#WRAPPER_MSG_KEY message;
because the string 'null' is serailzied as bytes: [110, 117, 108, 108]; and the MessageDecoder will parse it as a
WRAPPER_MSG_KEY(110) packet(with message = 'ull');
So, the Controller treat it as wrong key and try to close netty connection; however, the client-side handler (org.rzo.yajsw.app.WrapperManagerImpl.WrapperHandler) will try to reconnect if channel is inactive. so a infinite loop is created.(this explain the phenomenon of Related Topic: https://sourceforge.net/p/yajsw/discussion/810311/thread/ff5805cc/)
the demo code to show a 'null' packet decoded as org.rzo.yajsw.Constants#WRAPPER_MSG_KEY message:
What i doing now is skip the problem by simply drop the null message(and add more context logging to track the root cause):
// org.rzo.yajsw.controller.jvm.ControllerHandler#channelRead@OverridepublicvoidchannelRead(ChannelHandlerContextctx,Objectin)throwsException{if(_controller.getState()==JVMController.STATE_USER_STOP){// set the channel if not set_controller._channel.set(ctx.channel());_controller.stop(JVMController.STATE_USER_STOP,"INTERNAL");return;}Messagemessage=(Message)in;switch(message.getCode()){caseWRAPPER_MSG_KEY:// check if JVM sent us correct keyif(_controller._key.equals(message.getMessage())){// we set the channel not in channelConnected,_controller._channel.set(ctx.channel());_controller.setState(JVMController.STATE_LOGGED_ON);_controller.startupOK();ctx.channel().writeAndFlush(newMessage(Constants.WRAPPER_MSG_OKKEY,""+_controller._wrappedProcess.getAppPid()));if(_controller.getDebug()>2)_controller.getLog().info("Correct key["+ctx.channel()+"]");}// if not: announce it and close sessionelse{if("ull".equals(message.getMessage())){if(_controller.getDebug()>2){_controller.getLog().info("Problem Key["+ctx.channel()+"] -> "+message.getMessage()+", expected:"+_controller._key);}}else{if(_controller.getDebug()>0){_controller.getLog().info("Wrong Key["+ctx.channel()+"]");}elseif(_controller.getDebug()>2){_controller.getLog().info("Wrong Key["+ctx.channel()+"] -> "+message.getMessage()+", expected:"+_controller._key);}ctx.channel().writeAndFlush(newMessage(Constants.WRAPPER_MSG_BADKEY,null));ctx.channel().close();}}break;...}}
All in all, the problem is caused by wrong message sent by client(i am sure about this, both the normal WRAPPER_MSG_KEY message and 'null' message is sending by same connection, see the logging output below):
Finally, becuase the controller's connection always in reconnect state, the other command(such as stop/restart) just hang there without any response(https://sourceforge.net/p/yajsw/discussion/810311/thread/ff5805cc/).
Last edit: bob 2017-05-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
However, I am wondering where the literal string "null" is being sent from. Analyzing the code this should never happen. The cycle of 5 sec. indicates that this could be the PING message. But, this message is only 2 bytes long: [0x67,0x0].
Anyway I have adpated the code to ignore further KEY messages once a correct key has been received.
Doing this I have noticed that the log setting for the communication between the wrapper and the app was wrong.
If you want I could provide you with a download for the update, for testing.
BTW: are you using the original yajsw code or did you change anything ?
-- Ron
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i am using source code packaged in the yajsw zip.
i just change the class file i need then replace the class in wrapper.jar with the new compiled one.
About why the "null" string is sent/received, i think it probably because there's bug in client, message decoder, or undering netty component, which read invalid message as "null"
Last edit: bob 2017-05-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Related Topic: https://sourceforge.net/p/yajsw/discussion/810311/thread/ff5805cc/
Problem Description:
In Normal case, when application starting, the org.rzo.yajsw.app.WrapperManagerImpl#reconnect will make connection to Controller and try to authorize the connection by wrapper.key.
However, in my application, what i found is the Controller regularly received some wrong message(a 'null' string message);
And the org.rzo.yajsw.controller.jvm.ControllerHandler#channelRead method treat it as a org.rzo.yajsw.Constants#WRAPPER_MSG_KEY message;
because the string 'null' is serailzied as bytes: [110, 117, 108, 108]; and the MessageDecoder will parse it as a
WRAPPER_MSG_KEY(110) packet(with message = 'ull');
So, the Controller treat it as wrong key and try to close netty connection; however, the client-side handler (org.rzo.yajsw.app.WrapperManagerImpl.WrapperHandler) will try to reconnect if channel is inactive. so a infinite loop is created.(this explain the phenomenon of Related Topic: https://sourceforge.net/p/yajsw/discussion/810311/thread/ff5805cc/)
the demo code to show a 'null' packet decoded as org.rzo.yajsw.Constants#WRAPPER_MSG_KEY message:
What i doing now is skip the problem by simply drop the null message(and add more context logging to track the root cause):
All in all, the problem is caused by wrong message sent by client(i am sure about this, both the normal WRAPPER_MSG_KEY message and 'null' message is sending by same connection, see the logging output below):
Finally, becuase the controller's connection always in reconnect state, the other command(such as stop/restart) just hang there without any response(https://sourceforge.net/p/yajsw/discussion/810311/thread/ff5805cc/).
Last edit: bob 2017-05-03
hello,
thanks for taking your time to check this out.
However, I am wondering where the literal string "null" is being sent from. Analyzing the code this should never happen. The cycle of 5 sec. indicates that this could be the PING message. But, this message is only 2 bytes long: [0x67,0x0].
Anyway I have adpated the code to ignore further KEY messages once a correct key has been received.
Doing this I have noticed that the log setting for the communication between the wrapper and the app was wrong.
If you want I could provide you with a download for the update, for testing.
BTW: are you using the original yajsw code or did you change anything ?
-- Ron
Hi rzo, sorry for responding so late.
i am using source code packaged in the yajsw zip.
i just change the class file i need then replace the class in wrapper.jar with the new compiled one.
About why the "null" string is sent/received, i think it probably because there's bug in client, message decoder, or undering netty component, which read invalid message as "null"
Last edit: bob 2017-05-23