We should use the Queue for Remote Communication and therefore
we should use Queries to get Entries from the Queue.
(instead to have a central listener that distribute the entries
to the workflow processes (distributed systems!)).
Please use for the first implementation configurable timeout
values
(it should be no problem to use higher values than 1 second,
or?)
Mit freundlichen Grüßen /
Kind regards
Sebastian Voigt
brox IT-Solutions
GmbH
==================================
According to Section 80 of the German Corporation Act brox IT-Solutions GmbH
must indicate the following information.
Address: An der Breiten Wiese 9, 30625 Hannover Germany
General Manager: Hans-Chr. Brockmann
Registered Office: Hannover, Commercial Register Hannover HRB 59240
========== Legal Disclaimer ==========
From:
smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] On
Behalf Of Ivan Churkin
Sent: Wednesday, July 30, 2008 4:12 PM
To: smila-dev@xxxxxxxxxxx
Subject: [smila-dev] new router/listener
Hi Sebastian
Router/Listener based on new principles is working.
(Its possible to manage working threads by JMX, using multiples brokers,
switching MQ implementations and specifying task execution list in
configuration.)
(Its not included into main build and not used by connectivity etc.)
For testing include into workspace all new bundles from trunc
org.beanshell
org.eclipse.eilf.jms
org.eclipse.eilf.jms.activemq
org.eclipse.eilf.connectivity.queue.worker
org.eclipse.eilf.connectivity.queue.worker.test
Test it by running launch configuration
org.eclipse.eilf.connectivity.queue.worker.test/WorkerTest.launch
It was found a problem with ActiveMQ
I pushed into queue just only 2500 messages before listening
and after that consumer was unable to receive messages.
I guess that it was because now consumer collect messages synchronously in
working thread
message = _consumer.receive(TIMEOUT);
(TIMEOUT was equals to 1 sec)
I think that ActiveMQ is unable to find message in durable storage by Condition
in this timeout and always return NULL!
Solutions:
1) I did TIMEOUT configurable by Rule XML tag, increase it and to forget.
2) We may try to use more fast database when Derby as ActiveMQ durable message
storage.
But all that solutions are only partial.
There is totally different solution:
To get message from consumer without condition and to check Condition inside
Listener.
That also helps to solve the second problem: "Condition syntax does not
specified in JMS and depends on broker implementation"
In this solution condition syntax in Rules will be independent from broker
implementation.
But, of course, there is also a disadvantage:
Listener will get every message from queue and, if rule will not be found,
message will be send into DLQ, finally.
But I'm not sure that its a problem because its "our queue" and it
should contains only "our messages".
What do you think about it?
Folks, feedbacks are appreciated :).
--
Regards, Ivan
