Channel Removal?

Hi,

are there any plans to implement channel removal in ChannelRegistry?
I've managed to implement simple ChannelInvoker, taking JmsInvoker as an example, and it does really work. But the problem is, that I used the idea of temporary reply channels, which are created at the request phase and never destroyed.
Or, maybe I just don't know how-to unregister them ?

btw, good job. I really like the idea.

greets,
Wojtek

Wojtek,

Thanks for the suggestion. Providing an unregister method does indeed make sense. Feel free to raise the issue in Jira: http://jira.springframework.org/browse/INT

Regarding temporary channels, the current plan is to modify the Message 'replyChannelName' header so that actual references OR names can be used. In that case, a temporary channel would not need to be added to the registry at all - it would effectively be "anonymous" - only known to sender awaiting reply and the replier.

Thanks,
Mark

Hello Mark,

I've just raised an issue for channel removal (http://jira.springframework.org/browse/INT-88) and the second one (http://jira.springframework.org/browse/INT-89).
The latter is a feature request for channel based remoting layer. Please find an attachment with source code of what I've reached so far in making it works.

Greetings,
Wojtek

Thanks Wojtek.

I had a quick look at the channel invoker proxy/exporter. It's similar in some ways to what I've been working with for adding remoting (the plan is to support Spring-supported remoting protocols: RMI, HttpInvoker, Hessian/Burlap). However, I was trying to maintain loose coupling between method interception and channel adapters. In other words, there are already a few ways to pass messages between method invocations and channels: @Publisher, @Subscriber, MethodInvokingSource, and MethodInvokingTarget. None of those has any concern for remoting - instead, I was planning to provide the remoting support as channel adapters - so for example, an RmiSourceAdapter and RmiTargetAdapter. Rather than sending the RemoteInvocation as a message payload, these would be invoking send/receive on a remote channel. It's almost inside-out then - the RemoteInvocation would be the "send" and the RemoteInvocationResult would provide the Message.... the "local channel" would be a proxy for the "remote channel". I don't know if any of that makes sense, but let me know if I can clarify it a bit. My main motivation for taking that approach is to maintain the primacy of the asynchronous "Document Message"-driven model as opposed to an RPC model.

By the way, the registry's unregister method should be available shortly... I will post another comment here.

Thanks again,
Mark

The channel registry's unregister method is now available (on the SVN head): http://jira.springframework.org/browse/INT-88

-Mark

Thanks Mark,

I've already downloaded sources and started testing.

Wojtek

Wojtek,

Please let me know how it goes. I will also be experimenting a bit with the anonymous replyChannel (and 0-capacity "direct handoff" option for channels) as mentioned earlier.

Thanks again,
Mark

I think this question falls in the same category as the discussion above.

Situation:
I will get a message with a tempQueue as the replyTo destination. Looking at the milestone code, I see that the message is picked up by the ChannelPublishingJmsListener. It converts the transport specific JMS Message to the Spring Message format. However, in the process, we seem to lose the header.

Question:
-Am I missing something? If not is this a bug and the replyTo will go to the replyChannel?
-Would it be possible to inject the message converters/mappers into the ChannelPublishingJmsListener? This would allow me to plug-in my own logic if I have anything weird to do in terms of message production.

I would very much appreciate your response

Check out the very latest version. The 'message-converter' ref attribute is now available on <jms-source> (or you can of course use a generic <bean> element to define the JmsMessageDrivenSourceAdapter).

-Mark

Thanks for the amazingly quick response!

It took me a while to figure out some build issues, but registering the converter works now: I will test it in earnest tomorrow.

I did think of overriding the JmsMessageDrivenSourceAdapter, but what stopped me was that I would have had to overwrite a reasonably bulky function; I was hoping to be able to simply override a method like: newMessageConverter()... essentially the equivalent of injection. Anyway, your suggestion is better, so I will run with it.