Hello,
Because of the heavy load, a couple of hundred per minute ( yes, it really is and even more, depending on the time of day ), the LongPoll VC server gives an error:

{"failed":1,"ts":<new_ts>} 

This error means the following: -

the event history is outdated or partially lost, the application can receive events further using the new ts value from the response.


And the fact is that the bot is running for 2-3 minutes, and this error starts to fall out, its reason is as follows: before sending the message, the bot checked (sending a request) whether the user is in the group, because there were several messages per second, requests there was a lot, and he responded to them after he processed the response to the request to verify the user, because of this the history of events “became obsolete or partially lost”. Then I removed this check - the bot lasted about 20 minutes, and then fell for some strange reason with a bunch of lines:

  at com.vk.api.sdk.httpclient.HttpTransportClient.post(HttpTransportClient.java:170) at com.vk.api.sdk.client.ApiRequest.executeAsString(ApiRequest.java:95) at com.vk.api.sdk.client.ApiRequest.execute(ApiRequest.java:59) at LongPollHandler.run(LongPollHandler.java:180) Caused by: java.net.SocketTimeoutException: connect timed out at java.net.DualStackPlainSocketlmpl.waitForConnect(Native Method) at java.net.DualStackPlainSocketlmpl.socketConnect(Unknown Source) at java.net.AbstractPlainSocketlmpl.doConnect(Unknown Source) at java.net.AbstractPlainSocketlmpl.connectToAddress(Unknown Source) at java.net.AbstractPlainSocketlmpl.connect(Unknown Source) at java.net.PlainSocketlmpl.connect(Unknown Source) at java.net.SocksSocketlmpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSL ConnectionSocketFactory.java:337) at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect (DefaultHttpClientConnectionOperator.java:141) ... 15 more com.vk.api.sdk.exceptions.ClientException: I/O exception at com.vk.api.sdk.client.ApiRequest.executeAsString(ApiRequest.java:98) at com.vk.api.sdk.client.ApiRequest.execute(ApiRequest.java:59) at LongPollHandler.run(LongPollHandler.java:180) 

From the lines of my code that are mentioned in this error, only LongPollHandler.java:180, which only contains the following query:

 int album_size = new JSONObject(vk.photos().get().ownerId(id страницы с альбомами).albumId(id альбома).getInt("count"); 

That is, we find the length of the album by its id. The remaining lines say something that I do not understand. The full error log is not particularly possible to get, because again, there are a lot of requests and it responds to each one with an error; it’s impossible to catch a piece, which is also not completely given.

Question: how to ease the load? The fact is that if you restart the application, the bot works again, but before the new errors. Perhaps somehow to redistribute these requests? Or something else to do so that in this case, one part of the received answers was processed by one application or stream, the other part was processed by another, and that the application did not fall with incomprehensible errors or due to load?
I will be very grateful.


UPDATE: Now I caught another error:

 java.net.SocketTimeoutException: timeout at okio.Okio$4.newTimeoutException(Okio.java:227) at okio.AsyncTimeout.exit(AsyncTimeout.java:284) at okio.AsyncTimeout$2.read(AsyncTimeout.java:240) at okio.RealBufferedSource.indexOf(RealBufferedSource.java:325) at okio.RealBufferedSource.indexOf(RealBufferedSource.java:314) at okio.RealBufferedSource.readUtf8LineStrict(RealBufferedSource.java:210) at okhttp3.internal.http.Http1xStream.readResponse(Http1xStream.java:185) at okhttp3.internal.http.Http1xStream.readResponseHeaders(Http1xStream.java:126) at okhttp3.internal.http.HttpEngine.readNetworkResponse(HttpEngine.java:707) at okhttp3.internal.http.HttpEngine.access$200(HttpEngine.java:81) at okhttp3.internal.http.HttpEngine$NetworkInterceptorChain.proceed(HttpEngine.java:692) at okhttp3.internal.http.HttpEngine.readResponse(HttpEngine.java:547) at okhttp3.RealCall.getResponse(RealCall.java:242) at okhttp3.RealCall$ApplicationInterceptorChain.proceed(RealCall.java:199) at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:161) at okhttp3.RealCall.execute(RealCall.java:57) at Connection.getLongPollResponse(Connection.java:44) at LongPoll.getLongPollHistory(LongPoll.java:7) at LongPollHandler.run(LongPollHandler.java:92) Caused by: java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.socketRead(Unknown Source) at java.net.SocketInputStream.read(Unknown Source) at java.net.SocketInputStream.read(Unknown Source) at sun.security.ssl.InputRecord.readFully(Unknown Source) at sun.security.ssl.InputRecord.read(Unknown Source) at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source) at sun.security.ssl.SSLSocketImpl.readDataRecord(Unknown Source) at sun.security.ssl.AppInputStream.read(Unknown Source) at okio.Okio$2.read(Okio.java:138) at okio.AsyncTimeout$2.read(AsyncTimeout.java:236) ... 16 more java.lang.NullPointerException at java.io.StringReader.<init>(Unknown Source) at org.json.JSONTokener.<init>(JSONTokener.java:85) at org.json.JSONObject.<init>(JSONObject.java:319) at LongPollHandler.run(LongPollHandler.java:92) 

LongPollHandler.java:92

 JSONObject response = new JSONObject(longPoll.getLongPollHistory(server, key, ts)); 

The VK SDK method is similar to this: VK documentation . Here, it seems, you can guess that the application was waiting for a response from the LongPoll server for too long. Or I am mistaken. But the mistake that is higher is still not clear to me.

    1 answer 1

    The problem was approximately as follows: first, it was up to the OkHttp client to make a static class field, as recommended, set the required timeout, and secondly, make a request to get the key and server only once, changing only ts. In general, the algorithm of interaction with the longpoll-server was a little not very good, and this technology itself is not very good.