[JBoss Messaging] - JBOSS configuration for multiple brokers.
by Milochanzy
Hi,
I am trying to connect my application to listen to a Queue that has multiple brokers. Code below:
| <entity jndiName="QueueConnectionFactory" class="progress.message.jclient.QueueConnectionFactory">
| <property name="brokerURL">tcp://blah.blah1.COM:4211,tcp://blah.blah2.COM:4211,tcp://blah.blah3.COM:4211</property>
| <property name="defaultUser">userID</property>
| <property name="defaultPassword">password</property>
| <property name="prefetchCount">3</property>
| <property name="prefetchThreshold">1</property>
| <property name="sequential">true</property>
| </entity>
|
|
I am getting following error
| java.lang.NumberFormatException: For input string: "tcp://blah.blah2.COM:4211,tcp://blah.blah3.COM:4211"
|
I have tested each of brokers individually and are working fine.
Please Suggest.
Thanks and Regards,
Milan.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159802#4159802
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159802
17 years, 10 months
[JBoss Messaging] - Re: Interesting performance numbers with 2.0 alpha, 1.4 & AM
by seattle.golfer
"timfox" wrote :
|
| 1) I'd strongly recommend against running all tests on the same box. You'll probably find the results won't give you a real picture of performance since you really need a network in play (minimum 1GB network).
|
|
We are designing each node in this role so it is horizontally scalable. What that means is that the JMS Broker runs on each node, and all message producers only publish messages to their local JMS broker. Message consumers can live on other nodes, and use a piece of custom (spring) code to perform the subscription multiplexing to all the topics they are interested in. (*)
So, that is a long winded way of saying, on the producing side, network latency & bandwidth shouldn't matter, and on the receiving side, I'm not overly concerned because the producers are the only ones in the real time code flow.
"timfox" wrote :
|
| 2) For JBM 1.4 - are you using out of the box config? If so JBM 1.4 out of the box in the app server uses HSQLDB which isn't a "real" database - has not tx, and is in memory. It may give high perf figures because it's not actually persisting to disk. If you replace HSQLDB by a real db like Oracle or MySQL you'll probably see a difference in the perf.
|
|
Yup, out of the box JBM 1.4 config. HSQL is fine with us because of the architecture I mentioned above, as long as HSQL is configured to persist to disk for durable storage across restarts (which it is by default it appears).
"timfox" wrote :
| 3) JBM 2.0 - I'd strongly recommend running the server on linux if you're not already and installing libaio (see userguide) - this will make the journal even faster.
|
| 4) AMQ by default does not by default sync tx to disk - make sure you switch this on.
|
| 5) I'd also try with larger transaction sizes. If you're using tx size of 1, there's little point you may as well just send a single persistent message outside a tx. The JBM journal will shine even more with larger or more real world transactions.
|
Good info to have, thanks!
"clebert.suconic(a)jboss.com" wrote :
| Is this Linux? Are you using libaio? What disk you have in your config?
|
| If you are using linux/libaio, when you add more clients you should scale even higher. I mean.
|
This was on a MacBook, but all our servers run linux with a recent 2.6 kernel. So we should be able to utilize all the performance the ASYNCIO provides!
"clebert.suconic(a)jboss.com" wrote :
| Our target for BETA is to maximize your disk... say.. if your disk can do up to 20K messages a second on the disk, you would be able to add 20 more producers and you would still have 800/1K messages per second on each producer.
|
Is there a tentative date for the Beta or the Release?
Thanks for the responses guys, much appreciated.
I'm going to recommend we switch to JBM 1.4 from AMQ for now, and plan on upgrading to 2.0 once it is released. I
(*) We designed things this way because AMQ's network of brokers feature didn't work as advertised, and JBM 1.4's clustering still required a central database. When we are ready to adopt 2.0, we'll look at using a distributed destination/clustering within JBM.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159801#4159801
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159801
17 years, 10 months