Re: [Springframework-developer] JMS remoting provider available

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

James,
=20
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).
=20
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.=20
=20
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?
=20
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.
=20
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? I wonder if =
that's feasible... However, what's the alternative, given that we =
shouldn't keep using the same Session forever?
=20
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".
=20
Already touching 1.2 RC1 work here, I guess :-)
=20
Looking forward to your thoughts,
=20
Juergen
=20
=20
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.
=20

________________________________

Von: spr...@li... im Auftrag =
von jas...@ma...
Gesendet: Mi 27.10.2004 20:56
An: spr...@li...
Betreff: Re: [Springframework-developer] JMS remoting provider available



On 27 Oct 2004, at 19:40, j=FCrgen h=F6ller [werk3AT] wrote:
> OK - thanks for the prompt response, James. I fully understand the
> effect of the JCAContainer; it's just that this is big enough to
> warrant Spring 1.2 :-) I'd prefer to publically introduce all those
> JMS-related new features in Spring 1.2 RC1, rather than in a 1.1.x
> point release. 1.2 RC1 is scheduled for early January, so isn't too
> far away...

Sounds great with me. We can have it all nicely documented by January
with a few more examples.

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



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer