[jbaruchs]

1. I can hardly imagine how I can ask my question more clearly. I gave  all the exact details - the configuration, the environment, the  exception.

2. The word "suck" described a stituation, in which I must provide  ip inside my configuration, it has nothing to do with the product  itself. I'll quote what I said about the product, in case you didn't notice: "First, thank you for the great product. Works like charm, except of one  strange point.".

3. I am not more important than anyone else when talking about your product, but somehow I got your attention just by mentioning other alternative in exactly 20 minutes. Coincidence, probably.

4. Please advice what considered not "rushing in as a stranger". Should I post number of off-topic flame posts first?

No dobt my problems are configuration issues. That's the reason I asked for help. Again, I am highly impressed with your product. It looks great.

[bjchip]

When you said it didn't work, did you get no clustering, some exception or some other problem.   I'm not nearly as expert or experienced as other folks here, but I AM curious.     

I suspect there's a grain of truth in what you say about Terracotta, but we've used it simply to front  JBoss instances because JBoss clustering in some of our environments is pretty ragged ....  OTOH,  I haven't seen ANY sort of problem with hornetq itself.     IT solves  problems that JBoss, at least the 4.2.3.GA flavour of JBoss, can't.  

This makes integration with 4.2.3.GA in those particular instances... challenging :-)   ....  it is seriously confusing to have the appserver incapable of clustering but having its JMS messaging connected. 

If we could get Bonita 5 fo work in JBoss 5.1 we'd be out of the 4.2.3.GA in a heartbeat.... and we would not need terracotta.

As for putting in a line that hints to the application WHICH of several interfaces it should bind to,  that doesn't trouble me a lick.

In some ways I am happier with completely explicit definitions and host table  entries and no discovery, because discovery entails traffic and DNS lookups entail traffic and for the price of an entry in hosts you can avoid some messages... and  unless you are building a really massive cluster it isn't going to trouble your sysadmin(s) all THAT much.  

I wish the exchange between you and Tim could be dialed back a bit.    He knows a hell of a lot more than I do about this stuff.    Sorry my limited assistance didn't resolve your problem before this too.   

respectfully

BJ

[jbaruchs]

Didn't work - I still get the same exception.

BJ, I really don't want to get into this holly-war crap.

HornetQ is awesome, no doubt about it. I didn't manage to configure it correctly, my fault. I found another solution that does the job. I gladly accept that Tim thinks his product is better. I appologise if anything I said hirts somebody.

Thanks for trying to help.

[mcleanl]

Hi BS

You see that value  ${hornetq.remoting.netty.host:localhost} in the configutation file... well that means "use the value of hornetq.remoting.netty.host passed in with the startup parameters and if it doesn't exist then use the default which is set to localhost.


So if you don't pass in a value then the acceptor will only use localhost which will not be accessable from any other machine. I think that will explain why you can access one of the machines but not the other (probably accessing the machine you are on right?)

Simplist method is to modify the run.bat and add a parameter -Dhornetq.remoting.netty.host=<YOUR_MACHINE_IP> where you obviously replace <YOUR_MACHINE_IP> with your ip address.

Now that takes care of the acceptor/connector barrier.  You may like to connect to the broadcast addres without hard coding the machine IP addresses in your clients. You can do that by setting the discoveryAddress and discoveryPort in your client code. It will then get the information it needs (discoveryAddress and discoveryPost must match the group-address and group-port you put in your configuration (default 231.7.7.7 and 9876).

The other message you get (Timed out waiting) is because the broadcast-period in the clustered example is set to 5000ms (the default is 1000). The default period the client waits is only 2000ms... so change the broadcast period to 1000 or less and all will be sweet in the world.

Cheers.

Message was edited by: Luke McLean (sorry I had the wrong port number for the discoveryPort, should be 9876 as per the config file, updated. Cheers)

[jbaruchs]

Oh, that's a valuable answer!

Thanks a ton!

[rkgupta75]

Same problem, did you resolve this?

[timfox]

Ravi Gupta wrote:

Same problem, did you resolve this?

Did you read this? :

"The other message you get (Timed out waiting) is because the broadcast-period in the clustered example is set to 5000ms (the default is 1000). The default period the client waits is only 2000ms... so change the broadcast period to 1000 or less and all will be sweet in the world."