Threads get stuck at DefaultSmppSession.sendRequestPd:530 about cloudhopper-smpp HOT 5 OPEN

You probably are onto something. Gladly will accept a PR that makes the change.

from cloudhopper-smpp.

Pull request added #115

from cloudhopper-smpp.

Hi!
Branch 'netty4' peace of code:
// write the pdu out & wait timeout amount of time
ChannelFuture channelFuture = this.channel.writeAndFlush(buffer);
if (configuration.getWriteTimeout() > 0){
channelFuture.await(configuration.getWriteTimeout());
} else {
channelFuture.await();
}
Method writeAndFlush won't throw exception if channel is closed by other side. So, if 'writeTimeout' is default and session listener doesn't handle 'fireChannelClosed' we'll get the same lock.
Please, let me know if @mthyman PR affects branch netty4?

from cloudhopper-smpp.

@olegagafonov I haven't tried the netty4 branch myself so I haven't seen the problem there, but looking at your code snippet setting a positive write timeout in your config should avoid the problem if it's there.

One a side note, we've been running a special build with my PR in production for almost two months now without seeing any threads get stuck so far.

from cloudhopper-smpp.

@mthyman You're right! Possitive timeout is a solution. But default timeout is a delayed dead-lock.
Your PR and my code snippet is the same code in differrent branches. But I don't know both branches lifecycle and merge strategy. @jjlauer what do you think?

from cloudhopper-smpp.