t, and implementing them will make sure the API
is correct.
== Pipelining
I think it's a relic of the past. Nobody uses it by default, and using
it has serious semantic effects. I would frankly remove support for
this feature; implementations may be configured to support it, but I
would not ex
ily write:
while (true)
{
try
{
future.get(1, SECONDS);
break;
}
catch (TimeoutException x)
{
// Not done yet, try again.
}
}
without implying any effect on the actual underlying operation.
This means that the timeout expires, but the request is not c
when
they have to send an OPTIONS * and just use another HttpClient.
I prefer clean, explicit APIs, but your call, obviously :)
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal perform
IMHO the API is confusing, I prefer just doing builder.header("Foo",
>> "foovalue").header("Bar", "barvalue").
>
>
> the parameters have to be specified in pairs
> with (header name first, then value) * n
Right, but you cannot enforce t
t 2 different levels of abstraction.
If it's not reactive streams, then it must be something new.
FWIW, we're discussing with the Servlet 4 EG about introducing a
reactive stream API for Servlet 4 async I/O.
Not yet carved in stone, but it's getting a little traction.
--
Simone Bo
aded version that takes a String).
Me, I'd like to get the semantic right first, and then look at
opportunities for improving performance.
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with opt
This proposal seems less clear to me, a bit of compromise between a
full fledged multi-selector API (it is in fact a 2-selector API for
cipher and application protocol) and the previous proposal (that was a
select-after-the-cipher selector API).
If the times are tight, I would go for the simpler approach and leave
the full fledged multi-selector API for JDK 10.
Thanks !
--
Simone Bordet
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
ead more until the write has completed. This is currently
not doable with the API.
Again, look at how it is done in juc.Flow.
Where is TLS support ? Let's not make the same mistake already done in
javax.websocket :)
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
Hi,
On Tue, Sep 8, 2015 at 8:34 PM, Pavel Rappo wrote:
> Hi Simone, thanks for looking at this!
>
>> On 8 Sep 2015, at 17:29, Simone Bordet wrote:
>>
>> Uh, please no.
>>
>> JDK 9 will like ship juc.Flow, so I would recommend to base on that
>> API ra
implementation can extract data
from any Outgoing implementation in an asynchronous way, less people
will object to it (apart noticing that the API forces allocation ;)
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliv
"matching"
more than client notification. For me this is a blocker.
Can you please provide an example of how a client application would
use this new API to be notified that the server has chosen protocol
"foo" ?
I still remain convinced that - so far - the Jetty API proposal (o
and
it's available in SSLSession.
When remains is the transient value of cipher that is being chosen.
Because we already have modified the API to support the application
protocol transient value (by adding
SSLEngine.getHandshakeApplicationProtocol()) to be used by
KeyManagers
vely because they use
many different communication protocols internally, so it won't be a
rare occasion to implement ApplicationProtocol.
> http://cr.openjdk.java.net/~wetmore/8051498/webrev.15/
I gather that the Map parameter can't be solved in other ways, right ?
Thanks !
--
S
protocol, you only sort to favour the best protocol.
In case you have [HTTP/2, AP_NEW, HTTP/1.1], then you can simply
compose the comparators to sort first with the H2.CIPHER_COMPARATOR,
then with AP_NEW.CIPHER_COMPARATOR.
cipherSuites = Arrays.sort(cipherSuites,
ApplicationProtocol.H2.CIPHER_COMPARATOR.thenComparing
he strength for general purpose, but not for
> application protocol.
Because HTTP/2 would probably be popular given the success of its
predecessor, it would be handy to have a HTTP/2 comparator to
influence the selection of the HTTP/2 protocol.
Nothing forbids to offer a comparator by ciphe
l.
It cannot choose the cipher based on the application protocol.
--
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
xplorer.java
Can you expand on how such approach would look like ? Seems overkill
to me, and all in the hands of application developers ?
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performa
to prefer 128 bits or lower to favor performance,
but also do HTTP/2.
The H2 comparator will sort the blacklisted at the end.
Among the good ones, they all compare == 0 for the H2 comparator.
That is where the second comparator will kick in, grep the cipher name
for the bits number and sort them accor
etend that ALPN
> wasn't recognized.
Are you saying that every application has to write its own TLS parser ?
Would not that be overkill and full of potential security issues if
one does not get the implementation strictly correct ?
Also, what if the JDK implementation refuses to use the
avor ap1 *and* c2, you have to decide what is more
important between the two, because you cannot have both.
I don't see any problem, really.
That the results are different, sure, but they are predictable.
When the configuration uses one comparator, it will always be that
result, and same for t
m the HTTP/2 spec.
Yes, there was an answer to Bradford's email:
https://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/0160.html.
The answer is "yes".
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug
tions, exactly
because the application decides whether to accept or not the
combination of application protocol, cipher, etc.
--
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
H1 and H2 for
ap.matches(), but in general these will be implemented by application
code.
For an application that wants to support H2, this boils down to the
first 2 lines, the rest is in the JDK.
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and
and also much more flexible.
Well, I kinda like it, but I have strong reservations that it cannot
really "negotiate" the application protocol, meaning that if one
application protocol fails, try the next, and then the next and so
forth until one succeeds (or they all fail).
Thanks !
--
an implementation already ? That would help.
--
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
s (CompletableFuture.get(time) is obviously not the
right semantic)
are blockers for me.
The other points in my previous message are less blockers, but I would
still ask to consider them.
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design
no idle timeout, no
total (request + response) timeout, which are in my experience the 3
most requested features about timeouts.
--
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
o write when using
Future.get(time) is just cumbersome, I would advice against any usage
of Future methods in the API.
CompletableFuture is fine, as long as you don't use the Future methods.
If an application wants to use Future methods, they are on their own,
but at least they are not forced to.
-
which is of
course against an async API and therefore not a viable solution.
--
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 fl
Failed to proof-read.
I meant "there is *no* timeout for async calls either" below.
Thanks !
On Mon, Sep 28, 2015 at 3:08 PM, Simone Bordet wrote:
> Hi,
>
> On Mon, Sep 28, 2015 at 2:50 PM, Michael McMahon
> wrote:
>> We might reconsider this. Currently ther
cklist/Comparator
>
> 2. set/getApplicationProtocols() back to SSLParameters.
Have you implemented this solution already ? Also for clients ?
Do you have feedback on actually implementing ALPN in this way ?
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the arch
to be configured in HttpClient ? Likewise for cookies and
headers ?
--
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
}
default void onError(WebSocket ws, Throwable failure) { }
end
enum CloseState { OPEN, REMOTE, LOCAL, CLOSED, ABORTED }
end
I hope it gets a second consideration.
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug
Hi,
On Fri, Oct 9, 2015 at 3:18 PM, Pavel Rappo wrote:
>> On 8 Oct 2015, at 20:51, Simone Bordet wrote:
>> For example, this is going to surprise users (simple echo):
>>
>> onBinary((ws, bytes, last) -> {
>>ws.sendBinary(bytes, last, null, (_, failure)
more
an implementation detail or something you want to configure in a
concrete implementation class, rather than in the API.
IMHO there are other ways to solve the same problem than exposing a
ByteBuffer pool API inside a WebSocket API.
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
--
n where
exceptions class names always have the "Exception" suffix. The JDK
consistently use this naming convention apart for some 1.0 class for
historical reasons (e.g. ThreadDeath).
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
keep WebSocketException only.
The subclasses also break an "implicit" naming convention where
exceptions class names always have the "Exception" suffix. The JDK
consistently use this naming convention apart for some 1.0 class for
historical reasons (e.g. ThreadDeath).
Than
n less and clearer
code), I am interested in learning from it.
> As for the API, well CompletableFuture is surely more nice compared to a bare
> Consumer. But let me try to implement both things and we could choose later.
> We probably don't want to double the number of sending me
* to buffer pool ...
}
});
}
At that point, the return value of onText() could well be a CF like
it already is, no ?
The implementation would just need to test for null, but then never
actually use the returned object wrapped by the CF.
What do you think ?
--
Simone Bordet
in the implementation, and you will not painting yourself in a corner
with CharBuffer.
Today you can use charset encoders, tomorrow you may use something
more optimized that does not need CharBuffer.
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and
thod into WebSocket, you get
exactly that: the write part along with the flow control and
cancelling part.
In ReactiveStream Publisher and Subscription are divided to support
multiple Subscribers.
In WebSocket there is no need to, hence, no need to split them.
--
Simone Bordet
http://bordet.blo
be as close as possible to ReactiveStream, then
just use the Flow API.
LongConsumer is of course not Flow.Subscription. Half mimicking the
Flow API does not bring any good.
And with this I really hope you are not going to extract out of
WebSocket also the cancelling/closing part to separate more concerns
handshake
Is that right ?
In that scenario, what is the use of
SSLEngine.getHandshakeApplicationProtocol() ?
Also, I don't understand how the above could work for SSLSocket ?
Can someone write down the steps a client and a server should do to
actually use ALPN with SSLSocket ?
Thanks !
--
mentation needs
a major overhaul to simplify it.
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
s something deliverable, perfect, why
> can't I proceed with reading the next chunk of data?
When the read buffer has no more space, you are going to require a
read interest for no reason.
If you are otherwise compacting the buffer, you will run into the data
corruption problem I mentioned.
Bot
subclasses for application or
implementation failures, but Exception or subclasses instead.
--
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
Hi,
On Mon, Apr 4, 2016 at 5:35 PM, Chris Hegarty wrote:
>>> On 3 Apr 2016, at 18:43, Simone Bordet wrote:
>>> Threading.
>>> ---
>>> WebSocket.sendXXX() calls
>>> MessagePublisher.send(), which dispatches a to
>>> MessagePublisher.
ould hurt
applications that do not block - and we are going towards more and
more of this kind of applications.
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 relia
ifferent in their speed. How would you suggest one should organize
> and
> scale this?
You have to define what you mean by "organize and scale", and what is
the real problem you are trying to solve.
I would not start worrying about this until the implementation is
simple and effi
ons).
4) Where possible, try to avoid the use of the modulo operator % - it
is known to be really slow.
>From what I saw, you can probably get by using power of twos and bit
shifting and masking.
It does make the code a little more unreadable though. Your call.
Thanks !
--
Simone Bordet
http
eview in an IDE rather than in textual mode, but I
have not found instructions on how to apply a webrev to a source tree.
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 r
g your HTTP/1.1 patches, then the HTTP2 patch.
Is that ok ?
--
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
e API which are protected via dispatches to other
threads (that then block), but the I/O.
Is this deliberate ? I was under the impression the HTTP client wanted
to be non-blocking at its core ?
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design
#x27;s really confusing to review :/
Maybe you can clarify why it has been implemented in this hybrid way,
to then rewrite it asynchronously ?
It will help reviewers (at least me) to understand the implementation
choices (which now appear as "wtf" moments).
Thanks !
--
Simone Bordet
h
ent has been received. I find this confusing.
I would rather remove this method (to keep only bodyAsync()), and
provide a utility class that has a blocking behavior when passed to
bodyAsync(), something like:
BlockingBody bb = ...;
response.bodyAsync(bb);
T body = bb.get();
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
code ?
SSLEngine.getApplicationProtocol() seems only to be used for debugging ?
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 fla
Hi,
is there any plan to make the new HTTP/2 and WebSocket client
implementation replaceable via a ServiceLoader mechanism ?
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal
I'm presenting the API at a conference this week, would be great to
have a 10k meters view of the availability for early adopters.
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with opti
ry quick look, but exception throwing, thread dispatching,
multi-nested synchronization, incorrect handling of non-blocking
writes (if I understand the code correctly) are still there.
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
Hi,
On Tue, May 10, 2016 at 2:03 PM, Pavel Rappo wrote:
> Hi Simone,
>
>> On 4 Apr 2016, at 20:07, Simone Bordet wrote:
>>
>> In my experience, once you get rid of exception throwing in async API
>> everything becomes much simpler, especially "dee
pResponse.multiProcessor::onStart's return
> type (from BiFunction<..., Boolean> to BiPredicate), to building on the
> j.u.c.Flow API & eliminating HttpResponse.MultiProcessor. So I'm wondering
> what's still on on the table for JEP 110 w.r.t. API changes?
I second
I don't recall if extensions have been ruled out ?
Browsers seem to have settled at implementing permessage-deflate.
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
nClose(), but not to onPing(), nor to onPong().
--
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
bytes long.
The requirement of handling its payload asynchronously can be perhaps
dropped: the implementation can just copy those bytes and pass them to
the application, and not worry about buffer recycling.
In any case, your call, I'm fine with either solution.
--
Simone Bordet
http://bor
n has the
meaning of a 1005 code.
If you remove the parameterless sendClose() from the API, you don't
need the Optional anymore, and things will be much simpler.
My point being: let's clean the API to the bare minimum required,
removing stuff until there is nothing left to take away.
Th
ebSocket
Connection Close Code_ is considered to be 1005."
I am not opposed to have a utility method sendClose() parameterless,
but I don't think that it's worth an Optional in onClose(), given the
semantic defined by 7.1.5.
--
Simone Bordet
http://bordet.blogspot.com
---
Finally,
always offering a close code in the
API (and thus get rid of the Optional).
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
eturned by sendClose() and be done with it.
But onClose() should return a CS, or you decided not to ? If so, can
you detail why, FTR ?
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal p
the idea was that you always want *at most* one outstanding write.
Multiple writes should be chained via CS.
Concurrent writes are handled by applications.
Are you saying that with this change, you allow infinite buffering ?
To be clear, do you want to allow this (pseudocode):
ByteBuffer buffer = ...;
x is the same as above, write the application thinking this
properly, but now there is a double work: the application queueing,
and the implementation queueing.
Alternatively, you can make this semantic explicitly configurable in
the Builder ?
--
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
e are additional burdens on applications, but at
least it's clear to an application what it should do.
If you choose the last, then an application has to assume the least,
and it has to write code with only one outstanding write.
At that point you (as implementer) have the burden of putting
emantic for sendX() is "at most one outstanding write" I
would not consider a ping an outstanding write: it can be performed at
any time.
> 2. Does "sendPing" have to wait until the CF returned by the previous sendPing
> has completed?
I'd say no.
--
Simone Bordet
htt
Hi,
On Mon, Jun 13, 2016 at 3:40 PM, Pavel Rappo wrote:
>
>> On 13 Jun 2016, at 12:14, Simone Bordet wrote:
>>
>> Close should definitely *not* "jump ahead of the queue", it should be
>> sent after queued stuff has been sent.
>
> Why is that?
Becau
Hi,
On Tue, Jun 14, 2016 at 1:26 PM, Pavel Rappo wrote:
>
>> On 13 Jun 2016, at 12:14, Simone Bordet wrote:
>>
>>> Should the application be in charge of chopping outgoing messages in chunks
>>> in
>>> order to provide better responsiveness when
Hi,
On Tue, Jun 14, 2016 at 2:36 PM, Simone Bordet wrote:
> That is again a semantic problem, but I think this one is simple: the
> implementation cannot guarantee that one API call correspond to one
> frame.
> There are, for example, fragmentation extensions that
> fragment/re
> programming
> model, not using CF's will be most common, but it doesn’t get in the way of a
> more sophisticated advanced usage.
However, you still want to use the CFs for exception reporting.
BTW, this suggestion was ruled out by Pavel when I suggested it.
Not sure who overrules
om onClose(), and the implementation will send the reply close frame
(if not already sent by the application).
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
e).
And the disagreement is that TCP can send an unlimited amount of data
in half closed state, while WebSocket *seems* to hint that it *may*
send a *non specified* amount of fragments ?
:)
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design
considers the WebSocket connection closed and MUST close the
underlying TCP connection."
Which tells that an endPoint closes the TCP connection when it is
fully closed (2 halves).
So, if you *have* to continue reading from the network to read the
reply close frame, what do
m Pavel's, we're
just discussing different interpretations here and try to come out
with a good/common one.
--
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 i
Hi,
On Thu, Jun 23, 2016 at 7:00 PM, Pavel Rappo wrote:
> But I still think we probably more safe assuming the intersection of our
> understandings, rather than a union :-)
Chris and I agreed, so now you're minority :)
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no
eanup());
} catch (Throwable x) {
// Uh, no idea if the implementation actually closed !
// Let's *hope* this one goes fine :/
ws.sendClose(1000, "short").handle((ws, th) -> cleanup());
}
--
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
essage.
It's not a programming error, it's just the result of events happening
at the same time.
--
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
a classic getter method, and the uppercase allows people to
quickly identify that is different.
--
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 implementatio
lementation detail”. Does this sound like a
> good idea ? If so I would be happy to come up with a patch against openjdk.
>
I wholeheartedly support this.
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-fr
ly
when connecting to multiple domains.
I would suggest smaller values.
Our experience is that even in fast network (not localhost) 16 MiB
session windows will hit TCP congestion control before stalling HTTP/2
flow control.
--
Simone Bordet
---
Finally, no matter how good the architecture and
erfering with their throughput, with proxy applications that have
different speeds on the 2 sides they proxy, and so on.
Here I am seriously advocating to the net-dev JDK group to provide an
efficient solution, or at least start a discussion where appropriate,
for ByteBuffer to [Input|Output]
- I have not written it myself and for this kind
of things often the details are hidden until a serious implementation
effort is attempted.
Thanks !
--
Simone Bordet
---
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
bridge between ByteBuffer and [Input|Output]Stream
will solve a million cases.
--
Simone Bordet
---
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
Alan,
On Tue, Feb 20, 2018 at 8:50 AM, Alan Bateman wrote:
> On 19/02/2018 20:19, Simone Bordet wrote:
>>
>> :
>> Now, ByteBufferInputStream is not present in the JDK, and if you want
>> to complain you are in good (and conspicuous) company, as the JDK
>> en
Hi,
On Tue, Feb 20, 2018 at 10:22 AM, Alan Bateman wrote:
>
>
> On 20/02/2018 08:14, Simone Bordet wrote:
>>
>> :
>> Where would be a good list to start discussing ByteBuffer to
>> [Input|Output]Stream bridging ?
>>
> Are you looking for this for perfor
le
with JDK 8 there may have been hidden copies to provide a full
ByteBuffer.
--
Simone Bordet
---
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 Livschit
x27;t see why not ?
Read from network, parse header bytes, slice the buffer, call the
listener. Zero copy.
Can you expand ?
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation t
s that the implementation must reassemble on her
behalf, no ?
So it will *always* be the case that zero copy is possible, right ?
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the impleme
the WebSocket
frames, I know what to do", sticking to least surprise.
One last orthogonal comment about usage of the Flow APIs in the new HTTP client.
As far as I know the Flow APIs are only used for request and response
content, not the for HTTP protocol lifecycle.
HTTP requests/response
leFuture) should have been taken for
HTTP with even more importance, given how more popular is HTTP over
WebSocket.
I would like this revision to be taken into consideration, offering an
efficient low-level API for HTTP as well.
Thanks !
--
Simone Bordet
---
Finally, no matter how good the arc
an IntelliJ warning telling me that I should not do
that!), will cause confusion and be potential source of bugs - we all
know non-blocking/async programming is hard.
Thanks !
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with opti
and
almost none to handle Subscribers: Publishers are exposed, Subscribers
hidden.
I don't see any confusion.
Thanks !
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementati
implement.
> I accept that a carrier would be a more friendly for possible evolution,
> maybe:
>
> BodyHandlerInfo {
> int statusCode() {... }
> HttpHeaders responseHeaders { ... }
> }
>
> Does this satisfy your concern?
Yes.
This class could already hold the HTT
Processor/Subscriber
implementation should just extend a ReactiveStream TCK class
overriding a few methods, for example:
https://github.com/jetty-project/jetty-reactive-httpclient/blob/master/src/test/java/org/eclipse/jetty/reactive/client/internal/QueuedSinglePublisherTCKTest.java
The ReactiveStreams TCK doe
1 - 100 of 116 matches
Mail list logo
