Jaroslaw Cwiklik wrote:
In your particular case ( node dying), getting a message in a transactional
context could have helped. Transactions are not "free" and I certainly would
not want to use them by default. Transactions have impact on performance. We
could enable transactional JMS session using a configuration setting.
Perhaps via -D.
Sure, do you think transactions are really expensive and slow the
system down ?
Otherwise it might be better to have a cluster master which just keeps
track of everything.
I also noticed that client node failure is difficult to handle, because
then you loose
track of the of the pending CASes, which are processed right now.
Our system reads from a work queue which is feed by a different system,
then the work item is wrapped in a CAS and sent to the uima-as cluster,
when the client
gets the work back from the cluster the result is sent to another queue.
If now the client crashes (dies) we do not get back the CASes already
sent to the cluster
but have not returned yet. To improve that situation it would be cool if
UIMA AS could
guarantee that every CAS which was sent to the cluster can also be
retrieved from it,
even in case the client crashes (or a worker node dies). Our use case
would be really simple if UIMA AS just defines
two queues, one to feed it and one to read results form it (I think it
is nearly done like that right now).
The part which reads the result from uima-as must not necessary run in
the same process (or machine) as the
part which feeds it.
Jörn
