Announcement Announcement Module
Collapse
No announcement yet.
Channel Removal? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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

  • #2
    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

    Comment


    • #3
      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

      Comment


      • #4
        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

        Comment


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

          -Mark

          Comment


          • #6
            Thanks Mark,

            I've already downloaded sources and started testing.

            Wojtek

            Comment


            • #7
              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

              Comment


              • #8
                ReplyTo Header Property

                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

                Comment


                • #9
                  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

                  Comment


                  • #10
                    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.

                    Comment


                    • #11
                      message-converter?

                      In order for me to route the message, I would also need the message-converter to be registered; even better would be the ability to register the ChannelPublisher, because I can then plug everything into it.

                      Maybe I am missing something altogether, so let me just give you the use case in its entirety. Please advise me on how I could do the following (without overriding JmsMessageDrivenSourceAdapter; I will attempt that myself):

                      - JMSMessage arrives on a queue with a replyTo set by the client
                      - I want to route it to a Handler
                      - The handler sends N number of responses (e.g. think of a db cursor that is sent out as multiple messages as it iterates)
                      -all these messages are sent to the replyTo address as specified by the client (for now assume that it is a tempQueue, but may become a tcp, etc. in the future)

                      Thanks,

                      Vassil

                      Comment

                      Working...
                      X