You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Christopher Piggott <cp...@gmail.com> on 2015/04/10 14:52:06 UTC
Async consumer (serial port component)
https://github.com/wz2b/camel-jssc/blob/master/src/main/java/com/autofrog/camel/JsscConsumer.java
Is this a reasonable way to have an event-driven listener (jssc in this
case) receive serial port events then push them up a camel route as they
arrive?
I still haven't gotten all of this working right. I backed up to just my
jssc component and found out it really wasn't working correctly. It
receives the serial events, but then everything seems to just hang. To
test it I just made a really simple route:
from("jssc:com10?baud=19200")
.process(new Processor() {
@Override
public void process(Exchange exchange) throws
Exception {
log.info("Inline processing");
}
});
and discovered the inline processor never gets called (ever).
Looking through all the examples I can find but I'm still not getting
this whole Async thing - it doesn't work the way I expect. What am I
missing?
Someone suggested that I should have my component emit null messages
when it has nothing to say. I like the creativity, but from a users'
perspective that doesn't seem like a great thing - what it means is
imposing upon the user a set of semantics to filter out dummy
messages. It's not a good pattern - components should be as intuitive
as possible. Imagine if you were attaching to a queue and it did that
- just sometimes emitted 'null' exchange that it's then up to you, the
user, to filter out.
One of my friends (who has more camel experience than me) is telling
me I'm trying to make camel do something it just wasn't meant to do...
and that the intent is that throughout the pipeline you've got a 1:1
exchange flow, except in cases where you have splitters and
aggregators. Does the mailing list agree?
What I'm putting together here is a zigbee message flow that goes like this:
[ Serial Port Component ] --> [ XBee Component ] --> [ ZDO/ZCL Component ]
The serial port component emits bytes. It doesn't know about messages
or message boundaries, just bytes.
The Xbee component accumulates and processes those bytes until it gets
enough of them to form a message. That could be after a single
exchange (from the serial port consumer) or lots of exchanges that it
put together. It might even get a lot of bytes and emit SEVERAL xbee
messages.
THe ZDO/ZCL component looks at those Xbee messages and if it makes up
a ZDO message it emits ZCL attributes. A ZDO "Report Attributes"
response contains a List<ZclAttribute> ... the ZDO/ZCL component emits
them separately so they can be dealt with, routed, multiplexed,
whatever. In other words I might want to store temperature separately
from burglar alarm depending on the Attribute ID.
I really want all of this to work within camel because that opens up
the entire world of what I can do with these messages. I also see the
IoT / Home Automation world being very disjointed in terms of hardware
and protocols, and I think Camel can go a long way to helping fix that
problem.
But I've been "stuck" in this same place for 2 weeks with little
forward movement, and it has been extremely frustrating.
Re: Async consumer (serial port component)
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Only time for short comment
Yeah you would hide all that inside the Camel component, so when you
have a complete message you can emit that from the consumer.
So that its a 1:1 message when Camel routes it.
On Fri, Apr 10, 2015 at 2:52 PM, Christopher Piggott <cp...@gmail.com> wrote:
> https://github.com/wz2b/camel-jssc/blob/master/src/main/java/com/autofrog/camel/JsscConsumer.java
>
> Is this a reasonable way to have an event-driven listener (jssc in this
> case) receive serial port events then push them up a camel route as they
> arrive?
>
> I still haven't gotten all of this working right. I backed up to just my
> jssc component and found out it really wasn't working correctly. It
> receives the serial events, but then everything seems to just hang. To
> test it I just made a really simple route:
>
> from("jssc:com10?baud=19200")
> .process(new Processor() {
> @Override
> public void process(Exchange exchange) throws
> Exception {
> log.info("Inline processing");
> }
> });
>
>
> and discovered the inline processor never gets called (ever).
>
> Looking through all the examples I can find but I'm still not getting
> this whole Async thing - it doesn't work the way I expect. What am I
> missing?
>
> Someone suggested that I should have my component emit null messages
> when it has nothing to say. I like the creativity, but from a users'
> perspective that doesn't seem like a great thing - what it means is
> imposing upon the user a set of semantics to filter out dummy
> messages. It's not a good pattern - components should be as intuitive
> as possible. Imagine if you were attaching to a queue and it did that
> - just sometimes emitted 'null' exchange that it's then up to you, the
> user, to filter out.
>
> One of my friends (who has more camel experience than me) is telling
> me I'm trying to make camel do something it just wasn't meant to do...
> and that the intent is that throughout the pipeline you've got a 1:1
> exchange flow, except in cases where you have splitters and
> aggregators. Does the mailing list agree?
>
>
> What I'm putting together here is a zigbee message flow that goes like this:
>
>
>
> [ Serial Port Component ] --> [ XBee Component ] --> [ ZDO/ZCL Component ]
>
>
> The serial port component emits bytes. It doesn't know about messages
> or message boundaries, just bytes.
>
>
> The Xbee component accumulates and processes those bytes until it gets
> enough of them to form a message. That could be after a single
> exchange (from the serial port consumer) or lots of exchanges that it
> put together. It might even get a lot of bytes and emit SEVERAL xbee
> messages.
>
>
> THe ZDO/ZCL component looks at those Xbee messages and if it makes up
> a ZDO message it emits ZCL attributes. A ZDO "Report Attributes"
> response contains a List<ZclAttribute> ... the ZDO/ZCL component emits
> them separately so they can be dealt with, routed, multiplexed,
> whatever. In other words I might want to store temperature separately
> from burglar alarm depending on the Attribute ID.
>
>
> I really want all of this to work within camel because that opens up
> the entire world of what I can do with these messages. I also see the
> IoT / Home Automation world being very disjointed in terms of hardware
> and protocols, and I think Camel can go a long way to helping fix that
> problem.
>
>
> But I've been "stuck" in this same place for 2 weeks with little
> forward movement, and it has been extremely frustrating.
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/