Make it possible to remove timeout altogether

[wilsonpage]

Make it possible to remove timeout altogether

[wilsonpage]

Some cases in SMS app requests are resolve from the network, this means that overall round trip time is unknown and could take several seconds. In this case it's best to never timeout.

var client = threads.client({
  service: 'my-service'
  endpoint: myEndpoint,
  timeout: false
});

[julienw]

timeout: 0 would work for me too

[julienw]

@steveck-chung volunteered to work on this :)

[steveck-chung]

WIP in #75

[azasypkin]

Not totally related to this issue: but I'm wondering if we should have separate timeouts for the connection and for the method call like some other web-services-in-the-wild have (or maybe someday even per-method timeout, e.g. client.withTimeout(0).method('very-heavy-method', ...) similar to what marionette does with scope's timeouts)?

Currently I'm suffering from connection timeout when I refresh page with ctrl-f5 with our 2 hops communication channel, sometimes 1000ms is not enough for shared worker to start and initialize service. But at the same time method calls should be very fast and big global timeout can mask some potential performance issues for method calls.

Not really sure, but still feel a bit concerned.

What do you guys think?

[julienw]

I think it makes sense.

but tbh I'm not sure we need a timeout at all, ever... what exactly is the purpose of a timeout ?

[azasypkin]

but tbh I'm not sure we need a timeout at all, ever... what exactly is the purpose of a timeout ?

Mmm, good question :)

Here is where I-am-as-a-developer see timeout is useful from the top of my head - If client can't connect to the service it timeouts and we see that "connection" can't be established due to timeout, if connection is established, but method is not responding we see that "method" is not responding - easier to understand where the problem is. Connection is done under the hood when we call method - so with never-resolved-promise we can't say what's going on exactly.

Also Potentially clean-up/re-try/re-connect logic can be applied inside bridge automatically if service connection is time-outed - not really an argument since I'm not sure if it's practically needed and don't have real use cases (e.g. one of the ideas to handle SharedWorker->multiple iframes (one per app instance) was to automatically re-connect to the first available service-in-iframe that responds to connection request via BroadcastChannel in case previous time-outed, but we decided to not do it as it's impractical and damn complex :)).