hi Matt, The game UI does handle response timeout. Tomcat just transfers traffic back and forth.
2013/12/29 Matt Connolly <[email protected]> > If the Tomcat service (layer 1) sends messages asynchronously to the > betting service (layer 2), then how is it possible to timeout the response > back to the iOS/Android app (layer 0)? > > -Matt > > On 29 Dec 2013, at 8:13 pm, artemv zmq <[email protected]> wrote: > > hi Pieter, > > > You're still not explaining what problem this solves > > Ok. Here's the problem which I faced recently. Here's appl. architecture > (to keep discussion focused): > > iOS/Android (game ui) <----ssl----> Tomcat <--------> bet_service . > > There are three layers (from left to right): game UI (0), java webserver > (1) and concrete service layer (2). > Layer#0: > - doesn't host 0mq library. > - talks to L1 via ssl. > - blocking(with timeout) on every call to L1. > Layer#1: > - does host 0mq library. > - it's a gateway for game ui. It's an async layer between ui and world > of services. > - it's _asynchronous_. It's a sort of "delegator/router/etc" for a call > from L0 to L2. > - on every call from L0 this layer doesn't wait for response from L2. > Layer#2: > - does host 0mq library. > - a concrete business service layer. > - L0 and L1 _don't care_ will this layer produce response or not. If > not -- L0 will hit call-timeout, L1 -- simply don't care et al. > > The problem is. > When L2 goes down (whatever reason), then L1 will queue messages, and, by > turn, L0 will hit call-timeout. After certain amount of time (usually up to > 1hr) L2 will be restarted. And messages, > which have been queued on L1, will be flying to L2. In my case, I don't > want getting those messages on L2, because they are "out-of-date" for > bet_service. > > The solution is -- TTL for a message. > I can implement TTL myself, making it being as a part of message, _but_ I > don't want to do that, because, TTL is low level thing, so fixing it at > higher level would bring more problems, I suppose. > > > > > > > 2013/12/29 Pieter Hintjens <[email protected]> > >> On Sat, Dec 28, 2013 at 9:52 PM, artemv zmq <[email protected]> wrote: >> > That's what I'm talking about ). Why this can't/shouldn't be done on >> 0mq? >> > The thing is -- 0mq is queueing solution (after all) and TTL is part of >> any >> > queueing. TTL is not concrete business feature, it's very common and >> > ubiquitous thing. >> >> You're still not explaining what problem this solves. Most "queuing >> solutions" offer priorities, acks, persistence, two-phase commits, >> etc. ZeroMQ does not. >> >> If you want to contribute to ZeroMQ, I'd advise you to use ZeroMQ to >> do do real work, then find areas where you need to make improvements, >> then make those improvements carefully and minimally. >> >> -Pieter >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
