Re: [Springframework-developer] JMS remoting provider available

[<jue...@we...>]

James,
=20
OK, I see... I already assumed that it's not feasible to recreate a =
QueueRequest for each remote method invocation. However, even if the =
Session auto-reconnects in case of a JMS server restart (as a side note, =
is this really provided by all major JMS implementations? my JMS =
experience is too limited to tell), a Session is a single-threaded =
object, isn't it? So if the remote client side resides in a server (for =
example a web application talking to an external process), we shouldn't =
use one single Session from multiple threads... Correct me if I'm wrong =
in that assumption, of course.
=20
So as far as I can tell, we do need some sort of pooling here, to allow =
for proper concurrent invocations on a JMS remoting proxy. I agree that =
we should pool the QueueRequestors, not just the Sessions, to also avoid =
the recreation of the temporary queue. The idea with the TargetSource is =
interesting; it might still be worthwhile to put the pooling =
configuration into JmsInvokerClientInterceptor itself, though, for =
configuration convenience. After all, the QueueRequestors need to be =
pooled once there is more than one thread accessing the proxy... (and =
even standalone applications might use multiple threads doing backend =
work).
=20
Regarding the naming: We use the "xxx invoker" naming mainly if we use =
"xxx" in a special fashion, i.e. if plain "xxx" usually works =
differently. So "HTTP invoker" means transferring Spring =
RemoteInvocation objects over HTTP; "RMI invoker" means sending such =
Spring RemoteInvocations over RMI (in contrast to standard RMI). In the =
case of Hessian and Burlap, we use the native facilities of those =
protocols, i.e. the exposed services are always classic Hessian and =
Burlap without Spring specifics - we do not send Spring RemoteInvocation =
objects over the wire there. That's why they are not named "invoker".
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von jas...@ma...
Gesendet: Fr 29.10.2004 09:28
An: spr...@li...
Betreff: Re: [Springframework-developer] JMS remoting provider available




On 28 Oct 2004, at 21:14, j=FCrgen h=F6ller [werk3AT] wrote:
> James,
>
> I've looked at the JmsClientInterceptor in some more detail, and found
> that it uses the JMS QueueRequestor class (which I haven't seen in
> action before).

Its a JMS helper class. Its possible to implement in a slightly more
efficient way with timeouts and re-try support; but its a suitable
first implementation. We could get more advanced later on.


> I've noticed that QueueRequestor takes a Session and a Queue,
> internally creating a temporary queue for responses. However, in the
> current usage style, it would use the same Session for the entire
> lifetime of the JmsClientInterceptor bean (i.e. the entire
> application), and isn't properly closed on shutdown.

Good catch. I've just patched the code to support DisposableBean to
close down the session & queueRequestor.


> While that might not cause any issues in a standalone client
> environment, what about usage of JmsClientInterceptor in a J2EE
> environment, for example a web app invoking some external process? And
> what about the JMS Session used by the QueueRequestor becoming stale,
> for example through a restart of the JMS server?

Most decent JMS providers can handle auto-reconnection to the JMS
server if it goes down and full HA.


> It seems to me that we should get a Session via a given
> ConnectionFactory for each request here. In the J2EE case, this will
> usually be a pooled Session from a pooled Connection. In the
> standalone case, it can be from a single Connection, via Spring's
> SingleConnectionFactory.

Grabbing a session from a pool is a reasonable idea (though there's
also the MessageProducer, MessageConsumer and temporary Queue to
consider). Though creating JMS resources like session, consumer,
producer, each time you need to perform some kind of remote invocation
is a very bad idea - its really slow, since creating a
session/consumer/producer requires an RPC with the JMS server anyway :)

Sessions are pretty lightweight to keep around though; its Connections
that need to be pooled as they are the expensive resource; sessions are
much cheaper, though they are intended to be long lived objects.

In terms of pooling, the best idea is to pool the QueueRequestor; i.e.
pool the Session + temporary Queue + MessageProducer + MessageConsumer.
Then when you grab one from the pool its complete ready to be used -
you don't have to wait for a session or producer or consumer to be
created - all of which are pretty expensive operations, requiring an
RPC with the JMS server.

If further down the road we write a more complex kind of QueueRequestor
object, we could pool that too as a single unit since it'll always have
a Session, MessageProducer, MessageConsumer and temporary Queue.


> The problem with the ConnectionFactory approach is that we'd need to
> recreate a QueueRequestor instance for each request, with a freshly
> fetched Session. Does this mean that the QueueRequestor would create a
> new temporary Queue for each request in such a scenario?

Yes - which is a bad idea too, as creating a temporary queue requires
an RPC with the JMS server.

> I wonder if that's feasible... However, what's the alternative, given
> that we shouldn't keep using the same Session forever?

Well we could use the same session forever. Or we could pool the
QueueRequestor instances.

How about we use the same trick we just used on the JCAContainer - we
create an interface to represent some kind of JMS based QueueRequestor;
then we could use a single one for the duration of the client stub, or
we could introduce a pool using TargetSource?


> We could also add QueueRequestor/TopicRequestor support to
> JmsTemplate, offering "request" methods that throw unchecked
> JmsExceptions, fetching a fresh Session from the configured
> ConnectionFactory underneath. We could also offer a
> "requestAndConvert" method that takes Object as input message and also
> returns Object, analogous to "convertAndSend"/"receiveAndConvert".

Sounds great. I'd be nice to use the same JMS implementation code
underneath.


> Already touching 1.2 RC1 work here, I guess :-)

:)

> P.S.: I'd like to rename JmsClientInterceptor, JmsServiceExporter etc
> to JmsInvokerClientInterceptor respectively JmsInvokerServiceExporter.
> It's about serializing Spring's remote invocations through JMS, not
> about native remoting support in JMS, and I feel that we should
> reflect this in the name. We use the terms "HTTP invoker" and "RMI
> invoker" too, when serializing RemoteInvocations via HTTP or RMI.

Sounds good with me. Shouldn't we rename BurlapClientInterceptor and
HessianClientInterceptor too?

James
-------
http://radio.weblogs.com/0112098/



-------------------------------------------------------
This Newsletter Sponsored by: Macrovision
For reliable Linux application installations, use the industry's leading
setup authoring tool, InstallShield X. Learn more and evaluate
today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer