search

crossbario / crossbar

Crossbar.io - WAMP application router
https://crossbar.io/
Other
2.05k stars 274 forks source link

Timeout at different levels #226

Open sehoffmann opened 9 years ago

sehoffmann commented 9 years ago

In my recent work with and on crossbar and autobahn aswell, I was often able to bring the session between client and router in a dead state, e.g if something on the router didn't worked out as intended. Due to this I realized that crossbar, autobahn py and autobahn js totally lack timeouts. Even though I opened this issue on the crossbar project, I believe every of the mentioned projects would need such a feature.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/8141908-timeout-at-different-levels?utm_campaign=plugin&utm_content=tracker%2F462544&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F462544&utm_medium=issues&utm_source=github).
oberstet commented 9 years ago

Crossbar.io has timeouts at the transport level (e.g. TCP and WebSocket).

sehoffmann commented 9 years ago

If I have not lacked any crucial point in the documentation, we have timeouts for opening and closing handshakes aswell as pings. However I talked about timeouts at application level. Imagine the following situation: You want to invoke a function but to some unspecified reason you simply just don't get a reply from the router (those things occured to me!). Your application will now just endlessly wait for a response. Please correct me if Im wrong.

oberstet commented 9 years ago

If the call doesn't come back because the callee never responds, this is about "WAMP call timeouts" - a feature of the WAMP advanced profile which isn't completely spec'ed nor implemented in Crossbar.io. Yes, this is crucial to have.

If the call doesn't come back even though the callee responded, it is a bug in Crossbar.io - if you ran into this, please provide some code for me to reproduce a we will fix it.

If the timeout should be for something like finishing the WAMP opening handshake, this is yet another type of timeout. We need that also.

So "timeout" is at different levels:

  1. WAMP transport
  2. WAMP opening handshake (including possibly authentication)
  3. WAMP actions (like calls)

We want all three, but only the first is there.

estan commented 9 years ago

I also recently realized that there's a lack of timeouts at WAMP level, and consider this an important feature. In my case, I'll be building a component to which you can do RPC call, each such RPC callee in this "main service" will do RPC calls to other components, and it is in these calls I need the ability to set a custom timeout. I need to be able to implement retry logic such as "try three times with a timeout of 3 seconds, then consider it a complete failure" and report the failure back to the original caller.

estan commented 9 years ago

As I'm getting further into my current project, I'm realizing how much of a pain the lack of timeouts at app level is going to be.

For instance, I'm controlling an x-ray source by sending it the desired tension (kV) and current (uA), and the application should then wait until the x-ray source has reached the requested values. I want to abstract the request and waiting in an RPC call, where the callee does the polling in a separate thread. But without any control over timeouts I'm afraid this is simply not possible. I must be able to abort if the operation takes more than a certain amount of time, since I know quite well how long it should take.

I have several other situations like this where I will need timeouts.

Do you think this feature is 1.0 material? Or when can we expect timeouts at the WAMP action level?

I'm afraid I might have to reconsider the use of Crossbar/Autobahn :/

estan commented 9 years ago

I guess I should be able to build this with some timers and explicitly cancelling the calls, but I'm afraid it'll become quite complex after a while. I'm building one component which should provide a sort of higher-level service by issuing a set of predefined calls to other components (for hardware control), and without a natural way to express timeouts for the different steps in servicing these higher-level requests, it will be quite a chore.

pratman commented 11 months ago

Even tho a solution for this within autobahn(not only Crossbar) is extremely important, as mentioned... As workaround you can wait_for on the futures returned by the actions (e.g. call). This doesn't consider internal state of connection/socket/... And it's for sure suboptimal, but it's a temporary solution.