Hi Jim, sorry for the late response, we’ve been a bit busy lately. Your analysis is correct in that boundedness applies to all aspects and cannot be magically “lifted”: the number of requests in flight will always be limited by the amount of buffering along the whole round-trip. In that sense there is no problem with being explicit about a maximal number of outstanding requests—having to remember facts about them for proper handling is just one side of this coin. This parameter is also directly available to limit the pressure you put onto the server, a bound that you’ll want to establish reliably—especially in larger systems—as well. What we need, beyond fixing simple bugs that are no doubt also in the mix, is to make this setting (which directly corresponds to a buffer size in the bypass flow) configurable in the client.
Regards, Roland > 9 feb 2015 kl. 21:14 skrev Jim Hazen <[email protected]>: > > Now that I think even more on the problem the more it seems that we're trying > to solve too much within a single flow. There are concepts that ought to be > independent that we're forcing to become dependent. > > I still like the independent streams model. I'd start with that, but with a > realization that this is a low-level protocol. A higher level protocol, > ought to deal with more advanced concepts, like auto-retry. > > There's a *big assumption* that the httpMethod bypass was to support things > like that. If not, then I'm going to start getting farther and farther off > base. > > Hmm. Yet, even with a full duplex stream of requests and responses, > implementing higher level stateful interactions tends to run into similar > problems. "remembering" what actor ought to receive a given response once > it's read off the stream. Easiest way to solve this would be to encapsulate > that addressing state into the response being returned. However, we need to > work within the confines of the HTTP protocol and I'm not sure the best way > to implement that handback in that case (cookies?). > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/> > >>>>>>>>>> Check the FAQ: > >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html> > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > >>>>>>>>>> <https://groups.google.com/group/akka-user> > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at http://groups.google.com/group/akka-user > <http://groups.google.com/group/akka-user>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. Dr. Roland Kuhn Akka Tech Lead Typesafe <http://typesafe.com/> – Reactive apps on the JVM. twitter: @rolandkuhn <http://twitter.com/#!/rolandkuhn> -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
