deepstreamIO / deepstream.io-client-js

The Browser / Node.js Client for deepstream.io
Other
294 stars 109 forks source link

ACCEPT_TIMEOUT weired behavior #551

Closed slachtar closed 3 years ago

slachtar commented 3 years ago

I'm working on a slow server (sandbox for tests) and set the following values on server config

  # Timeout for client RPC acknowledgement
  ackTimeout: 180000
  # Timeout for actual RPC provider response
  responseTimeout: 180000

I do use default acceptTimout on client side (which is 6000 I think). When I make an rpc call twice for the same function, the second call raises an ACCEPT_TIMEOUT error and the rpc callback is called which is fine for me.

The problem is that after some time (few seconds), the rpc callback is called again but now with result returned from backend. Is this the expected behavior?

When this happens, I can continue making other rpc calls, but cannot subscribe to records anymore!

jaime-ez commented 3 years ago

Hi, I was just testing a similar problem and came to see if it had been raised before! I'm seeing the behaviour with rpcResponseTimeout:

If I declare on the client options a value for rpcResponseTimeout that is less than the server default or declared, I get a RESPONSE_TIMEOUT error, and then the response from the server. This should not happen in my opinion becasue it leads to bugs: you handle the error but then the success response is called anyway.

I think the solution is to add a isComplete flag on rpc.ts file, I'll make a pull with the proposed changes

slachtar commented 3 years ago

Yes, that was exactly the behavior with the accept timeout too. After that error, the deepstream client stops working properly.

It will be great if you could fix it.

Thank you,

Le ven. 11 déc. 2020 à 03:10, jaime echegaray zipper < notifications@github.com> a écrit :

Hi, I was just testing a similar problem and came to see if it had been raised before! I'm seeing the behaviour with rpcResponseTimeout:

If I declare on the client options a value for rpcResponseTimeout that is less than the server default or declared, I get a RESPONSE_TIMEOUT error, and then the response from the server. This should not happen in my opinion becasue it leads to bugs: you handle the error but then the success response is called anyway.

I think the solution is to add a isComplete flag on rpc.ts file, I'll make a pull with the proposed changes

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/deepstreamIO/deepstream.io-client-js/issues/551#issuecomment-742918343, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATKH2VBBE6CRZ2PZN3PW23SUF5PPANCNFSM4UU6TAFQ .

jaime-ez commented 3 years ago

Well, the problem has been eliminated on version 5.2.0 (to be released). The client no longer controls rpc timeouts. I'll update the website soon

slachtar commented 3 years ago

Thank you, nice work.

On Wed, Dec 30, 2020, 02:02 jaime echegaray zipper notifications@github.com wrote:

Closed #551 https://github.com/deepstreamIO/deepstream.io-client-js/issues/551.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/deepstreamIO/deepstream.io-client-js/issues/551#event-4156042477, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATKH2QCA6P7VOZMWJDI3LLSXJ3ZBANCNFSM4UU6TAFQ .