camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Piggott <>
Subject Async consumer (serial port component)
Date Fri, 10 Apr 2015 12:52:06 GMT

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

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:

                    .process(new Processor() {
                        public void process(Exchange exchange) throws
Exception {
                  "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

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

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

But I've been "stuck" in this same place for 2 weeks with little
forward movement, and it has been extremely frustrating.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message