You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Harald Wellmann <ha...@gmx.de> on 2011/03/14 21:33:38 UTC
Asynchronous Remoting with Futures
Is it possible to combine remoting by proxy
(http://camel.apache.org/spring-remoting.html) with asynchronous
request/reply (http://camel.apache.org/async.html) to achieve some sort
of equivalent to EJB 3.1 @Asynchronous invocations?
E.g.
@Stateless
@Remote(CalculatorService.class)
public class CalculatorServiceImpl implements CalculatorService {
@Asynchronous
public Future<Integer> add(int a, int b) {
// ...
}
}
If so, which transports are supported (JMS, HTTP, ...)? If not, is
something like this on the Camel roadmap at all?
Best regards,
Harald
Re: Asynchronous Remoting with Futures
Posted by ebergner <em...@gmail.com>.
Actually it turns out that it is not working. So the original question is
still valid. I've stepped through the code a little and I notice that when
it gets here (in JmsBinding):
protected JmsMessageType getJMSMessageTypeForBody(Exchange exchange, Object
body, Map<String, Object> headers, Session session, CamelContext context) {
JmsMessageType type = null;
// let body determine the type
if (body instanceof Node || body instanceof String) {
type = Text;
} else if (body instanceof byte[] || body instanceof GenericFile || body
instanceof File || body instanceof Reader
|| body instanceof InputStream || body instanceof ByteBuffer ||
body instanceof StreamCache) {
type = Bytes;
} else if (body instanceof Map) {
type = Map;
} else if (body instanceof Serializable) {
type = Object;
} else if
(exchange.getContext().getTypeConverter().convertTo(File.class, body) !=
null
||
exchange.getContext().getTypeConverter().convertTo(InputStream.class, body)
!= null) {
type = Bytes;
}
return type;
}
because Future is not Serializable, it will try to convert it to either a
File or an InputStream. Then it discovers that it is actually a future
object and gets the result. It is still trying to convert to either File or
Inputstream though, so this is what I tries to convert the Future result to
as well. Since my Response class does not have a TypeConverter to neither
File nor InputStream, the conversion results in Void.
Right now I have solved this by implementing a fallback TypeConverter on the
server that converts from a Serializable object to InputStream and byte[].
And a fallback TypeConverter on the client that converts from byte[] to a
Serializable object.
Should that be necessary or am I missing something? Any help would be very
much appreciated.
Thanks,
Emil
--
View this message in context: http://camel.465427.n5.nabble.com/Asynchronous-Remoting-with-Futures-tp3606370p4925187.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Asynchronous Remoting with Futures
Posted by ebergner <em...@gmail.com>.
Oh this is embarrassing. My Response object wasn't Serializable. Everything
works now. I'm surprised no exceptions were thrown though.
Sorry about that,
Emil
--
View this message in context: http://camel.465427.n5.nabble.com/Asynchronous-Remoting-with-Futures-tp3606370p4922915.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Asynchronous Remoting with Futures
Posted by ebergner <em...@gmail.com>.
Hi,
I'm trying to do something like this:
public interface Responder {
Future<Response> respond(Request request);
}
But the result I get from the received Future in the client is always null.
If I change the type to Future<String> everything works fine though. Do I
need to do anything extra to be able to return Futures containing my own
POJOs as results (the only example that I've seen uses Integer)?
Thanks,
Emil
--
View this message in context: http://camel.465427.n5.nabble.com/Asynchronous-Remoting-with-Futures-tp3606370p4922755.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Asynchronous Remoting with Futures
Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Apr 9, 2011 at 1:56 PM, Harald Wellmann <ha...@gmx.de> wrote:
> I've tested this with a small example using Camel 2.8-SNAPSHOT and Future<T>
> over JMS, which works fine.
>
Thats great.
> The only problem I'm having is not related to the new features, but rather
> to thread pool configuration, e.g. to increase the reply timeout.
>
> From http://camel.apache.org/threading-model.html I can see I somehow need
> to configure a ThreadPoolProfile and/or an ExecutorServiceStrategy, but I
> can't figure out how to do this in Java - all the examples use Spring XML
> with Camel extensions, but I'm trying to use Java Config wherever possible
> and I'm hoping to get rid of XML contexts with Spring 3.1...
>
You can always find examples in the unit test.
I assume you have read
http://camel.apache.org/threading-model.html
Camel in Action book chapter 10 shows you how to use that in both XML and Java.
Check out ExecutorServiceStrategy from CamelContext. Which has Java
API for the threading model.
And you can enlist custom thread pools in the Registry (for example
using SimpleRegistry) if you dont use Spring.
> Best regards,
> Harald
>
>> Am 31.03.2011 11:57, schrieb davsclaus:
>>>
>>> This has been implemented in Camel 2.8. You can now use Future in your
>>> client
>>> interfaces, and the invocation will now be asynchronous.
>>>
>>> And there is a little example here
>>> https://cwiki.apache.org/confluence/display/CAMEL/Using+CamelProxy
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
CamelOne 2011: http://fusesource.com/camelone2011/
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Asynchronous Remoting with Futures
Posted by Harald Wellmann <ha...@gmx.de>.
I've tested this with a small example using Camel 2.8-SNAPSHOT and
Future<T> over JMS, which works fine.
The only problem I'm having is not related to the new features, but
rather to thread pool configuration, e.g. to increase the reply timeout.
From http://camel.apache.org/threading-model.html I can see I somehow
need to configure a ThreadPoolProfile and/or an ExecutorServiceStrategy,
but I can't figure out how to do this in Java - all the examples use
Spring XML with Camel extensions, but I'm trying to use Java Config
wherever possible and I'm hoping to get rid of XML contexts with Spring
3.1...
Best regards,
Harald
> Am 31.03.2011 11:57, schrieb davsclaus:
>> This has been implemented in Camel 2.8. You can now use Future in your
>> client
>> interfaces, and the invocation will now be asynchronous.
>>
>> And there is a little example here
>> https://cwiki.apache.org/confluence/display/CAMEL/Using+CamelProxy
Re: Asynchronous Remoting with Futures
Posted by Harald Wellmann <ha...@gmx.de>.
Cool, thanks :-) I'll check this out and give you some feedback.
Best regards,
Harald
Am 31.03.2011 11:57, schrieb davsclaus:
> This has been implemented in Camel 2.8. You can now use Future in your client
> interfaces, and the invocation will now be asynchronous.
>
> And there is a little example here
> https://cwiki.apache.org/confluence/display/CAMEL/Using+CamelProxy
>
> -----
> Claus Ibsen
Re: Asynchronous Remoting with Futures
Posted by davsclaus <ci...@yahoo.dk>.
This has been implemented in Camel 2.8. You can now use Future in your client
interfaces, and the invocation will now be asynchronous.
And there is a little example here
https://cwiki.apache.org/confluence/display/CAMEL/Using+CamelProxy
-----
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
--
View this message in context: http://camel.465427.n5.nabble.com/Asynchronous-Remoting-with-Futures-tp3606370p4273033.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Asynchronous Remoting with Futures
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
On Fri, Mar 18, 2011 at 10:08 PM, Harald Wellmann
<ha...@gmx.de> wrote:
> The point is, I don't want to use any Camel APIs in my application code, all
> my service clients and service implementations are Bean endpoints, and all
> the Camel plumbing should happen in the Spring Configuration.
>
See
http://camel.apache.org/using-camelproxy.html
> Example:
>
> public interface Calculator {
>
> // long running implementation
> Future<Integer> add(int a, int b);
> }
>
>
> public class CalculatorClient {
>
> @Inject
> private Calculator calculatorProxy;
>
> public void calculate() {
>
> // returns immediately
> Future<Integer> sum = calculatorProxy.add(2, 3);
>
> // do something else
>
> Integer theSum = sum.get();
> System.out.println(sum);
> }
>
>
> So the ProducerTemplate and the Future API won't help at all. I'm currently
> trying to create my own FutureComponent, derived from SedaComponent, which
> will allow me to use routes like
>
> from("bean:calcClient").to("future:calc").to("bean:calcImpl")
>
> or in a client-server scenario with JMS in between:
>
> // Client VM
> from("bean:calcClient").to("future:calc").to("jms:queue:calc")
>
> // Server VM
> from("jms:queue:calc").to("bean:calcImpl")
>
>
> I can't help feeling there must be an easier way of doing this, but I just
> don't see how...
>
> Best regards,
> Harald
>
> Am 16.03.2011 08:24, schrieb Willem Jiang:
>>
>> If you are write your own component, you can use the camel async API[1]
>> to do work asynchronously.
>>
>> But as you are using the client API to send the request into the camel
>> route, you need to leverage the Feature API[2]
>>
>> [1]http://camel.apache.org/asynchronous-processing.html
>> [2]http://camel.apache.org/async.html
>>
>>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Asynchronous Remoting with Futures
Posted by Harald Wellmann <ha...@gmx.de>.
The point is, I don't want to use any Camel APIs in my application code,
all my service clients and service implementations are Bean endpoints,
and all the Camel plumbing should happen in the Spring Configuration.
Example:
public interface Calculator {
// long running implementation
Future<Integer> add(int a, int b);
}
public class CalculatorClient {
@Inject
private Calculator calculatorProxy;
public void calculate() {
// returns immediately
Future<Integer> sum = calculatorProxy.add(2, 3);
// do something else
Integer theSum = sum.get();
System.out.println(sum);
}
So the ProducerTemplate and the Future API won't help at all. I'm
currently trying to create my own FutureComponent, derived from
SedaComponent, which will allow me to use routes like
from("bean:calcClient").to("future:calc").to("bean:calcImpl")
or in a client-server scenario with JMS in between:
// Client VM
from("bean:calcClient").to("future:calc").to("jms:queue:calc")
// Server VM
from("jms:queue:calc").to("bean:calcImpl")
I can't help feeling there must be an easier way of doing this, but I
just don't see how...
Best regards,
Harald
Am 16.03.2011 08:24, schrieb Willem Jiang:
> If you are write your own component, you can use the camel async API[1]
> to do work asynchronously.
>
> But as you are using the client API to send the request into the camel
> route, you need to leverage the Feature API[2]
>
> [1]http://camel.apache.org/asynchronous-processing.html
> [2]http://camel.apache.org/async.html
>
>
Re: Asynchronous Remoting with Futures
Posted by Willem Jiang <wi...@gmail.com>.
If you are write your own component, you can use the camel async API[1]
to do work asynchronously.
But as you are using the client API to send the request into the camel
route, you need to leverage the Feature API[2]
[1]http://camel.apache.org/asynchronous-processing.html
[2]http://camel.apache.org/async.html
On 3/16/11 2:13 AM, Harald Wellmann wrote:
> Am 15.03.2011 15:04, schrieb Claus Ibsen:
>>
>> We could maybe detect the return type is a Future, and offer support
>> for that. I don't know how easy that would be.
>>
>> That said its my impression that its only a few Camel end users who
>> needs to use the Future API.
>
> Hmm, if you don't use Futures, is there any other way of getting the
> asynchronous result of a proxy method call? Or is everybody directly
> using send/receive without service proxies?
>
> Some background for my question: I started looking into Camel as a
> possible replacement for Lingo, which we're using in our project in
> production. (Lingo is no longer maintained and only works for us with a
> bunch of patches.)
>
> But it seems that camel-jms only has a subset of Lingo's features (and
> possibly some others) - we're heavily using EventListener callbacks with
> Lingo. It may be a matter of taste whether or not Futures are preferable
> to listeners and callbacks, but as long as Camel supports neither, I
> guess we're stuck with Lingo.
>
> Best regards,
> Harald
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Re: Asynchronous Remoting with Futures
Posted by Harald Wellmann <ha...@gmx.de>.
Am 15.03.2011 15:04, schrieb Claus Ibsen:
>
> We could maybe detect the return type is a Future, and offer support
> for that. I don't know how easy that would be.
>
> That said its my impression that its only a few Camel end users who
> needs to use the Future API.
Hmm, if you don't use Futures, is there any other way of getting the
asynchronous result of a proxy method call? Or is everybody directly
using send/receive without service proxies?
Some background for my question: I started looking into Camel as a
possible replacement for Lingo, which we're using in our project in
production. (Lingo is no longer maintained and only works for us with a
bunch of patches.)
But it seems that camel-jms only has a subset of Lingo's features (and
possibly some others) - we're heavily using EventListener callbacks with
Lingo. It may be a matter of taste whether or not Futures are preferable
to listeners and callbacks, but as long as Camel supports neither, I
guess we're stuck with Lingo.
Best regards,
Harald
Re: Asynchronous Remoting with Futures
Posted by Claus Ibsen <cl...@gmail.com>.
I created a ticket
https://issues.apache.org/jira/browse/CAMEL-3790
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Asynchronous Remoting with Futures
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
On Mon, Mar 14, 2011 at 9:33 PM, Harald Wellmann <ha...@gmx.de> wrote:
> Is it possible to combine remoting by proxy
> (http://camel.apache.org/spring-remoting.html) with asynchronous
> request/reply (http://camel.apache.org/async.html) to achieve some sort of
> equivalent to EJB 3.1 @Asynchronous invocations?
>
>
> E.g.
>
> @Stateless
> @Remote(CalculatorService.class)
> public class CalculatorServiceImpl implements CalculatorService {
>
> @Asynchronous
> public Future<Integer> add(int a, int b) {
> // ...
> }
> }
>
>
> If so, which transports are supported (JMS, HTTP, ...)? If not, is something
> like this on the Camel roadmap at all?
>
The ProducerTemplate API has methods for sending messages using Future.
However AFAIK it's not implemented into the @Produce or @InOut @InOnly
annotations of Camel
We could maybe detect the return type is a Future, and offer support
for that. I don't know how easy that would be.
That said its my impression that its only a few Camel end users who
needs to use the Future API.
But if its not to troublesome to implement its of course a nice
feature to have in Camel. Transparent proxy with the Future handle.
> Best regards,
> Harald
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/