Re: [Resteasy-users] Pool for javax.ws.rs.client.Client objects?
By default, Resteasy only allows one connection per Client. You have to
use ResteadyClient(Builder) to expand this. Other than that, it should
be threadsafe.
Personally, I'd create the Client as an application-scoped CDI bean and
inject it, or create one with SPring and inject it, or create one in a
servlet listener and add it to ServletContext. If you create per
request, then you lose any socket connection pooling that Apache Http
Client does.
On 10/27/2014 8:21 PM, Savvas Andreas Moysidis wrote:
The question, I suppose, is whether Client implementations are
thread-safe or not which is something that is not stipulated by the
interface contract.
If they are(something which is sort of implied by the javadoc), then you
could maybe declare and use a single instance like the following? (in a
JavaEE context)
@Singleton
public class SomeService {
private Client restClient;
@PostConstruct
private void init() {
restClient = ClientBuilder.newClient();
}
.
// Use restClient object here
.
@PreDestroy
private void cleanUp() {
restClient.close();
}
}
On 27 October 2014 23:24, Mario Diana mariodi...@gmail.com
mailto:mariodi...@gmail.com wrote:
I'd be interested in hearing what common practice is regarding
pooled Client objects, too. Do people use the Apache objects pool
library? That's the only option I've heard of. Are there other
mainstream solutions?
Mario
On Oct 27, 2014, at 12:39 PM, Rodrigo Uchôa
rodrigo.uc...@gmail.com mailto:rodrigo.uc...@gmail.com wrote:
[...]
How should we implement a pool of Client objects in this scenario? Is
there a common solution?
Regards,
Rodrigo Uchoa.
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
mailto:Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
Re: [Resteasy-users] Pool for javax.ws.rs.client.Client objects?
Great, thanks for the input Bill.
On 29 October 2014 13:20, Bill Burke bbu...@redhat.com wrote:
By default, Resteasy only allows one connection per Client. You have to
use ResteadyClient(Builder) to expand this. Other than that, it should
be threadsafe.
Personally, I'd create the Client as an application-scoped CDI bean and
inject it, or create one with SPring and inject it, or create one in a
servlet listener and add it to ServletContext. If you create per
request, then you lose any socket connection pooling that Apache Http
Client does.
On 10/27/2014 8:21 PM, Savvas Andreas Moysidis wrote:
The question, I suppose, is whether Client implementations are
thread-safe or not which is something that is not stipulated by the
interface contract.
If they are(something which is sort of implied by the javadoc), then you
could maybe declare and use a single instance like the following? (in a
JavaEE context)
@Singleton
public class SomeService {
private Client restClient;
@PostConstruct
private void init() {
restClient = ClientBuilder.newClient();
}
.
// Use restClient object here
.
@PreDestroy
private void cleanUp() {
restClient.close();
}
}
On 27 October 2014 23:24, Mario Diana mariodi...@gmail.com
mailto:mariodi...@gmail.com wrote:
I'd be interested in hearing what common practice is regarding
pooled Client objects, too. Do people use the Apache objects pool
library? That's the only option I've heard of. Are there other
mainstream solutions?
Mario
On Oct 27, 2014, at 12:39 PM, Rodrigo Uchôa
rodrigo.uc...@gmail.com mailto:rodrigo.uc...@gmail.com wrote:
[...]
How should we implement a pool of Client objects in this scenario?
Is there a common solution?
Regards,
Rodrigo Uchoa.
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
mailto:Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
Re: [Resteasy-users] Pool for javax.ws.rs.client.Client objects?
Hi Rodrigo,
That's precisely what my example above showcases. :)
It may well be the case that the Client class is not thread-safe indeed but
can I ask though what evidence have you got to believe that?
Perhaps taking a look at the source code would clarify things? (or a
commiter following this thread could verify instead)
On 28 October 2014 01:23, Rodrigo Uchôa rodrigo.uc...@gmail.com wrote:
if Client implementations are thread-safe, shouldn't a single instance be
enough? Thus having a single instance for the whole app would do it. I
don't think it's the case.
On Mon, Oct 27, 2014 at 10:21 PM, Savvas Andreas Moysidis
savvas.andreas.moysi...@gmail.com wrote:
The question, I suppose, is whether Client implementations are
thread-safe or not which is something that is not stipulated by the
interface contract.
If they are(something which is sort of implied by the javadoc), then you
could maybe declare and use a single instance like the following? (in a
JavaEE context)
@Singleton
public class SomeService {
private Client restClient;
@PostConstruct
private void init() {
restClient = ClientBuilder.newClient();
}
.
// Use restClient object here
.
@PreDestroy
private void cleanUp() {
restClient.close();
}
}
On 27 October 2014 23:24, Mario Diana mariodi...@gmail.com wrote:
I'd be interested in hearing what common practice is regarding pooled
Client objects, too. Do people use the Apache objects pool library? That's
the only option I've heard of. Are there other mainstream solutions?
Mario
On Oct 27, 2014, at 12:39 PM, Rodrigo Uchôa rodrigo.uc...@gmail.com
wrote:
[...]
How should we implement a pool of Client objects in this scenario? Is
there a common solution?
Regards,
Rodrigo Uchoa.
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
Re: [Resteasy-users] Pool for javax.ws.rs.client.Client objects?
Savvas,
I have no evidence whatsoever. :)
But it seems strange to me that if implementations should be thread-safe,
this information is not written in bold in the javadocs :) Or it could be
decision left up to vendors to decide.
Anyway, if it is indeed thread-safe it makes things a lot easier since a
single instance can be used throughout the app.
On Tue, Oct 28, 2014 at 7:50 AM, Savvas Andreas Moysidis
savvas.andreas.moysi...@gmail.com wrote:
Hi Rodrigo,
That's precisely what my example above showcases. :)
It may well be the case that the Client class is not thread-safe indeed
but can I ask though what evidence have you got to believe that?
Perhaps taking a look at the source code would clarify things? (or a
commiter following this thread could verify instead)
On 28 October 2014 01:23, Rodrigo Uchôa rodrigo.uc...@gmail.com wrote:
if Client implementations are thread-safe, shouldn't a single instance be
enough? Thus having a single instance for the whole app would do it. I
don't think it's the case.
On Mon, Oct 27, 2014 at 10:21 PM, Savvas Andreas Moysidis
savvas.andreas.moysi...@gmail.com wrote:
The question, I suppose, is whether Client implementations are
thread-safe or not which is something that is not stipulated by the
interface contract.
If they are(something which is sort of implied by the javadoc), then you
could maybe declare and use a single instance like the following? (in a
JavaEE context)
@Singleton
public class SomeService {
private Client restClient;
@PostConstruct
private void init() {
restClient = ClientBuilder.newClient();
}
.
// Use restClient object here
.
@PreDestroy
private void cleanUp() {
restClient.close();
}
}
On 27 October 2014 23:24, Mario Diana mariodi...@gmail.com wrote:
I'd be interested in hearing what common practice is regarding pooled
Client objects, too. Do people use the Apache objects pool library? That's
the only option I've heard of. Are there other mainstream solutions?
Mario
On Oct 27, 2014, at 12:39 PM, Rodrigo Uchôa rodrigo.uc...@gmail.com
wrote:
[...]
How should we implement a pool of Client objects in this scenario? Is
there a common solution?
Regards,
Rodrigo Uchoa.
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
Re: [Resteasy-users] Pool for javax.ws.rs.client.Client objects?
right...took a quick look at the jsr spec (
http://download.oracle.com/otn-pub/jcp/jaxrs-2_0-fr-eval-spec/jsr339-jaxrs-2.0-final-spec.pdf)
but nothing seems to be mentioned about thread-safety in client-api
implementations...so, this seems to largely be an implementation property
rather than a spec requirement..
anyway, I dug through the implementation I am using (
*org.glassfish.jersey.client.JerseyClient*) and from what I can see the
method for generating *WebRequest*s at least seems to be perfectly
thread-safe:
@Override
public JerseyWebTarget target(String uri) {
checkNotClosed();
checkNotNull(uri, LocalizationMessages.CLIENT_URI_TEMPLATE_NULL());
return new JerseyWebTarget(uri, this);
}
(note: checkNotNull is some preconditions-checking library statically
imported and LocalizationMessages.CLIENT_URI_TEMPLATE_NULL() is an actual
method call using a bizarre naming convention I've never come across
before... )
with checkNotClosed() having an implementation of:
void checkNotClosed() {
checkState(!closedFlag.get(),
LocalizationMessages.CLIENT_INSTANCE_CLOSED());
}
and with the class variable closedFlag declared as:
private final AtomicBoolean closedFlag = new AtomicBoolean(false);
which of course is thread-safe.
So, using a single instance and invoking only the various flavours of the
target() method seems to be safe. Wouldn't be so sure about the various
provider registration methods though...
Savvas
On 28 October 2014 12:40, Rodrigo Uchôa rodrigo.uc...@gmail.com wrote:
Savvas,
I have no evidence whatsoever. :)
But it seems strange to me that if implementations should be thread-safe,
this information is not written in bold in the javadocs :) Or it could be
decision left up to vendors to decide.
Anyway, if it is indeed thread-safe it makes things a lot easier since a
single instance can be used throughout the app.
On Tue, Oct 28, 2014 at 7:50 AM, Savvas Andreas Moysidis
savvas.andreas.moysi...@gmail.com wrote:
Hi Rodrigo,
That's precisely what my example above showcases. :)
It may well be the case that the Client class is not thread-safe indeed
but can I ask though what evidence have you got to believe that?
Perhaps taking a look at the source code would clarify things? (or a
commiter following this thread could verify instead)
On 28 October 2014 01:23, Rodrigo Uchôa rodrigo.uc...@gmail.com wrote:
if Client implementations are thread-safe, shouldn't a single instance
be enough? Thus having a single instance for the whole app would do it. I
don't think it's the case.
On Mon, Oct 27, 2014 at 10:21 PM, Savvas Andreas Moysidis
savvas.andreas.moysi...@gmail.com wrote:
The question, I suppose, is whether Client implementations are
thread-safe or not which is something that is not stipulated by the
interface contract.
If they are(something which is sort of implied by the javadoc), then
you could maybe declare and use a single instance like the following? (in a
JavaEE context)
@Singleton
public class SomeService {
private Client restClient;
@PostConstruct
private void init() {
restClient = ClientBuilder.newClient();
}
.
// Use restClient object here
.
@PreDestroy
private void cleanUp() {
restClient.close();
}
}
On 27 October 2014 23:24, Mario Diana mariodi...@gmail.com wrote:
I'd be interested in hearing what common practice is regarding pooled
Client objects, too. Do people use the Apache objects pool library? That's
the only option I've heard of. Are there other mainstream solutions?
Mario
On Oct 27, 2014, at 12:39 PM, Rodrigo Uchôa rodrigo.uc...@gmail.com
wrote:
[...]
How should we implement a pool of Client objects in this scenario?
Is there a common solution?
Regards,
Rodrigo Uchoa.
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
Re: [Resteasy-users] Pool for javax.ws.rs.client.Client objects?
I have also been talking with people from the Jersey team. The conclusion
seem to be the same: There's a gap in the spec, it does not clearly states
wether Client implementations should be thread-safe or not.
However both RestEasy and Jersey have done it in a thread-safe manner.
Final conclusion: No need for pooling. A singleton should do it.
On Tue, Oct 28, 2014 at 9:37 PM, Savvas Andreas Moysidis
savvas.andreas.moysi...@gmail.com wrote:
right...took a quick look at the jsr spec (
http://download.oracle.com/otn-pub/jcp/jaxrs-2_0-fr-eval-spec/jsr339-jaxrs-2.0-final-spec.pdf)
but nothing seems to be mentioned about thread-safety in client-api
implementations...so, this seems to largely be an implementation property
rather than a spec requirement..
anyway, I dug through the implementation I am using (
*org.glassfish.jersey.client.JerseyClient*) and from what I can see the
method for generating *WebRequest*s at least seems to be perfectly
thread-safe:
@Override
public JerseyWebTarget target(String uri) {
checkNotClosed();
checkNotNull(uri, LocalizationMessages.CLIENT_URI_TEMPLATE_NULL());
return new JerseyWebTarget(uri, this);
}
(note: checkNotNull is some preconditions-checking library statically
imported and LocalizationMessages.CLIENT_URI_TEMPLATE_NULL() is an actual
method call using a bizarre naming convention I've never come across
before... )
with checkNotClosed() having an implementation of:
void checkNotClosed() {
checkState(!closedFlag.get(),
LocalizationMessages.CLIENT_INSTANCE_CLOSED());
}
and with the class variable closedFlag declared as:
private final AtomicBoolean closedFlag = new AtomicBoolean(false);
which of course is thread-safe.
So, using a single instance and invoking only the various flavours of the
target() method seems to be safe. Wouldn't be so sure about the various
provider registration methods though...
Savvas
On 28 October 2014 12:40, Rodrigo Uchôa rodrigo.uc...@gmail.com wrote:
Savvas,
I have no evidence whatsoever. :)
But it seems strange to me that if implementations should be thread-safe,
this information is not written in bold in the javadocs :) Or it could be
decision left up to vendors to decide.
Anyway, if it is indeed thread-safe it makes things a lot easier since a
single instance can be used throughout the app.
On Tue, Oct 28, 2014 at 7:50 AM, Savvas Andreas Moysidis
savvas.andreas.moysi...@gmail.com wrote:
Hi Rodrigo,
That's precisely what my example above showcases. :)
It may well be the case that the Client class is not thread-safe indeed
but can I ask though what evidence have you got to believe that?
Perhaps taking a look at the source code would clarify things? (or a
commiter following this thread could verify instead)
On 28 October 2014 01:23, Rodrigo Uchôa rodrigo.uc...@gmail.com wrote:
if Client implementations are thread-safe, shouldn't a single instance
be enough? Thus having a single instance for the whole app would do it. I
don't think it's the case.
On Mon, Oct 27, 2014 at 10:21 PM, Savvas Andreas Moysidis
savvas.andreas.moysi...@gmail.com wrote:
The question, I suppose, is whether Client implementations are
thread-safe or not which is something that is not stipulated by the
interface contract.
If they are(something which is sort of implied by the javadoc), then
you could maybe declare and use a single instance like the following? (in
a
JavaEE context)
@Singleton
public class SomeService {
private Client restClient;
@PostConstruct
private void init() {
restClient = ClientBuilder.newClient();
}
.
// Use restClient object here
.
@PreDestroy
private void cleanUp() {
restClient.close();
}
}
On 27 October 2014 23:24, Mario Diana mariodi...@gmail.com wrote:
I'd be interested in hearing what common practice is regarding pooled
Client objects, too. Do people use the Apache objects pool library?
That's
the only option I've heard of. Are there other mainstream solutions?
Mario
On Oct 27, 2014, at 12:39 PM, Rodrigo Uchôa
rodrigo.uc...@gmail.com wrote:
[...]
How should we implement a pool of Client objects in this scenario?
Is there a common solution?
Regards,
Rodrigo Uchoa.
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
[Resteasy-users] Pool for javax.ws.rs.client.Client objects?
Hi guys!
I have a client web application that uses the Client API to make REST calls
to a REST business layer.
The javax.ws.rs.client.Client docs clearly states that Client objects are
expensive to create and dispose, and only a small number of them should be
created, which makes me think they should be pooled somehow.
Our initial thought was to instantiate and then close every Client object
we use, making code like this:
public void doSomething() {
Client client = ClientBuilder.newClient();
//do a bunch of stuff here
client.close();
}
Every method that needs to invoke REST services are coded like the example
above. That means every time a client web request comes in, a new Client
object is created and then closed. The exact opposite of what the docs
advises us to do.
How should we implement a pool of Client objects in this scenario? Is there
a common solution?
Regards,
Rodrigo Uchoa.
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
Re: [Resteasy-users] Pool for javax.ws.rs.client.Client objects?
The question, I suppose, is whether Client implementations are thread-safe
or not which is something that is not stipulated by the interface contract.
If they are(something which is sort of implied by the javadoc), then you
could maybe declare and use a single instance like the following? (in a
JavaEE context)
@Singleton
public class SomeService {
private Client restClient;
@PostConstruct
private void init() {
restClient = ClientBuilder.newClient();
}
.
// Use restClient object here
.
@PreDestroy
private void cleanUp() {
restClient.close();
}
}
On 27 October 2014 23:24, Mario Diana mariodi...@gmail.com wrote:
I'd be interested in hearing what common practice is regarding pooled
Client objects, too. Do people use the Apache objects pool library? That's
the only option I've heard of. Are there other mainstream solutions?
Mario
On Oct 27, 2014, at 12:39 PM, Rodrigo Uchôa rodrigo.uc...@gmail.com
wrote:
[...]
How should we implement a pool of Client objects in this scenario? Is
there a common solution?
Regards,
Rodrigo Uchoa.
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
Re: [Resteasy-users] Pool for javax.ws.rs.client.Client objects?
if Client implementations are thread-safe, shouldn't a single instance be
enough? Thus having a single instance for the whole app would do it. I
don't think it's the case.
On Mon, Oct 27, 2014 at 10:21 PM, Savvas Andreas Moysidis
savvas.andreas.moysi...@gmail.com wrote:
The question, I suppose, is whether Client implementations are thread-safe
or not which is something that is not stipulated by the interface contract.
If they are(something which is sort of implied by the javadoc), then you
could maybe declare and use a single instance like the following? (in a
JavaEE context)
@Singleton
public class SomeService {
private Client restClient;
@PostConstruct
private void init() {
restClient = ClientBuilder.newClient();
}
.
// Use restClient object here
.
@PreDestroy
private void cleanUp() {
restClient.close();
}
}
On 27 October 2014 23:24, Mario Diana mariodi...@gmail.com wrote:
I'd be interested in hearing what common practice is regarding pooled
Client objects, too. Do people use the Apache objects pool library? That's
the only option I've heard of. Are there other mainstream solutions?
Mario
On Oct 27, 2014, at 12:39 PM, Rodrigo Uchôa rodrigo.uc...@gmail.com
wrote:
[...]
How should we implement a pool of Client objects in this scenario? Is
there a common solution?
Regards,
Rodrigo Uchoa.
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
