It should be used only for tasks which need to be scheduled.
Effectively there is only single task like that in the API right
now: delayed reconnect of SseEventSource.
Regards,
Pavel
toggle quoted messageShow quoted text
On 11/07/2017 12:52, Sergey Beryozkin
wrote:
Hi Pavel, thanks,
OK, what about the ScheduledExecutorService - how can the client
API implementation know when to use this one
if the ExecutorService is also set ?
Cheers, Sergey
On 11/07/17 10:12, Pavel Bucek wrote:
Hi Sergey,
yes, that is correct.
Regards,
Pavel
On 11/07/2017 10:35, Sergey
Beryozkin wrote:
Hi Pavel
These executor services, if set in the client builder -
should they be used in the rx() flows ?
Thanks, Sergey
On 11/07/17 00:12, Pavel Bucek wrote:
Hi Andy,
firstly, thanks for your kind words.
Your pull request was merged - good that you brought that
up. Thanks!
Best regards,
Pavel
On 07/07/2017 14:38, Andy
McCright wrote:
Hi Pavel,
Thank you for the clarification, and my
apologies for bringing this up so late - a colleague
and I ran into some confusion on this point, so I
thought I would bring if forward in hopes that other
users might avoid a similar confusion.
I have opened a pull request [1] with my
suggested changes to the javadoc. I think this may
help users better understand the differences in the
Java SE vs EE environments.
Thanks again - it has been a pleasure
working with you in this expert group!
Andy
-----
Original message -----
From: "Pavel Bucek" <pavel.bucek@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: Re: [jaxrs] Proposed Final Draft
Date: Fri, Jul 7, 2017 12:25 AM
Hi Andy,
it is very late for changing anything..
We are not saying that on Java EE environment
ClientBuilder#executorService and
#scheduledExecutorService have no effect - but it
might sound that way.
The "default" for Java SE is NOT
ForkJoinPool#commonPool, since it is not meant for
I/O operations. On Java SE, the default is
intentionally left as implementation specific.
And I'm not sure what you mean by "what about
Future Objects returned from ..." - if there is any
need for starting a thread, it should be done on the
executor service provided in the client builder.
Note that the javadoc for
ClientBuilder#executorService mentions:
*
Provided executor service will be used for
executing asynchronous tasks.
And Invocation#buildGet() (and others):
*
Submit the request for an asynchronous
invocation and receive a future
*
response back.
Which seem to imply what I wrote..
It might be still possible to tweak the javadoc,
I'll wait for your reaction - whether this makes
sense or not and then will inquire about possible
javadoc adjustment.
Thanks and regards,
Pavel
On 07/07/2017 00:35, Andy McCright wrote:
Hi Pavel,
If it is not too late, I'm
wondering if we could clarify the uses of
ClientBuilder.executorService(...) and
scheduledExecutorService(...).
Are we saying that in a Java EE
environment, these methods have no effect? If
so, can we change this text:
When running in a Java EE
container, implementations are required to use
the container-managed executor service.
to:
When running in a Java EE
container, this method will have no effect.
The container will always use the
container-managed executor service.
and a similar change for the
executorService method?
If instead we are saying that in
a Java EE container, the default ES and SES
are different than in Java SE, we should
clarify it like this:
When running in a Java EE
container, the default scheduled executor
service will be the container-managed service.
In Java SE, this will be the ForkJoinPool
service.
I think we should also clarify
what methods will use these services. The
javadoc currently provides some guidance with:
* @see
Invocation.Builder#async()
* @see Invocation.Builder#rx()
* @see
RxInvokerProvider#getRxInvoker(SyncInvoker,
ExecutorService)
and
* @see
SseEventSource.Builder#reconnectingEvery(long,
TimeUnit)
but what about Future objects
returned from methods like
buildGet().submit(...)?
Thanks,
Andy
J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...
----- Original
message -----
From: "Pavel Bucek" <pavel.bucek@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: [jaxrs] Proposed Final Draft
Date: Thu, Jun 22, 2017 6:18 AM
Dear
experts,
we'd like to announce that Proposed Final
Draft was published on JCP JSR
370 page [1].
I'd like to encourage you all to review
provided artifacts and let us
know if you have any feedback.
Thanks and regards,
Pavel & Santiago
[1] https://jcp.org/en/jsr/detail?id=370
|