search

rubenlagus / TelegramBots

Java library to create bots using Telegram Bots API
https://telegram.me/JavaBotsApi
MIT License
4.68k stars 1.18k forks source link

BotSession.close() logs ERROR java.net.SocketException: Socket closed #168

Closed ceefour closed 6 years ago

ceefour commented 7 years ago

Currently it's only possible to register a handler, but not to unregister a handler.

For https://github.com/fast4indonesia/yoopabot , I need to be able to dynamically add/edit/remove handlers without restarting the JVM.

rubenlagus commented 7 years ago

Do you mean for LongPolling or Webhook bots?

ceefour commented 7 years ago

For LongPolling bots

On Sun, Nov 27, 2016, 23:12 Ruben Bermudez notifications@github.com wrote:

Do you mean for LongPolling or Webhook bots?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rubenlagus/TelegramBots/issues/168#issuecomment-263130648, or mute the thread https://github.com/notifications/unsubscribe-auth/AABeO-0SXBebbUQ38IpyOyEYIvI1Od3Dks5rCav9gaJpZM4K9KqB .

rubenlagus commented 7 years ago

If you check the code, when registering a longpolling bot, the api is making nothing but create and return BotSession object. That session have convenient methods to start/stop at wish.

ceefour commented 7 years ago

After calling BotSession.close() it logs Exception:

2017-01-13 09:39:30.850 ERROR 10088 --- [gram Connection] Telegram Bots Api                        : BOTSESSION

java.net.SocketException: Socket closed
    at java.net.SocketInputStream.socketRead0(SocketInputStream.java) ~[na:1.8.0_112]
    at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) ~[na:1.8.0_112]
    at java.net.SocketInputStream.read(SocketInputStream.java:170) ~[na:1.8.0_112]
    at java.net.SocketInputStream.read(SocketInputStream.java:141) ~[na:1.8.0_112]
    at sun.security.ssl.InputRecord.readFully(InputRecord.java:465) ~[na:1.8.0_112]
    at sun.security.ssl.InputRecord.read(InputRecord.java:503) ~[na:1.8.0_112]
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973) ~[na:1.8.0_112]
    at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:930) ~[na:1.8.0_112]
    at sun.security.ssl.AppInputStream.read(AppInputStream.java:105) ~[na:1.8.0_112]
    at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137) ~[httpcore-4.4.5.jar:4.4.5]
    at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153) ~[httpcore-4.4.5.jar:4.4.5]
    at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282) ~[httpcore-4.4.5.jar:4.4.5]
    at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140) ~[httpclient-4.5.2.jar:4.5.2]
    at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57) ~[httpclient-4.5.2.jar:4.5.2]
    at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259) ~[httpcore-4.4.5.jar:4.4.5]
    at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163) ~[httpcore-4.4.5.jar:4.4.5]
    at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167) ~[httpclient-4.5.2.jar:4.5.2]
    at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273) ~[httpcore-4.4.5.jar:4.4.5]
    at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125) ~[httpcore-4.4.5.jar:4.4.5]
    at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271) ~[httpclient-4.5.2.jar:4.5.2]
    at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184) ~[httpclient-4.5.2.jar:4.5.2]
    at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) ~[httpclient-4.5.2.jar:4.5.2]
    at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) ~[httpclient-4.5.2.jar:4.5.2]
    at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184) ~[httpclient-4.5.2.jar:4.5.2]
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) ~[httpclient-4.5.2.jar:4.5.2]
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107) ~[httpclient-4.5.2.jar:4.5.2]
    at org.telegram.telegrambots.updatesreceivers.DefaultBotSession$ReaderThread.run(DefaultBotSession.java:172) ~[telegrambots-2.4.4.jar:na]

Seems to be harmless, but it'd preferable to log it as INFO instead, since close()-ing is intentional.

rubenlagus commented 7 years ago

That socket exception could be raised due to different causes (intentional closing among them). If I change it to INFO, it may cause that it is hidden in other important cases. In any case, I'm open to suggestions or pull requests.

rubenlagus commented 7 years ago

@ceefour any improvement in latest versions? Any suggestion?

mr-yusupov commented 7 years ago

Hello @rubenlagus Is there any news on this issue? Still getting the same exception in CDI context.

BOTSESSION: java.net.SocketException: Socket closed

rubenlagus commented 7 years ago

There is no actual problem with this exception when called during "close" request since we are actually forcing it close regardless its state. The only option is to reduce logging level but that can hide it in other cases where important.

myplacedk commented 6 years ago

This problem seems to be reduced to a race condition since opening this issue.

It seems to be a symptom of imperfect thread handling. I tried cleaning it up a bit, and that seemed to solve it. Although I'm not sure if it will affect performance negatively when under heavy load.

The problem was that the session could be closed while getUpdatesFromServer() was running. One workaround is to check running again just before httpclient.execute(httpPost), but I solved it by synchronizing more code.

etielolecram commented 6 years ago

Hi, have just updated to 3.5 and issue remains.