Re: [Springframework-developer] JMS remoting provider available

[<jas...@ma...>]

On 29 Oct 2004, at 17:12, j=FCrgen h=F6ller [werk3AT] wrote:
> James,
>
> OK, I see... I already assumed that it's not feasible to recreate a=20
> QueueRequest for each remote method invocation. However, even if the=20=

> Session auto-reconnects in case of a JMS server restart (as a side=20
> note, is this really provided by all major JMS implementations? my JMS=20=

> experience is too limited to tell),

Most good ones do this. Though BEA doesn't :)

We could add a timeout which closes session/QueueRequestors down if a=20
reply isn't received in a maximum allowed time to recycle the pool.


> a Session is a single-threaded object, isn't it? So if the remote=20
> client side resides in a server (for example a web application talking=20=

> to an external process), we shouldn't use one single Session from=20
> multiple threads... Correct me if I'm wrong in that assumption, of=20
> course.

A session can only be used by one thread at once, yes. Though there's=20
no server side equivalent; the session is a client side, JMS client=20
thing. (To be a pedant, the session is used for transactions on the=20
server side; but other than that its purely a message decorator, to=20
help the JMS client multiplex messaging on the client side).


> So as far as I can tell, we do need some sort of pooling here, to=20
> allow for proper concurrent invocations on a JMS remoting proxy. I=20
> agree that we should pool the QueueRequestors, not just the Sessions,=20=

> to also avoid the recreation of the temporary queue. The idea with the=20=

> TargetSource is interesting; it might still be worthwhile to put the=20=

> pooling configuration into JmsInvokerClientInterceptor itself, though,=20=

> for configuration convenience.

Agreed. Though I guess it depends on the client side stub; if a client=20=

side stub only allows 1 remote request at once on any thread, then=20
there's no absolute need for pooling.

Though using pooling from the start is a good idea; as it means you=20
could have 10,000 remote client stub objects, but only use, say, 5=20
QueueRequestor's concurrently.


> After all, the QueueRequestors need to be pooled once there is more=20
> than one thread accessing the proxy... (and even standalone=20
> applications might use multiple threads doing backend work).

Agreed. I think a bigger reason for pooling is reducing resource load=20
rather than concurrent access to a client stub; so we can have huge=20
numbers of lightweight client stubs, which only use a QueueRequestor=20
from the pool when they are needed.


> Regarding the naming: We use the "xxx invoker" naming mainly if we use=20=

> "xxx" in a special fashion, i.e. if plain "xxx" usually works=20
> differently. So "HTTP invoker" means transferring Spring=20
> RemoteInvocation objects over HTTP; "RMI invoker" means sending such=20=

> Spring RemoteInvocations over RMI (in contrast to standard RMI). In=20
> the case of Hessian and Burlap, we use the native facilities of those=20=

> protocols, i.e. the exposed services are always classic Hessian and=20
> Burlap without Spring specifics - we do not send Spring=20
> RemoteInvocation objects over the wire there. That's why they are not=20=

> named "invoker".

Cool - thanks for the explanation.

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