Object pooling

[Tom Anderson]

Hi all,

I have some heavyweight objects that i would like to try pooling.

To be specific, they're JAX-WS (actually JBossWS) Service (and/or port)
objects. My observations so far are that they take hundreds of
milliseconds to make (if you count instantiation of the service,
instantiation of the port, and extra time taken the first time a method on
the port is called, it seems to be 200-800 ms, depending), and that the
spec doesn't guarantee that they're threadsafe (and as it happens, i
believe that in the JBossWS implementation, neither the service nor the
port is threadsafe).

That may not be that much time in the grand scheme of things, but some
guys in the sort of ops-infrastructure-architecture part of the project
are making worried noises about performance of the web service interfaces,
and i'd like to be able to reassure them.

I know the modern warnings about pooling, but this seems like a case where
it could be justified. Does that sound right?

So, what's the state of the art in object pooling? My default starting
point is Commons pooling:

http://commons.apache.org/pool/

But i note that it doesn't do generics. I would really like something that
does generics. I could wrap a generic wrapper round it fairly easily, but
i'd rather not have to. So, are there any other pooling implementations
around which use generics, or are otherwise preferable?

Thanks,
tom

 

[Robert Klemme]

I have some heavyweight objects that i would like to try pooling.

To be specific, they're JAX-WS (actually JBossWS) Service (and/or port)
objects. My observations so far are that they take hundreds of
milliseconds to make (if you count instantiation of the service,
instantiation of the port, and extra time taken the first time a method
on the port is called, it seems to be 200-800 ms, depending), and that
the spec doesn't guarantee that they're threadsafe (and as it happens, i
believe that in the JBossWS implementation, neither the service nor the
port is threadsafe).

That may not be that much time in the grand scheme of things, but some
guys in the sort of ops-infrastructure-architecture part of the project
are making worried noises about performance of the web service
interfaces, and i'd like to be able to reassure them.

I know the modern warnings about pooling, but this seems like a case
where it could be justified. Does that sound right?

So, what's the state of the art in object pooling? My default starting
point is Commons pooling:

http://commons.apache.org/pool/

But i note that it doesn't do generics. I would really like something
that does generics. I could wrap a generic wrapper round it fairly
easily, but i'd rather not have to. So, are there any other pooling
implementations around which use generics, or are otherwise preferable?

Since you are using web services which is a pretty much standard way of
accessing business logic I would expect some prepackaged solutions to be
available. If not, you could wrap your client code in a JCA connector
which then will be pooled almost automatically by your application
container (at least if it's JBoss but I am pretty sure that other's have
similar functionality).

Kind regards

robert

 

[Eric Sosman]

I have some heavyweight objects that i would like to try pooling.

To be specific, they're JAX-WS (actually JBossWS) Service (and/or port)
objects. My observations so far are that they take hundreds of
milliseconds to make (if you count instantiation of the service,
instantiation of the port, and extra time taken the first time a method
on the port is called, it seems to be 200-800 ms, depending), and that
the spec doesn't guarantee that they're threadsafe (and as it happens, i
believe that in the JBossWS implementation, neither the service nor the
port is threadsafe).
[...]
I know the modern warnings about pooling, but this seems like a case
where it could be justified. Does that sound right?

Yes. You're not really pooling the objects per se, but the
associated externals (ports, services, ...) that go with them, and
the investment in setting them up. It sounds very much like pooling
database connections or the like, entirely defensible.

To put it another way: When did "cache" become a dirty word?

 

[Lew]

To put it another way: When did "cache" become a dirty word?

Around when "cash" did.

The problem is the same with both - the real thing is great but there are too
many pretenders. People tire of fairy gold and become disillusioned.

On one recent project my rule of thumb was, "Anything that claims to be a
cache isn't."

Some so-called "caches" were slower than the operation they buffered, under
multi-threaded production loads that is, not single-threaded development
environments. Other "caches" sit on top of OS or hardware caches that already
are fast enough.

Such experiences are common enough that the pendulum has swung. People hear
"Premature optimization is the root of all evil," as if it were "Optimization
is the root of all evil."

They are as wrong as their antagonists; obsessive knee-jerk anti-optimization
is as bad as obsessive knee-jerk failed attempts to optimize. The art, and
the measure of one's intelligence and wisdom, lies in the choice of when and
where to optimize, based on evidence from reality.

--
Lew
<http://www.indopedia.org/The_Life_of_Brian.html>
Brian (to adoring crowd): You've got to think for yourself! You're all
individuals!
Crowd (in unison): Yes, we're all individuals!
Brian (to adoring crowd): You're all different!
Crowd (in unison): Yes, we're all different!
Single voice (from within the crowd): I'm not.

 

[Tom Anderson]

I have some heavyweight objects that i would like to try pooling.

To be specific, they're JAX-WS (actually JBossWS) Service (and/or port)
objects. My observations so far are that they take hundreds of
milliseconds to make (if you count instantiation of the service,
instantiation of the port, and extra time taken the first time a method
on the port is called, it seems to be 200-800 ms, depending), and that
the spec doesn't guarantee that they're threadsafe (and as it happens, i
believe that in the JBossWS implementation, neither the service nor the
port is threadsafe).
[...]
I know the modern warnings about pooling, but this seems like a case
where it could be justified. Does that sound right?

Yes. You're not really pooling the objects per se, but the
associated externals (ports, services, ...) that go with them, and the
investment in setting them up. It sounds very much like pooling
database connections or the like, entirely defensible.

Pooling the investment is an excellent way of looking at it, yes.

I'd be interested to know where the time taken to build these objects is
spent - i know initialising the service involves reading and parsing the
WSDL, and then doing something or other based on that, so i imagine that's
quite a bit of it.

To put it another way: When did "cache" become a dirty word?

After Thatcherism died out.

tom

 

[Tom Anderson]

Since you are using web services which is a pretty much standard way of
accessing business logic I would expect some prepackaged solutions to be
available.

So would i. I haven't come across any, though.

If not, you could wrap your client code in a JCA connector which then
will be pooled almost automatically by your application container

Man, it's all JCA today! This is something that would make a sensible
general-purpose tool, i suppose. How would you access it from application
code? Bind some kind of ServicePool into the JNDI namespace and look it
up? Or bind a PoolableService which gives out a different instance every
time it's looked up?

tom

 

[Arne Vajhøj]

I have some heavyweight objects that i would like to try pooling.

To be specific, they're JAX-WS (actually JBossWS) Service (and/or port)
objects. My observations so far are that they take hundreds of
milliseconds to make (if you count instantiation of the service,
instantiation of the port, and extra time taken the first time a method
on the port is called, it seems to be 200-800 ms, depending), and that
the spec doesn't guarantee that they're threadsafe (and as it happens, i
believe that in the JBossWS implementation, neither the service nor the
port is threadsafe).

That may not be that much time in the grand scheme of things, but some
guys in the sort of ops-infrastructure-architecture part of the project
are making worried noises about performance of the web service
interfaces, and i'd like to be able to reassure them.

I know the modern warnings about pooling, but this seems like a case
where it could be justified. Does that sound right?

So, what's the state of the art in object pooling? My default starting
point is Commons pooling:

http://commons.apache.org/pool/

But i note that it doesn't do generics. I would really like something
that does generics. I could wrap a generic wrapper round it fairly
easily, but i'd rather not have to. So, are there any other pooling
implementations around which use generics, or are otherwise preferable?

Pooling is an anti-pattern today for simple "just allocate memory
and initialize values without interacting with anything" objects.

Pools are completely standard for database connections.

I would go for the Apache Commons Pools. They work fine. And
I doubt that you will need to interact so many places that
a little bit of casting would be a problem.

Arne

 

[Arne Vajhøj]

So would i. I haven't come across any, though.

Axis allows you to define the scope of the service to request,
session or application.

The last will reuse. But it does require the service methods
to be individually thread safe. If that does not work for
you, then you need to look for another solution.

Man, it's all JCA today!

JCA does not seem to be a good fit for your requirement. You don't
need anything JCA specific. And you can do pools without it.

This is something that would make a sensible
general-purpose tool, i suppose. How would you access it from
application code? Bind some kind of ServicePool into the JNDI namespace
and look it up?

Yes.

Arne

 

[Robert Klemme]

Axis allows you to define the scope of the service to request,
session or application.

The last will reuse. But it does require the service methods
to be individually thread safe. If that does not work for
you, then you need to look for another solution.

That means you either create a bottleneck or have to do the pooling
internally.

JCA does not seem to be a good fit for your requirement. You don't
need anything JCA specific. And you can do pools without it.

Why not? Since you are talking to a remote system and _if_ there is
no built in solution in the app server used, then JCA seems like the
exact fit. Basically, talking to remote systems and exchanging
information is exactly what JCA was created for. And you can even
make it transactional. What makes you say it's not a good fit?

Kind regards

robert

 

[Arne Vajhøj]

That means you either create a bottleneck or have to do the pooling
internally.

No.

If the methods are thread safe you can make parallel calls
on the same object.

Why not? Since you are talking to a remote system and _if_ there is
no built in solution in the app server used, then JCA seems like the
exact fit. Basically, talking to remote systems and exchanging
information is exactly what JCA was created for. And you can even
make it transactional. What makes you say it's not a good fit?

JCA is for connecting to systems.

But you don't need it for the standard supported protocols: EJB,
Web Service, JMS etc..

And you don't need any of the special privileges of JCA: using
JNI, starting threads, listening to sockets etc..

And the CCI interface would make the API more cumbersome
not less cumbersome.

Arne

 

[Robert Klemme]

No.

If the methods are thread safe you can make parallel calls
on the same object.

They might still block internally. Either you have a pool internally
which needs some level of synchronization for handing out objects and
taking them back. Or you reuse the same instance which likely has some
state that is not thread sharable (a socket comes to mind). The whole
point of this thread was to pool what amounts to WS service objects
which, according to OP, are not guaranteed to be thread safe. Reusing a
single instance does not scale in this case.

JCA is for connecting to systems.

But you don't need it for the standard supported protocols: EJB,
Web Service, JMS etc..

And you don't need any of the special privileges of JCA: using
JNI, starting threads, listening to sockets etc..

And the CCI interface would make the API more cumbersome
not less cumbersome.

All good reasons. Thanks for taking the time!

Kind regards

robert

 

[Arne Vajhøj]

They might still block internally. Either you have a pool internally
which needs some level of synchronization for handing out objects and
taking them back. Or you reuse the same instance which likely has some
state that is not thread sharable (a socket comes to mind). The whole
point of this thread was to pool what amounts to WS service objects
which, according to OP, are not guaranteed to be thread safe. Reusing a
single instance does not scale in this case.

As I wrote "it does require the service methods to be individually
thread safe" and that was intended to mean natural not by internal
blocking.

But given the context then that scenario may indeed be rather unlikely.

Arne