Hi Karl,

I did some more testing with hedera jms standalone : 3 nodes (on the same
sever), 3 senders, 1000 messages of 5120 bytes each, 1 jms server instance.
All is running fine (total ordering ok) and fast (using non persistent
message).

I also did some little basic testing under Sequoia and it seems to work as
expected. I will try to do some more serious testing with Sequoia and maybe
with some other JMS implementations (I think about OpenJMS and ActiveMQ).
I was wondering from a high availability perspective when the controllers are distributed, who is going to own the queue? Can it be replicated or will the JMS server hosting the queue be a single point of failure?

I found a more elegant way of dealing with non-unique (groupid, node)
running on the same server (see my previous post) : the local member is
identified with the localhost ip, the group identifier and a unique id set
in the configuration properties file as the port.
Yes, this is probably the easiest way. Each controller has a unique id that it could use but we would have to modify the Hedera API to allow the setting of this unique id. It is prably better to let this off the API.

Thus, if you need to run more than one controller for a given virtual
database on the same server, then all you have to do is to use a different
hedera-jms configuration properties file for each (controller, vdb) with a
different uniqueid value. Furthermore, each vdb should use a different topic
to avoid useless message broadcast (which would result in message dropping
otherwise => wasted resource usage).
Looks extremely promising. Don't hesitate to keep us posted.
We can create a CVS module in Hedera to host the code if you wish.

Thanks again for your contributions,
Emmanuel

--
Emmanuel Cecchet
Chief Architect, Continuent

Open source: http://www.continuent.org
Corporate: http://www.continuent.com
Skype: emmanuel_cecchet
Cell: +33 687 342 685


_______________________________________________
Hedera mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/hedera

Reply via email to