|
Hi,
I agree with Sebastian that a listener should only read
those message it really wants to process and not all
messages, so we need to use message selectors. It may be
"our" queue with only "our" message, but still
we could have specialized workflow
processors that provide only a selection of all workflows, so they should
not read messages that they cannot process because they do
not contain the needed workflow.
Why do you say that the syntax for message selectors is not
defined in JMS? There is a syntax specification
in [1]. Or am I confusing something and you mean
something different?
Also, Derby is surely not an appropriate database when it
comes to really high volume scenarios, so we should
do tests with "real" database servers, too. BTW, why do we
use Derby at all? The default message store in
ActiveMQ should be a file based storage [2], which
should provide better performance (at least they claim
it).
Cheers,
Juergen.
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
|
