Hi, On Tue, Sep 8, 2015 at 8:34 PM, Pavel Rappo <pavel.ra...@oracle.com> wrote: > Hi Simone, thanks for looking at this! > >> On 8 Sep 2015, at 17:29, Simone Bordet <simone.bor...@gmail.com> wrote: >> >> Uh, please no. >> >> JDK 9 will like ship juc.Flow, so I would recommend to base on that >> API rather than reinventing a new API every time to do backpressure. > > 1. To be honest, I don't think Flow API is a good match here. It's a > high-level > (very abstract) API.
You are misunderstanding it. It's actually a very low-level API, and some even call it a protocol. > I assume people might later adapt WebSocket API to Flow > API, but I still don't think we should implement it in terms of Flow API in > the > first place. For example, how do you see the > Flow.Subscription.request(lonJust rely on APIsg n) > would work here exactly? Should n (number of items) be a number of bytes? > Frames? Chunks? Messages? Only bytes from the list above gives one control > over > back-pressure. Messages/Chunks/Frames may vary in size significantly. Typically, request(long) should match what is being received in Subscriber.onNext(T). However, I know of people that want to be more fine grained, and may receive a ByteBuffer, but backpressure on the number of bytes consumed, but this requires some sort of buffering. It's an implementation detail; application typically use higher level APIs with a richer interface. > What would an app do if it asks for one more message, but the message would > turn > out to be a 100M file? If you ask for 1 message and you receive a 100M buffer, it is either already in memory of the publisher, or it is mapped to native memory. Either case, you can handle it just fine; when you are done with it, you can request one more of those buffers. > 2. I wouldn't base the WebSocket client on an API that is not a part of JDK > yet. Flow is scheduled to be part of JDK 9, AFAIK. If it's not anymore, then I would suggest at what Flow (or reactive streams) provides and do something similar. For your interest, we are talking about using Flow for the Servlet APIs and the new HttpClient. In any case, the basic use cases should work out of the box. With the current APIs, you cannot even write an echo service that is fully async. > A question if I may. Are there any examples of inherent issues in the model of > communicating back-pressure proposed for the WebSocket API that are absent in > Flow's approach? There are no examples of how one is supposed to use the API you are proposing. If I missed them, please be gentle and relink them to me. The solution you proposed with BackpressureHandler is racy and forces applications to do horrible synchronizations, or the implementation to impose a thread model, which is also a bad thing. I understand it's a proposal, but don't go that way. There exist proven solution already, just reuse them. Please, write a proxy example and show to all of us how the current proposed API would work. It must be fully async: you cannot read until you finished write and viceversa. >> I don't see how this would work in general. >>Because you mentioned it, >> An application that acts as a proxy may have chunk1 available, know >> that is not the last, but not have chunk2 available yet. And it cannot >> buffer them. > > It just sends out the chunk1 to the next peer in the chain. How's that > different > from handling WebSocket frames on an intermediary? Think of chunks as frames > if > that helps. Please, write the simple proxy I talk about. You will realize that you cannot do what you think you can. >> An application cannot implement this with an Iterator. >> Again, the problem is already solved by juc.Flow. > > Again, what problem? The async problem. The current API will force a thread to block. > BTW, due to some previous criticism of Outgoing it will likely be removed. Okay. > I think we would use suspend/resume. The "proxy case" as far as I understand > is > no different from any other case where back-pressure control is needed. Write the proxy case with the current API and post it somewhere for reference. I could not write it, but perhaps I have misunderstood the API proposal. I hope that in the spirit of other APIs, this API could be re-implemented using service providers (j.u.ServiceLoader). As such you cannot expect to create Oracle-private subclasses of Outgoing (or whatever solution replaces it) and have an alternative implementation cast them down to figure out how to extract the data they contains. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
