mlange wrote
> Normally it is hard to see if two messages that are sent separately from
> each other are really the same. To implement this on the broker level
> might actually be a bit hard (imo)
> 
> However, there are a few ways you can work around this:
> 1) from the producer end: make sure that the producers do not produce the
> same data. For example such a thing can be prevented by placing the
> trigger on which the producers have to produce their messages on a queue;
> only one producer will consume this trigger and will produce the messages.
> 
> 2) on the receiver / consumer end: build in logic to filter out doubles,
> or -even better- make sure the receiving end is idempotent; meaning that
> receiving the same data does not yield any problems.
> 
> Both are viable, and might even for all kinds of reasons be combined.
> 
> Not sure if this answers your question though.


Yes, I understand that it could be done - in theory - manually, on producers
or consumers end. The problem is that sound and well-tested solution is non
trivial to implement (if I want to make sure in no case data is lost,
significantly delayed, or delivered out-of-order - as long as at least one
adapter is running, and switch-over from one adapter to another is
practically transparent to the consumers).
Idempodency of consumers is non practical, there are multiple different
processing flows in different applications, all fed from the bus. I can't
make sure every possible application now and in the future will be
idempodent, so the only way to solve it is to enforce usage of some
"ActiveMQ Client SDK" that does reduplication and switching logic - it is
acceptable - but then I have to write and test this SDK to ensure all
failover, split and rejoins scenarious are handled properly. It may be fun,
but rather out of time and money budget for the project .
Anyway, thanks for your answer.
Alex





--
View this message in context: 
http://activemq.2283324.n4.nabble.com/High-availability-multiple-publishers-scenario-tp4720767p4720789.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Reply via email to