Look at the documentation about acceptors. It's whatever you configure there. You just need proper networking configured at your AWS box
Thanks for your very quick response. I have read the section on acceptors, but that does not help me diagnose why the jms-bridge example does not work when one or both of the servers is running in an Amazon AWS instance in the cloud. Could you (or anyone else) please try to answer the 3 questions I posed in my original post.
Here is some additional information:
1. If I run the source and target servers in different instances WITHIN the same AWS region the jms-bridge example works perfectly!
2. However, when the servers are running in different AWS regions, I get the message "WARNING: Failed to start bridge" from the target server. I have opened all TCP ports in the AWS security groups in both directions between the source and target server instances.
3. Looking at the source code, it looks like the JNDIConnectionFactoryFactory is the only ConnectionFactoryFactory in the product. So I suspect JNDI is the only way to configure a JMS bridge.
1. Is JNDI the only way to configure a JMS bridge?
2. Does the setup of a JMS bridge use any protocol other then TCP (UDP?)?
3. Does anyone have any suggestions how I might further narrow down what is causing the bridge startup to fail? Like turning on some debug logging, etc.
That makes it a question for how to configure AWS. For what matters to us.. everything is just sockets.. Think of you're doing telnet from one node to another. You just need to configure the network properly, and I'm not sure how I could help you on that.
I have spent 4 days working on this configuration - unsuccessfully. Although I can't define exactly what the problem is, I do know that setting up a HornetQ JMS bridge between AWS regions is non-trivial. We could use some documentation from the HornetQ team defining how to configure HornetQ for the Cloud. It would also be useful to know which HornetQ functions work in the Cloud and which do not.
Until some sort of documentation exists to help with configuring HornetQ to work in the cloud, I've, unfortunately, had to abandon HornetQ as our messaging middleware. I've got a SNS/SQS solution up and running. It is WAY more sluggish than HornetQ and is not integrated into transactions in JBoss, but it works.
Please, please, please, I beg you, take some time to test those HornetQ examples that run on two servers in the Cloud with the servers in different regions and document the configurations that allow them to work.
HornetQ is a great tool and I would love to be able to continue using it. Given its speed and redundancy it would be my preferred choice over Amazon's SNS/SQS. But configuring it for use in the Cloud without any documentation specific to that task forces me to look elsewhere.
firstly Bill thanks for evaluating HornetQ. You must realise that we are are a small team, 3 at the moment, and at the minute we just dont have the time to firstly get a bridge working on the cloud and secondly document it, youve spent 4 days doing this and you no doubt have more cloud experience than we do.
However that doesnt mean we wont help you where we can, remember this is open source and its the community, including yourself, that contribute to things like this. maybe you could lead this effort and become a contributor.
Ok, a few things to look at. firstly if both your JMS servers are HornetQ i would suggest using a core bridge rather than a jms bridge, this will take JNDI etc out of the equation. The only ports that you should need to open, if your using the default config, are 1099 and 1098 if your using JMS with jndi and 5445 which is the default netty acceptor port. Now regarding naming resoultion i have no idea how this works, the connector used by each source end of the bridge should be whatever AWS A needs to connect to AWS B, if that makes sense.
Do you get any exceptions that would be a good place to start? also maybe post your config.
I am not familiar with running HornetQ in standalone, but the problem sounds similar to an issue we had when we went from running 3 nodes on a single box (in the development area) to a single node on 3 boxes (in the integration/test area). We run with JBoss5 and HornetQ inside. We had JBoss set to listen to 0.0.0.0 to allow connections from a local client using localhost and the JMS Bridge client using the external IP address. The problem ended up being that the incoming JMS Bridge connection was successfully completing the JNDI lookup. However, the server was telling the client that the resource was located on localhost (and not the remote host that was used for the JNDI lookup). The client then turned around to the server on its localhost, failed to locate that resource, and kicked out the "catch-all" errors that you decribed.
The quick fix on our end was to change the listen from 0.0.0.0 to the external connection to remove any ambiguity by the server as to which address to use.
The real fix that we have not yet researched is how to get the JNDI lookup response to use the external listen address versus the localhost listen address when listening to multiple addresses.
As a side note...Core Bridge keeps being recommended over JMS Bridge. I would love to use something that could take full advantage of the proprietary implementation on either side. However I could not locate an option within the Core Bridge to operate from the *receiving* side. Core Bridge seemed to be "push-only" from the source and JMS Bridge offers push and pull from either side.
HornetQ in standalone is simple: just get the standalone distribution, and use run.sh.. that's very simple.
We will implement Pull Core Bridges in a later version. We don't have that available yet.
"I've got a SNS/SQS solution up and running. It is WAY more sluggish than HornetQ and is not integrated into transactions in JBoss, but it works."
How do you communicate with SNS/SQS from/to JBoss? Did you use a SQS/JMS adapter?