MazWoz / jsmpp

Automatically exported from code.google.com/p/jsmpp
Apache License 2.0
0 stars 0 forks source link

EnquireLink might not work on some conditions ( race condition ) #13

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. When starting a session on a multi-processor machine, sometime the
Activity Notification Thread get stuck on a inputStrem.read() call.
2.
3.

What is the expected output? 
The activity monitor should kick in and send an enquire_link PDU.
What do you see instead?
When this condition occurs the enquire_link PDU does not  get sent and the
SMSC will close the connexion after a small period of tile.

What version of the product are you using? On what operating system?
JSMPP 2.0 On a linux 2 processor system, JDK 1.6.0_6

The problem is caused because the EnquireLinkSender Thread can get stuck in
readPDU() if the call is made before the connection.setSoTimeout() is
called. Therefore the in.read() will block forever.

The attached patch fixes the issue by calling the setSoTimeout() right
after the connection is opened and by adding a state check in
notifyNoActivity() to ensure that the session is opened before sending the
enquire_link PDU.

Please provide any additional information below.

Original issue reported on code.google.com by cerua...@gmail.com on 12 Dec 2008 at 10:58

Attachments:

GoogleCodeExporter commented 8 years ago
Hi,

Are you sure about that. SMPPSession#notifyNoActivity:void is only call when 
SocketTimeoutException occured. Checking isReadPDU on method notifyNoActivity 
seems 
will give a same result when SocketTimeoutException occured, no one will change 
the 
session state (see the isReadPDU implementation).

SO Timeout conn.setSoTimeout(getEnquireLinkTimer()) already been done on 
SMPPSesssion.BoundSessionStateListener, it was called when the state change to 
BOUND. 
See at connectAndBind(String host, int port, BindParam param, long timeout), 
there 
was sessionContext.bound(bindParam.getBindType()) that will raise event that 
invoke SMPPSesssion.BoundSessionStateListener#onStateChange(SessionState, 
SessionState, 
Object).

I think these (below) two lines of code will be invoked sequentially, even in a 
multi-processor.
sessionContext.bound(bindParam.getBindType());      
enquireLinkSender = new EnquireLinkSender();

CMIIW

How often this race condition happen? Is there any other indication that 
support your 
statement.

Regards, 
uudashr

Original comment by uuda...@gmail.com on 12 Dec 2008 at 11:56

GoogleCodeExporter commented 8 years ago
The problem is unclear, so I'll close this case

Original comment by uuda...@gmail.com on 22 Jan 2009 at 4:57