Announcement Announcement Module
Collapse
No announcement yet.
Random Access Queue Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • amsmota
    started a topic Random Access Queue

    Random Access Queue

    I'm in the process of extending AbstractMessageChannel to obtain a Random Access Queue, is there something similar under way? Any suggestions on this? Should I publish the code in here?

    It's nothing complicated, though, just a simple wrapper around a Map.

  • Mark Fisher
    replied
    Spring Integration is now using the SpringSource Enterprise Bundle Repository. The FAQ demonstrates the ivy and maven configuration: http://www.springsource.com/repository/app/faq#q7

    While Spring Integration is in the milestone phase, you can use that same configuration but replacing "release" with "milestone" for the Spring Integration JARs.

    Leave a comment:


  • amsmota
    replied
    I see the M4 is out now (although I can't find it in the mvn repository) which is good for me because I have to use the latest from repo in my tests. Actually I can't do any tests for now as I'm working in another part of our app (Birt). But since I'm now integrating Birt with SI I would try to give it another shot.

    Once I can get it from the repo, I mean...

    One thing I already noted is that the changes I need for my use cases (that I implemented in extended versions of your classes) are not yet supported:

    Originally posted by amsmota View Post
    (...) My problem is the issues that I *do* need and you guys aren't going to implement, or at least didn't until now. As is the case of the Iterators in ResponseCorrelator, MessageStore, RetrievalBlockingMessageStore and SimpleMessageStore.
    Last edited by amsmota; May 26th, 2008, 07:00 AM.

    Leave a comment:


  • amsmota
    replied
    I am not expecting to have backward compatibility in a work-in-progress, nor do I mind to change my code or otherwise test, write, suggest or contribute in any way time allows me. My problem is the issues that I *do* need and you guys aren't going to implement, or at least didn't until now. As is the case of the Iterators in ResponseCorrelator, MessageStore, RetrievalBlockingMessageStore and SimpleMessageStore.

    I'm going to test the gateway thing now.

    Cheers.

    Leave a comment:


  • Mark Fisher
    replied
    Have a look at the GatewayProxyFactoryBeanTests located in the "org.springframework.integration.gateway" package (from SVN head) and the associated configuration files that are referenced from those test cases. The parser for a <gateway/> element will be available soon. For now, it is a pretty simple bean definition.

    Since the "gateway" code may be changing a bit before M4, any feedback is greatly appreciated. I'd be especially interested if this accommodates your use cases.

    -Mark

    Leave a comment:


  • iwein
    replied
    You're feeling the sting of being on the bleeding edge. You will not have backwards compatibility until the GA release comes out. On the other hand your customisations are pretty likely to be replaced with something better in the framework.

    The <gateway/> suggestion by Mark is not in the namespace yet.The only thing I can sensibly advise here is: patience. The other option you mentioned (personal branch) is not ideal (to say the least).

    Leave a comment:


  • amsmota
    replied
    Hello:

    I'm back on my service architecture, I updated the SI from the trunk and I noticed many changes, can you tell me what is the state of the art relating the RequestReplyTemplate, the Correlator and correlated issues?

    Basically, I have to decide to go ahead with my changes outside of SI (which I of course don't want to do) or wait for your solution (but I can't wait also...)

    Cheers.

    Leave a comment:


  • Mark Fisher
    replied
    Sorry, after some more thought, I realized that you would still have your first endpoint definition. The gateway would be an intermediary (rather than using RequestReplyTemplate or sending directly to a channel and then invoking correlator.getResponse()). For example, something more like this:
    Code:
    <endpoint input-channel="input"
             handler-ref="serviceimpl"
             handler-method="execute"
             default-output-channel="responses"/>
    
    <gateway id="serviceGateway"
             target-channel="input"
             response-channel="responses"/>
    Then you would invoke it like this:
    Code:
    Message response = serviceGateway.handle(message);
    Since this would be backed by a ProxyFactoryBean, you could also provide an interface for the proxy (other than the default MessageHandler):
    Code:
    <gateway id="serviceGateway"
             interface="com.foo.SomeService"
             target-channel="input"
             response-channel="responses"/>
    In that case, the code would be using the regular argument and return value of that interface, while the gateway proxy converts to and from Messages.

    What do you think?
    -Mark

    Leave a comment:


  • Mark Fisher
    replied
    Thanks so much for all of the feedback.

    I am thinking that the RequestReplyTemplate and ResponseCorrelator need to be encapsulated. It seems that all of this can be hidden inside a Messaging Gateway implementation (see http://eaipatterns.com/MessagingGateway.html). Something like the following would be used instead of your endpoint definitions:

    Code:
    <gateway id="serviceGateway"
             input-channel="input"
             handler="serviceimpl"
             method="execute"
             response-channel="responses"/>
    This might internally use RequestReplyTemplate and ResponseCorrelator, but the result would be a proxy for "serviceimpl" whose bean name is "serviceGateway".

    If an anonymous, temporary channel is sufficient, then the "response-channel" can be left out. Also, if the proxy should just implement MessageHandler, then the "method" should be left out.

    Your idea of falling back to async after a timeout is interesting and could probably be available as one strategy used by the gateway.

    Regards,
    Mark

    Leave a comment:


  • amsmota
    replied
    Continuing my changes, I finished the synchronous-that-falls-down-to-asynchronous-with-correlationId-when-timedout message type, which I integrated in the RequestReplyTemplate. Now probably this is getting too complex and should be separated like suggested in Jira INT-143.

    I feel a little uncomfortable with this kind of configuration

    <endpoint input-channel="input" handler-ref="serviceimpl" handler-method="execute" default-output-channel="responses"/>

    <endpoint input-channel="responses" handler-ref="correlator"/>
    but I don't know how to do it better.

    Anyhow I have to move to other implementations so I only be testing this furthermore in my "spare" time. If you want me to publish the code here I can clean it up a little, but probably there are better ways to do what I did.

    If I can be of assistance please let me know.

    Leave a comment:


  • amsmota
    replied
    'm afraid (and apologize for) I'm not understanding the big picture here. For example, I don't know what you mean by "subscribe". And I also can't figure out what does the <handler/> tag also.

    But nevertheless, this is the situation of my tests. In my config i had:

    Code:
    	<channel id="input"/>
    	<channel id="responses"/>
    
    	<endpoint input-channel="input" handler-ref="serviceimpl"
    		handler-method="execute" default-output-channel="responses"/>
    	
    	<beans:bean id="serviceimpl"
    		class="com.meridianp2p.stf.service.testservice.TestService"/>
    	
    	<beans:bean id="resource"
    		class="com.meridianp2p.stf.service.testservice.TestResource">
    		<beans:property name="requestChannel" ref="input"/>
    		<beans:property name="responseChannel" ref="responses"/>
    	</beans:bean>
    and now I have

    Code:
    	<channel id="input"/>
    	<channel id="responses"/>
    
    	<endpoint input-channel="input" handler-ref="serviceimpl"
    		handler-method="execute" default-output-channel="responses"/>
    	
    	<endpoint input-channel="responses" handler-ref="correlator"/>
    	
    	<beans:bean id="correlator" class="org.springframework.integration.handler.ResponseCorrelator"/>
    	
    	<beans:bean id="serviceimpl"
    		class="com.meridianp2p.stf.service.testservice.TestService"/>
    	
    	<beans:bean id="resource"
    		class="com.meridianp2p.stf.service.testservice.TestResource">
    		<beans:property name="requestChannel" ref="input"/>
    		<beans:property name="responseChannel" ref="responses"/>
    		<beans:property name="correlator" ref="correlator"/>
    	</beans:bean>
    It's working ok with the changes I've made to the ResponseCorrelator, but I don't see the point in having a response channel and a ResponseCorrelator to do only one thing.

    Other thing that worries me is the impact that all this will have when I change my intra-VM queues to JMS queues...

    Leave a comment:


  • amsmota
    replied
    Well, I have added this to the RequestReplyTemplate and it works for me.

    Code:
    	private final ResponseCorrelator correlator;
    
    	public RequestReplyTemplate(MessageChannel requestChannel, ResponseCorrelator correlator, ExecutorService executor) {
    		Assert.notNull(requestChannel, "'requestChannel' must not be null");
    		Assert.notNull(correlator, "'correlator' must not be null");
    		Assert.notNull(executor, "'executor' must not be null");
    		this.requestChannel = requestChannel;
    		this.correlator = correlator;
    		this.executor = executor;
    	}
    
    	public RequestReplyTemplate(MessageChannel requestChannel, ResponseCorrelator correlator) {
    		this(requestChannel, correlator, Executors.newSingleThreadExecutor());
    	}
    	
    	
    	public void requestCorrelator(final Message<?> requestMessage) {		
    		ReplyHandler replyHandler = new ReplyHandler() {
    			public void handle(Message<?> replyMessage, MessageHeader originalMessageHeader) {
    				correlator.handle(replyMessage);
    			}
    		};
    		request(requestMessage, replyHandler);
    		
    	}
    It misses some checks yet.

    However, reading the comments on the Jira it's not this that you want, or at least is only partially what you want?

    Leave a comment:


  • Mark Fisher
    replied
    You should be able to use the same basic configuration. Then just add a ResponseCorrelator that is subscribed to the "responses" channel. If you provide a reference to that correlator in your client code, then you can call responseCorrelator.getResponse(correlationId).

    Nevertheless, what I think we need to introduce is a way to do this at a higher level so that these configuration details are not so tedious. Also, it should be very consistent with the RequestReplyTemplate usage. There are a couple JIRA issues related to this. Feel free to add comments:
    http://jira.springframework.org/browse/INT-126
    http://jira.springframework.org/browse/INT-143

    Thanks,
    Mark

    Leave a comment:


  • amsmota
    replied
    So basically I can rewrite my code to use a ResponseCorrelator instead of my Response channel, but that way I cannot specify like I have

    <channel id="input"/>
    <channel id="responses"/>
    <endpoint input-channel="input" handler-ref="serviceimpl" handler-method="execute" default-output-channel="responses"/>

    or with my RandomAccessChannel

    <beans:bean id="responses" class="RandomAccessChannel"/>


    because I have to hand code the ResponseCorrelator that has it's own queue. Also I added a iterator to ResponseCorrelator, RetrievalBlockingMessageStore, MessageStore, SimpleMessageStore. And I miss a peek method, but I can have the same efect by looking for a null after a ResponseCorrelator.getResponse(key).

    I'll keep on testing tomorrow.

    Leave a comment:


  • amsmota
    replied
    Hello again:

    I started today to test the ResponseCorrelator and I'm having a heck of a time doing it. First, let me tell the things my RandomAccessChannel was doing and I can't accomplish with ResponseCorrelator.

    - a non-blocking request-response mechanism. When I try to get a response from the queue I want to return something similar to a 404 - Not Found, so the user can keep requesting the resource for the response whenever he wants until it gets it.

    - a iterator over the messages currently on hold in the queue. That way, a user can query the responseChannel without a msgId in which case he receives a list of all the msgId's currently on the queue, if working with a http connector in the form of hiperlinks to those msgs (very restfull )

    Besides this "wishes", I don't even am successful in simply testing it with a asynchronous request / response test, the id's never match...

    But I'm trying a little more, I was testing with the M3 from the repository, I'll try now with the version I downloaded from the trunk.

    Thanks a lot for your time.

    Leave a comment:

Working...
X