On Tue, 17 May 2022 12:45:52 GMT, Daniel Jeliński wrote:
> This PR improves the execution time of jdk_net tests (and, by extension,
> tier2) by about 3 minutes.
>
> Tests located under `jdk/java/net/httpclient/websocket` are never run in
> parallel. Each of the 8 modified `Pe
On Thu, 19 May 2022 12:05:45 GMT, Daniel Jeliński wrote:
>> This PR improves the execution time of jdk_net tests (and, by extension,
>> tier2) by about 3 minutes.
>>
>> Tests located under `jdk/java/net/httpclient/websocket` are never run in
>> parallel. E
On Thu, 19 May 2022 10:46:35 GMT, Pavel Rappo wrote:
> > > What looks questionable is rearrangement of asserts: when `assertHangs`
> > > moves down. assertNotDone(cfClose) can transitorry pass even if ping has
> > > not hung.
> >
> >
> > `assertHangs` either waits for 5 seconds or throws an e
> This PR improves the execution time of jdk_net tests (and, by extension,
> tier2) by about 3 minutes.
>
> Tests located under `jdk/java/net/httpclient/websocket` are never run in
> parallel. Each of the 8 modified `Pending***` tests originally required 40
> seconds to c
On Thu, 19 May 2022 09:42:05 GMT, Daniel Jeliński wrote:
> > What looks questionable is rearrangement of asserts: when `assertHangs`
> > moves down. assertNotDone(cfClose) can transitorry pass even if ping has
> > not hung.
>
> `assertHangs` either waits for 5 seconds or throws an exception, s
> This PR improves the execution time of jdk_net tests (and, by extension,
> tier2) by about 3 minutes.
>
> Tests located under `jdk/java/net/httpclient/websocket` are never run in
> parallel. Each of the 8 modified `Pending***` tests originally required 40
> seconds to c
On Thu, 19 May 2022 09:22:57 GMT, Pavel Rappo wrote:
> What looks questionable is rearrangement of asserts: when `assertHangs` moves
> down. assertNotDone(cfClose) can transitorry pass even if ping has not hung.
`assertHangs` either waits for 5 seconds or throws an exception, so
`assertNotDone
On Tue, 17 May 2022 14:55:11 GMT, Daniel Fuchs wrote:
> I am a bit less sure about moving the post-asserts inside the loop
I moved them because they too can fail if the original blocked future suddenly
completes.
Side effect of this change is that any failures that happen after
websocket.abort
On Tue, 17 May 2022 12:45:52 GMT, Daniel Jeliński wrote:
> This PR improves the execution time of jdk_net tests (and, by extension,
> tier2) by about 3 minutes.
>
> Tests located under `jdk/java/net/httpclient/websocket` are never run in
> parallel. Each of the 8 modified `Pe
On Tue, 17 May 2022 12:45:52 GMT, Daniel Jeliński wrote:
> This PR improves the execution time of jdk_net tests (and, by extension,
> tier2) by about 3 minutes.
>
> Tests located under `jdk/java/net/httpclient/websocket` are never run in
> parallel. Each of the 8 modified `Pe
This PR improves the execution time of jdk_net tests (and, by extension, tier2)
by about 3 minutes.
Tests located under `jdk/java/net/httpclient/websocket` are never run in
parallel. Each of the 8 modified `Pending***` tests originally required 40
seconds to complete. After the proposed
On Wed, 16 Jun 2021 13:53:38 GMT, Daniel Fuchs wrote:
> Hi,
>
> Please find below a test-only change to fix some intermittent failures
> observed with the httpclient/websocket tests:
> these tests intermittently and randomly fail with ENOMEM ("No buffer space
>
On Wed, 16 Jun 2021 13:53:38 GMT, Daniel Fuchs wrote:
> Hi,
>
> Please find below a test-only change to fix some intermittent failures
> observed with the httpclient/websocket tests:
> these tests intermittently and randomly fail with ENOMEM ("No buffer space
>
On Wed, 16 Jun 2021 13:53:38 GMT, Daniel Fuchs wrote:
> Hi,
>
> Please find below a test-only change to fix some intermittent failures
> observed with the httpclient/websocket tests:
> these tests intermittently and randomly fail with ENOMEM ("No buffer space
>
Hi,
Please find below a test-only change to fix some intermittent failures observed
with the httpclient/websocket tests:
these tests intermittently and randomly fail with ENOMEM ("No buffer space
available").
Some machines in our CI seem to allow a higher level of concurrency w
Thank you all for your replies.
Kind regards
-Christos
On Fri, Jun 11, 2021 at 12:50 PM Michael McMahon <
michael.x.mcma...@oracle.com> wrote:
> Yes, it does seem that for local RPC a regular (unix domain) socket should
> suffice
> rather than a websocket.
>
> Also, just t
Yes, it does seem that for local RPC a regular (unix domain) socket
should suffice
rather than a websocket.
Also, just to point out that Unix domain socket (channels) have been in
the JDK
since Java 16.
- Michael.
On 11/06/2021 10:22, Daniel Fuchs wrote:
Hi Christos,
The HttpClient
at exposes a json-rpc interface
over a Unix Domain Socket using websocket. I know that the upcoming
Java 17 release will include support for unix domain sockets and I'm
wondering if the included websocket client (since Java 11) will also
support this mechanism ?
If not planned, any ad
Hello all,
we've a native application (in C) that exposes a json-rpc interface over a
Unix Domain Socket using websocket. I know that the upcoming Java 17
release will include support for unix domain sockets and I'm wondering if
the included websocket client (since Java 11) will al
On Thu, 27 May 2021 09:32:06 GMT, Daniel Fuchs wrote:
> Hi,
>
> Please find below a fix for:
> 8265367: [macos-aarch64] 3 java/net/httpclient/websocket tests fail with
> "IOException: No buffer space available"
>
> The Pending* websocket tests create a server t
On Thu, 27 May 2021 13:20:26 GMT, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below a fix for:
>> 8265367: [macos-aarch64] 3 java/net/httpclient/websocket tests fail with
>> "IOException: No buffer space available"
>>
>> The Pending* web
> Hi,
>
> Please find below a fix for:
> 8265367: [macos-aarch64] 3 java/net/httpclient/websocket tests fail with
> "IOException: No buffer space available"
>
> The Pending* websocket tests create a server that accepts sockets to create a
> websocket, but nev
Hi,
Please find below a fix for:
8265367: [macos-aarch64] 3 java/net/httpclient/websocket tests fail with
"IOException: No buffer space available"
The Pending* websocket tests create a server that accepts sockets to create a
websocket, but never read data from the websocket in order
Hi Pavel,
Thanks for the review!
On 07/08/2020 13:49, Pavel Rappo wrote:
May I suggest we use this?
ChannelState s;
assert (s = writeState.get()) == CLOSED : s;
Or better still,
ChannelState s = writeState.get();
assert s == CLOSED : s;
I'll do that before pushing.
be
But as a consequence - I am no longer planning to push it to
> 15 as it also changes some source files:
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8249786/webrev.02/
>
> best regards,
>
> -- daniel
>
> On 21/07/2020 18:53, Daniel Fuchs wrote:
>> Hi,
>> P
Thanks Chris!
best regards,
-- daniel
On 07/08/2020 09:44, Chris Hegarty wrote:
http://cr.openjdk.java.net/~dfuchs/webrev_8249786/webrev.02/
LGTM - extending repeatable to cover Windows platforms too.
( the previous problems with these tests came flooding back
when reading the comment in Pend
Daniel,
> On 23 Jul 2020, at 16:02, Daniel Fuchs wrote:
>
> Hi,
>
> More testing revealed that some other tests of the same family
> kept on failing intermittently, though my changes to
> PendingOperation.java should have fixed them.
>
> So here is a broader fix - which seems to have fixed th
as it also changes some source files:
http://cr.openjdk.java.net/~dfuchs/webrev_8249786/webrev.02/
best regards,
-- daniel
On 21/07/2020 18:53, Daniel Fuchs wrote:
Hi,
Please find below a fix for:
8249786: java/net/httpclient/websocket/PendingPingTextClose.java
fails very
Hi,
Please find below a fix for:
8249786: java/net/httpclient/websocket/PendingPingTextClose.java
fails very infrequently
https://bugs.openjdk.java.net/browse/JDK-8249786
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8249786/webrev.00/
This test has been observed failing on
> On 26 Jun 2020, at 18:18, Daniel Fuchs wrote:
>
> I concur. Rahul has convinced me.
> Rahul also pointed me to a test that verifies that the IAE is
> thrown, so I believe that
> http://cr.openjdk.java.net/~ryadav/webrev_8245245/index.html
LGTM.
-Chris.
Looks good to me.
P.S. I think I began to forget the very code I wrote.
> On 26 Jun 2020, at 18:18, Daniel Fuchs wrote:
>
> I concur. Rahul has convinced me.
> Rahul also pointed me to a test that verifies that the IAE is
> thrown, so I believe that
> http://cr.openjdk.java.net/~ryadav/webrev_8
ote:
>
>
>
>> On 26 Jun 2020, at 14:38, Pavel Rappo wrote:
>>
>> Rahul,
>>
>> Won't that start retaining the URL fragment? From
>> https://tools.ietf.org/html/rfc6455#section-3
>>
>> Fragment identifiers are meaningless in the cont
I concur. Rahul has convinced me.
Rahul also pointed me to a test that verifies that the IAE is
thrown, so I believe that
http://cr.openjdk.java.net/~ryadav/webrev_8245245/index.html
is good.
best regards,
-- daniel
On 26/06/2020 16:42, Rahul Yadav wrote:
Pavel,
That scenario is already handl
> On 26 Jun 2020, at 14:38, Pavel Rappo wrote:
>
> Rahul,
>
> Won't that start retaining the URL fragment? From
> https://tools.ietf.org/html/rfc6455#section-3
>
> Fragment identifiers are meaningless in the context of WebSocket URIs
> and MUST NOT be
throw illegal("URI must not contain a fragment: " + uri);
352 return uri;
353 }
354
- rahul
On 26/06/2020 14:38, Pavel Rappo wrote:
Rahul,
Won't that start retaining the URL fragment? From
https://tools.ietf.org/html/rfc6455#section-3
Fragment identifiers a
> On 26 Jun 2020, at 15:10, Pavel Rappo wrote:
>
> Chris,
>
> Currently (i.e. before the proposed change has been applied) the fragment is
> NOT retained. This is because of the requirement of the mentioned RFC
> section. The proposed change seems to overlook that detail. Hence, my
> quest
Rahul,
Won't that start retaining the URL fragment? From
https://tools.ietf.org/html/rfc6455#section-3
Fragment identifiers are meaningless in the context of WebSocket URIs
and MUST NOT be used on these URIs. As with any URI scheme, the
character "#", when not indicati
Hello,
Request to have my fix reviewed for issue:
JDK-8245245 : WebSocket can loose the URL encoding of URI query parameters
The fix updates the jdk.internal.net.http.websocket.OpeningHandshake
to ensure that the URL is not reencoded/decoded and loose the original
encoding
Issue: https
Hello,
Request to have my fix reviewed for issue:
JDK-8247675 : WebSocket can loose the URL encoding of URI query parameters
The fix updates the jdk.internal.net.http.websocket.OpeningHandshake
to ensure that the URL is not reencoded/decoded and loose the original
encoding
Issue: https
iewed for the issue:
>
>JDK-8244652: Add test for non utf-8 response handling by websocket
> client.
>
> The test java.net.httpclient.websocket.WSHandshakeExceptionTest.java is
> updated to test
>
>that the websocket client handles invali
, Rahul wrote:
Hello,
Request to have my fix reviewed for the issue:
JDK-8244652: Add test for non utf-8 response handling by websocket
client.
The test java.net.httpclient.websocket.WSHandshakeExceptionTest.java is
updated to test
that the websocket client handles invalid utf-8 sent by the
Hello,
Request to have my fix reviewed for the issue:
JDK-8244652: Add test for non utf-8 response handling by websocket client.
The test java.net.httpclient.websocket.WSHandshakeExceptionTest.java is
updated to test
that the websocket client handles invalid utf-8 sent
On 06/05/2020 16:48, rahul.r.ya...@oracle.com wrote:
Thanks Daniel , webrev updated.
Looks good!
-- daniel
Thanks Daniel , webrev updated.
- rahul
On 06/05/2020 16:16, Daniel Fuchs wrote:
Hi Rahul,
LGTM.
111 WebSocketHandshakeException wse =
(WebSocketHandshakeException) t;
112 out.println("Status code is " +
wse.getResponse().statusCode());
113
> On 6 May 2020, at 16:16, Daniel Fuchs wrote:
>
> Hi Rahul,
>
> LGTM.
+1
-Chris.
Hi Rahul,
LGTM.
111 WebSocketHandshakeException wse =
(WebSocketHandshakeException) t;
112 out.println("Status code is " +
wse.getResponse().statusCode());
113 out.println("Response is " +
wse.getResponse().body());
114 asse
Hi Pavel,
Thank you for the comment, the webrev has been updated.
webrev : http://cr.openjdk.java.net/~ryadav/webrev_8240666/webrev.00/index.html
- rahul
On 06/05/2020, 14:26, "Pavel Rappo" wrote:
An assertion of the form
assertEquals(true, ((String)wse.getResponse().body())
An assertion of the form
assertEquals(true, ((String)wse.getResponse().body()).contains("404"));
looks odd. I'd suggest using any of
assertTrue(boolean condition)
assertTrue(boolean condition, String message)
-Pavel
> On 6 May 2020, at 14:12, Rahul wrote:
>
> http://cr.openjdk.ja
Hello,
Request to have my fix reviewed for the issue:
JDK-8240666: Websocket client’s OpeningHandshake discards the HTTP response
body.
The fix updates jdk.internal.net.http.websocket.OpeningHandshake.send()
to process the response body received from server instead of
Daniel,
> On 13 Jan 2020, at 13:06, Daniel Fuchs wrote:
>
> Hi,
>
> Please find below a fix for:
> 8236859: WebSocket over authenticating proxy fails with NPE
> https://bugs.openjdk.java.net/browse/JDK-8236859
>
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8236
On 14/01/2020 18:17, Pavel Rappo wrote:
I think the WebSocket part of the changeset look good to me. I have gone through
the non-WebSocket part of the changes shallowly. I'm not an expert.
Thanks!
Your review is appreciated!
I will wait until Michael or Chris review the rest of the ch
I think the WebSocket part of the changeset look good to me. I have gone through
the non-WebSocket part of the changes shallowly. I'm not an expert.
> On 14 Jan 2020, at 17:59, Daniel Fuchs wrote:
>
> Hi Pavel,
>
> On 14/01/2020 17:54, Pavel Rappo wrote:
>> That chan
Hi Pavel,
On 14/01/2020 17:54, Pavel Rappo wrote:
That changeset applies fine, thanks.
I was wondering what you had in mind when added OpeningHandshake:225.
Was it for general robustness or you ran into something in particular?
More for general robustness. Sometimes assertion errors are fire
That changeset applies fine, thanks.
I was wondering what you had in mind when added OpeningHandshake:225.
Was it for general robustness or you ran into something in particular?
> On 14 Jan 2020, at 15:36, Daniel Fuchs wrote:
>
> On 14/01/2020 15:14, Daniel Fuchs wrote:
>> I wonder if this was
On 14/01/2020 15:14, Daniel Fuchs wrote:
I wonder if this was causing issue with the import.
(the patch is obtained by hg diff, not hg export)
Yes. Damn. the open.patch generated by webrev renames the files
instead of copying/modifying...
I have added a proper changeset generated with `hg expo
That patch contains the following lines:
--- old/test/jdk/java/net/httpclient/websocket/DummyWebSocketServer.java
2020-01-13 13:04:41.0 +
+++ /dev/null 2020-01-13 13:04:41.0 +
--- old/test/jdk/java/net/httpclient/websocket/Support.java 2020-01-13
13:04
me
of them could not be compiled. For instance,
java/net/httpclient/websocket/BlowupOutputQueue.java
java/net/httpclient/websocket/PendingPingBinaryClose.java
...
etc.
> On 13 Jan 2020, at 13:06, Daniel Fuchs wrote:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8236859/webrev.00/
Daniel,
I imported the patch from the link you provided as follows:
hg import --no-commit open.patch
The patch applied successfully. I tried then to run the tests and saw that some
of them could not be compiled. For instance,
java/net/httpclient/websocket/BlowupOutputQueue.java
Hi,
Please find below a fix for:
8236859: WebSocket over authenticating proxy fails with NPE
https://bugs.openjdk.java.net/browse/JDK-8236859
http://cr.openjdk.java.net/~dfuchs/webrev_8236859/webrev.00/
It happens when we have a TLS tunnel and authentication with the server
fails: in that
Thanks Patrick!
I pushed it.
best regards,
-- daniel
On 23/09/2019 18:13, Patrick Concannon wrote:
Hi Pavel,
Thanks for the feedback. I've incorporated the changes you suggested,
and you can find them in the new webrev below.
http://cr.openjdk.java.net/~pconcannon/8217825/webrevs/webrev.02
care of that!
Before you push, please add missing spaces to
WebSocketTest.java:612
WebSocketTest.java:713
(no need to update the webrev)
Nits:
WebSocketTest.java:808 does not abort WebSocket. Now, I understand that in
normal circumstances we never expect a WebSocket to be created. Ho
Patrick,
Thank you for taking care of that!
Before you push, please add missing spaces to
WebSocketTest.java:612
WebSocketTest.java:713
(no need to update the webrev)
Nits:
WebSocketTest.java:808 does not abort WebSocket. Now, I understand that in
normal circumstances we never expect
/webrevs/webrev.01/
Kind regards,
Patrick
On 13/09/2019 15:47, Daniel Fuchs wrote:
Hi Patrick,
I wonder if you should be using `try { } finally { }` to ensure
that the websocket is closed too:
var websocket = .;
try {
// send some messages etc...
} finally {
websocket.abor
I wonder if you should be using `try { } finally { }` to ensure
that the websocket is closed too:
var websocket = .;
try {
// send some messages etc...
} finally {
websocket.abort();
}
best regards,
-- daniel
On 13/09/2019 15:36, Patrick Concannon wrote:
Hi,
Would it be p
Hi Patrick,
I wonder if you should be using `try { } finally { }` to ensure
that the websocket is closed too:
var websocket = .;
try {
// send some messages etc...
} finally {
websocket.abort();
}
best regards,
-- daniel
On 13/09/2019 15:36, Patrick Concannon
Hi,
Would it be possible to have my fix for JDK-8217825 - Verify @AfterTest
is used correctly in WebSocket tests - reviewed?
Following on from the discussion had here:
https://mail.openjdk.java.net/pipermail/net-dev/2019-January/012141.html,
I’ve refactored several websocket tests to
Looks good.
While you're at it you could make:
123 CopyOnWriteArrayList connections;
final. No need for a new webrev.
best regards,
-- daniel
On 29/01/2019 12:53, Chris Hegarty wrote:
Agreed. Should be good enough for test cleanup.
http://cr.openjdk.java.net/~chegar/8217976/webrev.01/
> On 29 Jan 2019, at 12:31, Daniel Fuchs wrote:
>
> ...
> The best would be to use CopyOnWriteArrayList instead
> of synchronizedList(). Otherwise you'd still need to copy the list
> within a synchronize(connections) { } block to prevent CME.
Agreed. Should be good enough for test cleanup.
ht
Hi Chris,
116 List localList = List.copyOf(connections);
I think it is still possible for CME to happen during the copyOf
operation, even though it can reduce the window in which that might
happen.
The best would be to use CopyOnWriteArrayList instead
of synchronizedList(). Otherwise
WebSocketProxyTest is a new test that was added recently. It fails once
in every few hundred runs. The test uses a preexisting test-only proxy
server. There is a race when closing the server; the close method
iterates over all connections while another thread may be adding a new
connection. The sol
7;s what @AfterTest public void
>> cleanup()
>> is supposed to do.
>
> I think @AfterTest does not do what you think it does.
You are right, I was mistaken. I will have to make sure WebSocket test cases
perform their cleanup correctly. Looks like it's not the only test file that
Thanks Chris.
Makes sense, and looks good!
best regards,
-- daniel
On 25/01/2019 17:07, Chris Hegarty wrote:
Daniel,
On 25 Jan 2019, at 15:34, Daniel Fuchs wrote:
Hi Chris,
Looks good.
I had the same question than Pavel about server.close().
Answered already in reply to Pavel’s questio
Daniel,
> On 25 Jan 2019, at 15:34, Daniel Fuchs wrote:
>
> Hi Chris,
>
> Looks good.
> I had the same question than Pavel about server.close().
Answered already in reply to Pavel’s question.
> No test for both proxy + server authorization with
> -Djdk.http.auth.tunneling.disabledSchemes ?
N
Pavel,
> On 25 Jan 2019, at 15:16, Pavel Rappo wrote:
>
> Chris, thanks for doing this! I have two questions on this change.
>
> 1. After this change has been applied, there will be a circular dependency
> between HttpRequestImpl and OpeningHandshake. If this code is used by these
> two
> clas
Hi Chris,
Looks good.
I had the same question than Pavel about server.close().
No test for both proxy + server authorization with
-Djdk.http.auth.tunneling.disabledSchemes ?
cheers,
-- daniel
On 25/01/2019 14:21, Chris Hegarty wrote:
When tunneling WebSocket over a proxy requiring
) third
class?
2. Why does this change add server.close() to each and every test method of
WebSocketTest? If I'm not mistaken that's what @AfterTest public void cleanup()
is supposed to do.
> On 25 Jan 2019, at 14:21, Chris Hegarty wrote:
>
> When tunneling WebSocket ove
When tunneling WebSocket over a proxy requiring authentication, the
implementation must ensure that the appropriate Upgrade headers are
not lost after the tunnel has been established. The source changes are
quite straight forward, the remaining bulk of the changes are to address
a deficiency in
> 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
> 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,
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
re all CFs associated with sliced ByteBuffers
> generated from the internal ByteBuffer are completed.
>
>> However there is a natural need for multiple passes over the buffers, both
>> being sent and received. These are unavoidable transformations performed by
>> SSL
>> a
le passes over the buffers, both
> being sent and received. These are unavoidable transformations performed by
> SSL
> and WebSocket masking.
Sure.
> As for the WHOLE message, there's no way an implementation can provide a
> zero-copy
> solution.
Leaving SSL aside, I don&#
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
; ByteBuffer.
>
If by copies you mean allocating new buffers and feeling them with the same
contents, then you are right. No copies are made.
However there is a natural need for multiple passes over the buffers, both
being sent and received. These are unavoidable transformations performed by SSL
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
.get(index).complete(null);
++index;
}
return -1;
}
}
private static class MyListener implements WebSocket.Listener
{
private final ByteBufferInputStream bbis = new ByteBufferInputStream();
@Override
public CompletionSta
30 lines) and may even be provided as a utility class
> by the JDK WebSocket implementers.
>
> The advantage is that ByteBufferInputStream can be written in a way
> that performs *zero* copies, thanks to the JDK 9 WebSocket APIs -
> add() would need to return a CompletableFuture.
>
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
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.
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
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 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 years now (e.g. create a
String from a ByteBuffer without copy).
There is
Hi,
On Mon, Feb 19, 2018 at 10:55 PM, Chuck Davis wrote:
>> Note also that your requirement is to use blocking, stream-based,
>> byte[]-based APIs.
>> If you had chosen a data format for which a non-blocking parser based
>> on ByteBuffer APIs existed, you would be so happy about the JDK 9
>> APIs
nt
> to complain you are in good (and conspicuous) company, as the JDK
> engineers appear to avoid the issue since years now (e.g. create a
> String from a ByteBuffer without copy).
> Having said that, the class is trivial to implement (a naive version I
> wrote is about 30 lines) an
ngineers appear to avoid the issue since years now (e.g. create a
String from a ByteBuffer without copy).
Having said that, the class is trivial to implement (a naive version I
wrote is about 30 lines) and may even be provided as a utility class
by the JDK WebSocket implementers.
The advantage is t
Further thought...
Maybe a single WebSocket but two different listeners the developer can
choose depending upon what type of stream is expected???
Hi Chris and others:
There is only one WebSocket documented in jdk9. I was happy to be able to
write a jdk9 client that connected to my server unchanged (using
Wildfly11). And there are features of jdk9 API that I rather like.
There are two vastly differing handling requirements. I certainly
On 18/02/18 20:12, Chuck Davis wrote:
...
RESULT: The formerly fabulous WebSocket has been rendered relatively
useless as a platform for building responsive, bidirectional
client/server applications. Am I the only person who sees this as a
HUGE regression of functionality?? I am ALARMED by
James, who taught you how to ruin other people's days? You seem to have
mastered the art..😐
There seems to be a move afoot to abandon serialization.hummm. Then it
needs to get fixed because converting everything to a text stream before
transmitting is not an option (for me at least). Th
until all messages are processed (i.e. each byte will have
> been copied somewhere between 1 and 10 times)
> bais = new ByteArrayInputStrea(byte[]);
> ois = new ObjectInputStream(bais);
> MyDTO = ois.readObject();
>
> DONE! More complicated, messy and very slow. (i.e. lo
1 - 100 of 288 matches
Mail list logo
