-
15. Re: HornetQ: Consuming messages from a remote JMS Topic
Setting up a bridge between two machines should be a very simple exercise, I have no idea why it is proving so difficult.
Consequently, I'm going to ask one of our team to create an example pre-configured for remote machines, so you can just paste in your machines real ip addresses and away we go.
It's very time consuming and just doesn't scale to debug users configurations on the forums - this is probably some config error that could be spotted in 5 mins by a core team member.
The reason we don't have an example for bridges with remote nodes out of the box is all the examples are supposed to run out of the box. -
17. Re: HornetQ: Consuming messages from a remote JMS Topic
I would be very surprised if the core bridge is slower than the JMS bridge. I guess this is another config issue.
-
18. Re: HornetQ: Consuming messages from a remote JMS Topic
"timfox" wrote:
I would be very surprised if the core bridge is slower than the JMS bridge. I guess this is another config issue.
The core bridge seemed rather slow compared to other messaging solutions we've looked at, so I suspect it was a problem with the core bridge. Not a problem for us since we were only using a core bridge to try and get the JMS Bridge to work, but I thought I'd mention it.
As I say, we do now have this working, but SourceCFF and TargetCFF seem to be the wrong way around compared to what we expected.
Thanks for your help! -
19. Re: HornetQ: Consuming messages from a remote JMS Topic
"robertjlee" wrote:
The core bridge seemed rather slow compared to other messaging solutions we've looked at, so I suspect it was a problem with the core bridge. Not a problem for us since we were only using a core bridge to try and get the JMS Bridge to work, but I thought I'd mention it.
One of the key design principles of the core bridge is it is extremely fast, that's why I'm surprised you said it was slow. In out tests we can easily saturate a gigabit LAN with a bridge's traffic.
Just saying "it's slow" without backing that up with any more data is not really helpful.
If you can provide a test case demonstrating this we would like very much to investigate, so we can see if this is a real issue or not. -
20. Re: HornetQ: Consuming messages from a remote JMS Topic
"robertjlee" wrote:
As I say, we do now have this working, but SourceCFF and TargetCFF seem to be the wrong way around compared to what we expected.
Yes, it shouldn't be that way around. This is why I want an example so you can see it will work the "expected" way around. -
21. Re: HornetQ: Consuming messages from a remote JMS Topic
BTW the documentation on specifying a list of accept addresses has been in TRUNK for some time.
I have also added some large yellow note boxes explaining that 0.0.0.0 is not a valid address (0.0.0.0 is just a convention that JBoss app server uses) -
22. Re: HornetQ: Consuming messages from a remote JMS Topic
"robertjlee" wrote:
To get it to work, we had to set SourceCFF to "LocalJNDI" and TargetCFF to "RemoteJNDI" - I have no idea why this works, since the source is on the remote server and the target is on the local server.
Your configuration seems correct wrt to JNDI and it is likely the JMS Bridge is confusing the source and target settings...
I have not found where the confusion is done yet.
We will add a JMS Bridge example to run on 2 hosts.
In the mean time, could you enable TRACE logs in the JMSBridgeImpl class and sends logs for both the "correct" config (SourceCFF -> RemoteJNDI, TargetCFF -> LocalJNDI) and the "working" config (SourceCFF -> LocalJNDI, TargetCFF -> RemoteJNDI)?
thanks -
23. Re: HornetQ: Consuming messages from a remote JMS Topic
"robertjlee" wrote:
Looking at the documentation, it reads as if a core bridge can only connect to a local queue (as the source).
We have a large (and, in practice, variable) number of consumers connecting to one central server, so to set up core bridges to send messages out, we'd need to maintain a set of bridges on the central server, which could be something of a headache, so we'd rather connect to a remote source topic than a local queue if possible (especially if adding a local queue would mean restarting the central server). I know that core bridges would be faster, but to be honest it's reliability we're after more than performance.
I can see that right now, core bridges don't fit your use case very well, since the bridge must reside on that machine that pushes the messages.
I have added this JIRA to implement "pull" core bridges in HornetQ (which can reside on the target machine) which would satisfy your use case without having to resort to JMS bridges. -
24. Re: HornetQ: Consuming messages from a remote JMS Topic
"timfox" wrote:
Just saying "it's slow" without backing that up with any more data is not really helpful.
If you can provide a test case demonstrating this we would like very much to investigate, so we can see if this is a real issue or not.
We have a "test case" for the core bridge, connecting from a hornetQ server to a JBoss server running on the local machine, and using an MDB to time the number of messages processed. It's based loosely on your test case examples (except that it expects JBoss to already be running with an ejb.jar deploed) - what's the best way to get this to you?"timfox" wrote:
BTW the documentation on specifying a list of accept addresses has been in TRUNK for some time.
That makes sense; we've only been looking at the Beta release.
We will turn on TRACE logging in JMSBridgeImpl and post the logs. -
25. Re: HornetQ: Consuming messages from a remote JMS Topic
We're having some difficulty in finding the logs for JMSBridgeImpl (the jboss-log4j.xml is set to TRACE both for the class and the threshold, but we get no output for the class, unlike MemoryManagerImpl).
However, we think we've found the speed problem: it's not the JMS Bridge at all but the JCA adaptor. We were using an MDBean to time the rate at which messages can be consumed. Pulling messages from a local queue, we get a speed of around 600-900 mesages per minute (2kb payload with various headers). With JBoss MQ and Jboss Messaging 1.x, this has taken a negligable time (tens of thousands of messages per minute) so we didn't bother measuring it explicitly before with HornetQ. -
26. Re: HornetQ: Consuming messages from a remote JMS Topic
Yes, sure if you're using MDBs/JTA/JCA then more than likely the vast majority of time is spent in that code (part of the AS) not in HornetQ code.
There is discussed a little in the user manual performance section (and more in TRUNK IIRC).
The slowest thing you can do is if your MDB is using a JTA transaction, this will really slow things down, since a JTA tx will require several syncs to disk per transaction. -
27. Re: HornetQ: Consuming messages from a remote JMS Topic
"timfox" wrote:
"robertjlee" wrote:
As I say, we do now have this working, but SourceCFF and TargetCFF seem to be the wrong way around compared to what we expected.
Yes, it shouldn't be that way around. This is why I want an example so you can see it will work the "expected" way around.
Finally figured it out! We were defining the IP address in the connectors used by the Connection Factory Factory backwards: on each server, we set hornetq.remoting.netty.host as to the value needed to connect to the other server (it should have been the public IP of the local server), so when we looked it up the connection factory factory in JNDI we had to look up the opposite JNDI server in order to load the correct CFF.
This became apparant when we tried to add a second server in. -
28. Re: HornetQ: Consuming messages from a remote JMS Topic
Glad you worked it out.
BTW why connectors are defined on the client side too, is explained in the user manual:
http://hornetq.sourceforge.net/docs/hornetq-2.0.0.BETA5/user-manual/en/html/configuring-transports.html#understanding.connectors
I really recommend reading it -
29. Re: HornetQ: Consuming messages from a remote JMS Topic
In particular the part that starts with:
You make ask yourself, if connectors are used by the client to make connections then why are they defined on the server? There are a couple of reasons for this:
Is relevant to your misunderstanding which resulting in them being defined on the wrong servers.