answers in-lined at the bottom ...
On 16 Nov 2005, at 05:00, Peter Smith wrote:
Geez...this is probably going to cause
somebody a headache. I'm sorry about that - I am just trying to
understand how the architecture works
This email is specifically about the JMSFlow NMR flow type. I am
looking at the ServiceMix 2.0.1 JMSFlow code revision 749 which is
latest AFAIK. Unfortunately I am not in a position to be running this
yet, which means all this email is based just on me staring at the code
for a couple of hrs...
If somebody who knows the implementation details could go through this
and confirm my understanding of JMSFlow it would be a big help.
Here goes....
My understanding of JMSFlow
======================
- There is a main broadcast Topic and a number of Queues
(container specific Queues & Queues for each component)
- Topic is for broadcasting changes to remote containers
- Also for getting advisories if remote container
activated/deactivated
- Queue (per component) is for routing messages to...
- Queue (container) is also for routing messages...
- The JMSFlow instance seems to be the sole JMS MessageListener
for all these Queues/Topics
- The JMSFlow is also an ActiveMQ ConsumerAdvisoryEventListener
meaning it is notified of the start/stop of Consumers for the broadcast
Topic - ie when some other container runs the JMSFlow init/shutdown
- onMessage - JMS MessageListener for Queues/Topic
- ObjectMessage might be a MessageExchangeImpl (for message
routing) OR a ComponentPacketEvent (notifying some change in a remote
component)
- If ComponentPacketEvent
- add/update/remove local knowledge of the remote component
depending on the ComponentPacketEvent status
- If MessageExchangeImpl
- AbstractFlow.doRouting does message routing for the
incoming message to some local component
- onEvent(ConsumerAdvisoryEvent event). I think this is called
when some remote Consumer (ie container/JMSFlow instance) of the Topic
starts/stops
- If remote consumer is stopping
- trash all knowledge of the container components for the
remote container that is leaving
- If remote consumer is starting
- call onEvent(ComponentPacketEvent) for ALL of the LOCAL
container components. I think the main purpose of this is to make use
of the side effect to tell the remote container all the components that
are available to it from this local container. Presumably it there were
a dozen container then remote container 'X' is started then all the
other dozen would be advised that 'X' had started and they would madly
broadcast their respective components to the Topic so container 'X'
would learn about them.
- onEvent(ComponentPacketEvent event)
- I think this is called when a LOCAL component is
activated/deactivated
- Each component has a Queue associated with it and the
JMSFlow instance is the message listener for this Queue [see onMessage]
- Activation makes queue & consumer
- Deactivation closes the consumer for that component Queue
- doSend/doRouting - routing for outgoing messages...
- ObjectMessage send to either Queue for container or Queue
for specific component
QUESTIONS
==========
- In the init() method, how come the connection.start is called
prior to setting up the message listeners. Maybe it makes no difference
- just curious.
This doesn't make any difference - it's just habit on my part.
- I am a bit confused by the terminology "remote" used
throughout JMSFlow? Does it make any difference at all to JMSFlow if
the container (ie JMSFlow instance) is on another machine versus just
another container instance on the same machine. I think there is no
distinction - is that true?
That's correct - it doesn't make any difference to JMS where the other
instances of the JMSFlow are. However, the remote - methods are dealing
with ComponentPackets that are received from the broadcast topic - so
it's to make the distinction between locally activated packets and ones
created by other instances.
- If I understand the onEvent(ConsumerAdvisoryEvent event)
method correctly then that will mean that if a lot of containers get
started, then the same ComponentPacketEvents will be sent to the
broadcast Topic a number of times. That would mean most of the (already
started) containers will be told again and again about remote
components that they already know about. Is that true? How is the
addRemotePacket method is accounting for this scenario (???)
Yes this is true - but the ComponentRegistry only gets updated if it
doesn't already know about the activation of the Component
Quite a few JMS vendors allow for dynamic creation of destinations
(topics/queues) - ActiveMQ does this - and as the JMSFlow is dependant
on ActiveMQ (the advisories are outside the JMS spec) - I decided to
use this feature.
- If onEvent(ConsumerAdvisoryEvent event) is called whenever
some remote container starts, but because it in turn calls
onEvent(ComponentPacketEvent event) pretending to ACTIVATE local
components won't it just end up creating the same queues for the local
components over and over and over again (???)
Yep! Bug! Well spotted. The affect of this doesn't affect functionality
(as The Queue's don't created until a message is sent to them) but it
is a memory leak.
- I don't really understand the distinction of routing the
message to Queue (destination = INBOUND_PREFIX + componentName;) or
Queue (destination = INBOUND_PREFIX + id.getContainerName();). Can you
explain why the difference? It seems to be something like the "request"
going to the remote container Queue, and the "response" is going to the
component specific Queue - but why and what difference does it make
since either way the remote MessageListener is the same isn't it?
The routing is done this way because queue's will load balance delivery
of MessageExchanges. So you can have multiple component
instances listening to the same Queue. However, the response needs to
be sent back to the component that sent the exchange - as the sender
could have sent the exchange synchronously - and is waiting for a
response.
