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
>> engineers appear to avoid the issue since
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 performance or convenience reasons?
Bridging channel and input/output streams is natural of course, bridging
between buffers a
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 performance or convenience reasons?
Convenience.
The conversation has gone a little off topic from the WebSocket API,
and this is probably not the best place to be discussing such proposed
convenience / performance APIs, since they need broader discussion
than net-dev.
It seems most folk are in agreement that the proposed WebSocket API
could be
> ByteBufferInputStream bbis = new ByteBufferInputStream();
> for each partial ByteBuffer received by the listener {
> bbis.add(byteBuffer);
> }
> ois = new ObjectInputStream(bbis);
> MyDTO = ois.readObject();
>
> Now, ByteBufferInputStream is not present in the JDK, and if you want
> to complain
These items are essential to keeping the server up to date and keeping the
code at Oracle clean and up to standard:
1. Update to HTTP22. Remove excess threads, only one thread is needed3. Replace
handler with a FIFO queue4. Clean up code, ideally with
http://elegantobjects.org principles
If yo
W.r.t. alternatives the HTTP serving landscape on the JVM is rich and
diverse at this point. Projects worth a look include Grizzly, Netty, Jetty,
Tomcat, Undertow, Rapidoid and the many cool frameworks build on top of
these technologies. (e.g. Jooby, SparkJava, Play to name a few)
-Rob
On 20
Hi Rob
Can you please read what I initially asked again, I'm not asking about new
frameworks or web servers. I'm stating 4 points that need to be addressed in
the EXISTING jdk6 web server. Again, if you disagree with any of these 4 points
can you please state WHY and WHAT the alternative to the
Hi,
On Tue, Feb 20, 2018 at 4:32 PM, Chuck Davis wrote:
> Simone, please, please tell me how this is done.
The WebSocket.Listener APIs return a CompletableFuture, indicating
when the application is done with the processing of the parameters
passed to the listener method (in particular the ByteBu
Thank you so much for your assistance, Simone.
On Tue, Feb 20, 2018 at 10:31 AM, Simone Bordet
wrote:
> Hi,
>
> On Tue, Feb 20, 2018 at 4:32 PM, Chuck Davis wrote:
> > Simone, please, please tell me how this is done.
>
>
> This version has the advantage that guarantees that no other copy is
> d
> On 20 Feb 2018, at 21:31, Simone Bordet wrote:
>
>
>
> This version has the advantage that guarantees that no other copy is
> done, not even by the implementation (hopefully, right Pavel ?), while
> with JDK 8 there may have been hidden copies to provide a full
> ByteBuffer.
>
If by copi
Thanks Simone,
I think this is a good example of how this low-level API can be
leveraged to build adapters, InputStream in this case. Equally,
that could be a RS Subscriber, or some other non-blocking
async JSON parser, or something else.
Let’s not get caught up in what the JDK should provide
out
Ashton, I don't think anyone disagrees with your four points at a high
level (though #4 might be a bit subjective, and #2 and #3 are
obviously design points that would theoretically be subject to
debate).
However, at the same time, you're not really going to see anyone
lining up and clamoring for
Hi,
On Tue, Feb 20, 2018 at 8:35 PM, Pavel Rappo wrote:
> If by copies you mean allocating new buffers and feeling them with the same
> contents, then you are right. No copies are made.
I mean that you call user code with a ByteBuffer produced from a
slice() of an internal ByteBuffer.
The CF me
David, I understand that you don't use this feature of the JDK and that's
absolutely fine. I'm not the type of person to impose my way of doing things on
anyone. I hope that you aren't either. There are obviously many people in the
community that DO love and use this httpserver for many reasons
On 20/02/2018 19:52, David Lloyd wrote:
enough that the internal server is
almost a legacy artifact at this point (after all it was IIRC only
introduced to support the in-JDK web services classes which may soon
be dropped from the JDK altogether).
Yes, the original motive for this small HTTP serv
Simone,
> On 20 Feb 2018, at 20:19, Simone Bordet wrote:
>
> Hi,
>
> On Tue, Feb 20, 2018 at 8:35 PM, Pavel Rappo wrote:
>> If by copies you mean allocating new buffers and feeling them with the same
>> contents, then you are right. No copies are made.
>
> I mean that you call user code with
Thanks Alan, I'm aware of these options.
Again, I'll refer you to the 4 points that this discussion was intended for.
On Tuesday, 20 February 2018, 20:22:05 GMT, Alan Bateman
wrote:
On 20/02/2018 19:52, David Lloyd wrote:
> enough that the internal server is
> almost a legacy artifact a
Hi,
On Tue, Feb 20, 2018 at 9:35 PM, Chris Hegarty wrote:
> Optimistically, if the whole message is read from the underlying
> socket in one native read ( small messages ), then the whole
> message will be in a single byte buffer, zero copy.
Good.
> If not, then to re-assemble the whole message
On Tue, Feb 20, 2018 at 2:15 PM, Ashton Hogan wrote:
> David, I understand that you don't use this feature of the JDK and that's
> absolutely fine. I'm not the type of person to impose my way of doing things
> on anyone. I hope that you aren't either. There are obviously many people in
> the commu
> On 20 Feb 2018, at 20:49, Simone Bordet wrote:
>
> Hi,
>
> On Tue, Feb 20, 2018 at 9:35 PM, Chris Hegarty
> wrote:
>> Optimistically, if the whole message is read from the underlying
>> socket in one native read ( small messages ), then the whole
>> message will be in a single byte buffer,
> I think that any other OpenJDK community member owes you anything, and
you would do well to remember that.
I agree, no one owes anyone anything. That's why I'm trying to make an offer to
do the work at a cost or take the code and distribute under a different
license. I'm offering a business de
> On 20 Feb 2018, at 23:49, Simone Bordet wrote:
>
> I don't see why the message should be reassembled, given
> MessagePart.[FIRST|PART|LAST] ?
> It's not that the user can ask for the kind of MessagePart, e.g. ask
> only for WHOLE messages that the implementation must reassemble on her
> behalf
23 matches
Mail list logo
