You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by gabriel kastenbaum <gk...@gmail.com> on 2006/09/25 12:02:10 UTC
Several transportConnectors and clustering
Hi everybody,
Can we use several <transportConnector> in the same configuration.
And can they share the same destinations - using clustering ?
Here is the reason of my question:
I have client waiting for topics at a multicast adress.
But the producer of message is on the same machine as one of the consumer.
It means that as long as the consumer is using the Multicast Adress to
listen, the producer can not connect.
"javax.jms.JMSException: Could not connect to broker URL:
multicast://225.0.0.1:61617. Address already in use"
So I thought using a clustered destination to have the same Topic with
two adresses.
One - used by the producer - is in TCP
One - used by the consumer- is in Multicast.
Which leads to something like this:
Am I just doing something too complex for
<transportConnectors>
<transportConnector name="internal" uri="tcp://localhost:61617"
discoveryUri="multicast://225.0.0.1:61618"/>
<transportConnector name="multicast"
uri="multicast://225.0.0.1:61617"
discoveryUri="multicast://225.0.0.1:61618"/>
</transportConnectors>
<networkConnectors>
<networkConnector name="connexion"
uri="multicast://225.0.0.1:61618"/>
</networkConnectors>
2nd question:
Can we do something like this:
Two parallel networks.
One linking the internal and the multicast transportConnectors.
And one linking the localhost adress with others activeMQ via multicast
(for discovery) and TCP (for transport between the nodes)
<transportConnectors>
<transportConnector name="internal" uri="tcp://localhost:61617"
discoveryUri="multicast://225.0.0.1:61618"/>
<transportConnector name="multicast"
uri="multicast://225.0.0.1:61617"
discoveryUri="multicast://225.0.0.1:61618"/>
<transportConnector name="clustering" uri="tcp://localhost:61616"
discoveryUri="multicast://225.0.0.1:61616"/>
</transportConnectors>
<networkConnectors>
<networkConnector name="connexion"
uri="multicast://225.0.0.1:61618"/>
<networkConnector name="clustering"
uri="multicast://225.0.0.1:61616"/>
</networkConnectors>
Promise, if this works, I publish the entire config!
Re: Several transportConnectors and clustering
Posted by gabriel kastenbaum <gk...@gmail.com>.
gabriel kastenbaum a écrit :
> James Strachan a écrit :
>> On 9/25/06, gabriel kastenbaum <gk...@gmail.com> wrote:
>>> Hi everybody,
>>>
>>> Can we use several <transportConnector> in the same configuration.
>>> And can they share the same destinations - using clustering ?
>>
>> Yes.
>>
>> Note that an individual transportConnector is just a different
>> port/transport/protocol, you are still talking to the same broker &
>> destinations.
>>
>> I'd recommend using multicast for discovery and then using tcp for the
>> actual transports - its very reliable and fast.
>>
>
>
> Hi,
>
> Thanks for yesterday's help.
> But still my mdb can not receive anything from the activemq broker via
> multicast.
>
> Here is what happens on the broker :
> 2006-09-26 09:44:04,613 INFO UdpTransportServer -
> Starting UdpTransportServer@UdpServer@61619
> 2006-09-26 09:44:04,618 DEBUG UdpTransport - Binding
> to address: 0.0.0.0/0.0.0.0:61619
> 2006-09-26 09:44:04,756 DEBUG UdpTransport -
> Consumer thread starting for: UdpServer@61619
>
>
> its config is:
>
> (...)
>
> <transportConnectors>
> <transportConnector name="dossierspistes"
> uri="tcp://localhost:61616" discoveryUri="multicast://225.0.0.1:61616"/>
>
> <transportConnector name="internal" uri="tcp://localhost:61617" />
> <transportConnector name="tcp" uri="tcp://localhost:61618" />
> <transportConnector name="multicast"
> uri="multicast://225.0.0.1:61619?trace=true" />
> </transportConnectors>
>
> (...)
>
>
>
>
> There a JBoss server trying to connect the broker.
> The JBoss uses a activemq-ra.rar to connect to the server. The only
> thing I configured is the ServerUrl:
>
> Here are the log of the .rar
>
> 2006-09-26 12:28:45,546 DEBUG
> [org.apache.activemq.transport.udp.UdpTransport] Sending oneway from:
> multicast://225.0.0.1:61619@0 to target: /225.0.0.1:61619 command:
> ConnectionInfo {commandId = 1, responseRequired = true, connectionId =
> ID:ZOZMA-1989-1159266516578-1:2, clientId =
> ID:ZOZMA-1989-1159266516578-2:2, userName = defaultUser, password =
> defaultPassword, brokerPath = null, brokerMasterConnector = false,
> manageable = true}
> 2006-09-26 12:28:45,625 DEBUG
> [org.apache.activemq.transport.udp.CommandDatagramSocket] Channel:
> multicast://225.0.0.1:61619@0 sending datagram: 1 to: /225.0.0.1:61619
> 2006-09-26 12:28:45,640 DEBUG
> [org.apache.activemq.transport.udp.CommandDatagramSocket] Channel:
> multicast://225.0.0.1:61619@0 about to process: ConnectionInfo
> {commandId = 1, responseRequired = true, connectionId =
> ID:ZOZMA-1989-1159266516578-1:2, clientId =
> ID:ZOZMA-1989-1159266516578-2:2, userName = defaultUser, password =
> defaultPassword, brokerPath = null, brokerMasterConnector = false,
> manageable = true}
> 2006-09-26 12:28:47,656 DEBUG
> [org.apache.activemq.transport.reliable.ReliableTransport] Still
> waiting for response on: multicast://225.0.0.1:61619@0 to command:
> ConnectionInfo {commandId = 1, responseRequired = true, connectionId =
> ID:ZOZMA-1989-1159266516578-1:2, clientId =
> ID:ZOZMA-1989-1159266516578-2:2, userName = defaultUser, password =
> defaultPassword, brokerPath = null, brokerMasterConnector = false,
> manageable = true} sending replay message
> 2006-09-26 12:28:47,656 DEBUG
> [org.apache.activemq.transport.udp.UdpTransport] Sending oneway from:
> multicast://225.0.0.1:61619@0 to target: /192.9.211.39:61619 command:
> ReplayCommand {commandId = 2, firstNakNumber = 1, lastNakNumber = 1}
> 2006-09-26 12:28:47,656 DEBUG
> [org.apache.activemq.transport.udp.CommandDatagramSocket] Channel:
> multicast://225.0.0.1:61619@0 sending datagram: 2 to: /192.9.211.39:61619
> 2006-09-26 12:28:47,656 DEBUG
> [org.apache.activemq.transport.udp.CommandDatagramSocket] Channel:
> multicast://225.0.0.1:61619@0 about to process: ReplayCommand
> {commandId = 2, firstNakNumber = 1, lastNakNumber = 1}
> 2006-09-26 12:28:47,656 DEBUG
> [org.apache.activemq.transport.udp.CommandDatagramSocket] Channel:
> multicast://225.0.0.1:61619@0 REDELIVERING datagram: 1 to:
> /225.0.0.1:61619
> 2006-09-26 12:28:47,656 DEBUG
> [org.apache.activemq.transport.udp.CommandDatagramSocket] Channel:
> multicast://225.0.0.1:61619@0 about to process: ConnectionInfo
> {commandId = 1, responseRequired = true, connectionId =
> ID:ZOZMA-1989-1159266516578-1:2, clientId =
> ID:ZOZMA-1989-1159266516578-2:2, userName = defaultUser, password =
> defaultPassword, brokerPath = null, brokerMasterConnector = false,
> manageable = true}
>
>
> etc...
>
>
>
> And the config of the .rar
> (...)
> <config-property>
> <description>(..)</description>
> <config-property-name>ServerUrl</config-property-name>
> <config-property-type>java.lang.String</config-property-type>
>
> <config-property-value>multicast://225.0.0.1:61619?trace=true</config-property-value>
>
> </config-property>
> (...)
>
>
> If I change the url in the .rar (and uses another transportConnector:
> tcp://myServerIP:61618) it works .
> But nothing happens with multicast://myMulticastAdress:61619
>
> I think multicast works on my network because the discoveryUri and the
> network of brokers works.
>
>
> Do you have any ideas?
> Maybe the point is on the client with its
> 2006-09-26 12:28:47,656 DEBUG
> [org.apache.activemq.transport.udp.CommandDatagramSocket] Channel:
> multicast://225.0.0.1:61619@0 REDELIVERING datagram: 1 to:
> /225.0.0.1:61619
> But what does it mean?
> Is it possible (for instance) that one can only use Queue with multicast?
>
> Thanks by advance!
>
> Gabriel.
>
>
> PS: I agree with you that TCP is faster and more reliable. But this
> choice can be explained by our network:
> There is one publisher and more than 50 consumers.
> But the bandwith is very limited and what should happen is that we
> will have 50 times the same 1Mo topic on one point of the network...
>
> We will use the two transports: multicast for "1Mo/minut" topic (and
> it is not too important if one server miss one message), tcp for
> reliable transport.
>
>
Does anyone has an idea?
It reacts as if the TransportConnector is ont started on the multicast
adress: nothing sent and nothing received..
Sorry to ask once again today but I am on this problem since too long I
can not think any further :-)
Re: Several transportConnectors and clustering
Posted by gabriel kastenbaum <gk...@gmail.com>.
James Strachan a écrit :
> On 9/25/06, gabriel kastenbaum <gk...@gmail.com> wrote:
>> Hi everybody,
>>
>> Can we use several <transportConnector> in the same configuration.
>> And can they share the same destinations - using clustering ?
>
> Yes.
>
> Note that an individual transportConnector is just a different
> port/transport/protocol, you are still talking to the same broker &
> destinations.
>
> I'd recommend using multicast for discovery and then using tcp for the
> actual transports - its very reliable and fast.
>
Hi,
Thanks for yesterday's help.
But still my mdb can not receive anything from the activemq broker via
multicast.
Here is what happens on the broker :
2006-09-26 09:44:04,613 INFO UdpTransportServer - Starting
UdpTransportServer@UdpServer@61619
2006-09-26 09:44:04,618 DEBUG UdpTransport - Binding
to address: 0.0.0.0/0.0.0.0:61619
2006-09-26 09:44:04,756 DEBUG UdpTransport - Consumer
thread starting for: UdpServer@61619
its config is:
(...)
<transportConnectors>
<transportConnector name="dossierspistes"
uri="tcp://localhost:61616" discoveryUri="multicast://225.0.0.1:61616"/>
<transportConnector name="internal" uri="tcp://localhost:61617" />
<transportConnector name="tcp" uri="tcp://localhost:61618" />
<transportConnector name="multicast"
uri="multicast://225.0.0.1:61619?trace=true" />
</transportConnectors>
(...)
There a JBoss server trying to connect the broker.
The JBoss uses a activemq-ra.rar to connect to the server. The only
thing I configured is the ServerUrl:
Here are the log of the .rar
2006-09-26 12:28:45,546 DEBUG
[org.apache.activemq.transport.udp.UdpTransport] Sending oneway from:
multicast://225.0.0.1:61619@0 to target: /225.0.0.1:61619 command:
ConnectionInfo {commandId = 1, responseRequired = true, connectionId =
ID:ZOZMA-1989-1159266516578-1:2, clientId =
ID:ZOZMA-1989-1159266516578-2:2, userName = defaultUser, password =
defaultPassword, brokerPath = null, brokerMasterConnector = false,
manageable = true}
2006-09-26 12:28:45,625 DEBUG
[org.apache.activemq.transport.udp.CommandDatagramSocket] Channel:
multicast://225.0.0.1:61619@0 sending datagram: 1 to: /225.0.0.1:61619
2006-09-26 12:28:45,640 DEBUG
[org.apache.activemq.transport.udp.CommandDatagramSocket] Channel:
multicast://225.0.0.1:61619@0 about to process: ConnectionInfo
{commandId = 1, responseRequired = true, connectionId =
ID:ZOZMA-1989-1159266516578-1:2, clientId =
ID:ZOZMA-1989-1159266516578-2:2, userName = defaultUser, password =
defaultPassword, brokerPath = null, brokerMasterConnector = false,
manageable = true}
2006-09-26 12:28:47,656 DEBUG
[org.apache.activemq.transport.reliable.ReliableTransport] Still waiting
for response on: multicast://225.0.0.1:61619@0 to command:
ConnectionInfo {commandId = 1, responseRequired = true, connectionId =
ID:ZOZMA-1989-1159266516578-1:2, clientId =
ID:ZOZMA-1989-1159266516578-2:2, userName = defaultUser, password =
defaultPassword, brokerPath = null, brokerMasterConnector = false,
manageable = true} sending replay message
2006-09-26 12:28:47,656 DEBUG
[org.apache.activemq.transport.udp.UdpTransport] Sending oneway from:
multicast://225.0.0.1:61619@0 to target: /192.9.211.39:61619 command:
ReplayCommand {commandId = 2, firstNakNumber = 1, lastNakNumber = 1}
2006-09-26 12:28:47,656 DEBUG
[org.apache.activemq.transport.udp.CommandDatagramSocket] Channel:
multicast://225.0.0.1:61619@0 sending datagram: 2 to: /192.9.211.39:61619
2006-09-26 12:28:47,656 DEBUG
[org.apache.activemq.transport.udp.CommandDatagramSocket] Channel:
multicast://225.0.0.1:61619@0 about to process: ReplayCommand {commandId
= 2, firstNakNumber = 1, lastNakNumber = 1}
2006-09-26 12:28:47,656 DEBUG
[org.apache.activemq.transport.udp.CommandDatagramSocket] Channel:
multicast://225.0.0.1:61619@0 REDELIVERING datagram: 1 to: /225.0.0.1:61619
2006-09-26 12:28:47,656 DEBUG
[org.apache.activemq.transport.udp.CommandDatagramSocket] Channel:
multicast://225.0.0.1:61619@0 about to process: ConnectionInfo
{commandId = 1, responseRequired = true, connectionId =
ID:ZOZMA-1989-1159266516578-1:2, clientId =
ID:ZOZMA-1989-1159266516578-2:2, userName = defaultUser, password =
defaultPassword, brokerPath = null, brokerMasterConnector = false,
manageable = true}
2006-09-26 12:28:49,671 DEBUG
[org.apache.activemq.transport.reliable.ReliableTransport] Still waiting
for response on: multicast://225.0.0.1:61619@0 to command:
ConnectionInfo {commandId = 1, responseRequired = true, connectionId =
ID:ZOZMA-1989-1159266516578-1:2, clientId =
ID:ZOZMA-1989-1159266516578-2:2, userName = defaultUser, password =
defaultPassword, brokerPath = null, brokerMasterConnector = false,
manageable = true} sending replay message
2006-09-26 12:28:49,671 DEBUG
[org.apache.activemq.transport.udp.UdpTransport] Sending oneway from:
multicast://225.0.0.1:61619@0 to target: /192.9.211.39:61619 command:
ReplayCommand {commandId = 3, firstNakNumber = 1, lastNakNumber = 1}
etc...
And the config of the .rar
(...)
<config-property>
<description>(..)</description>
<config-property-name>ServerUrl</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>multicast://225.0.0.1:61619?trace=true</config-property-value>
</config-property>
(...)
If I change the url in the .rar (and uses another transportConnector:
tcp://myServerIP:61618) it works .
But nothing happens with multicast://myMulticastAdress:61619
I think multicast works on my network because the discoveryUri and the
network of brokers works.
Do you have any ideas?
Maybe the point is on the client with its
2006-09-26 12:28:47,656 DEBUG
[org.apache.activemq.transport.udp.CommandDatagramSocket] Channel:
multicast://225.0.0.1:61619@0 REDELIVERING datagram: 1 to: /225.0.0.1:61619
But what does it mean?
Is it possible (for instance) that one can only use Queue with multicast?
Thanks by advance!
Gabriel.
PS: I agree with you that TCP is faster and more reliable. But this
choice can be explained by our network:
There is one publisher and more than 50 consumers.
But the bandwith is very limited and what should happen is that we will
have 50 times the same 1Mo topic on one point of the network...
We will use the two transports: multicast for "1Mo/minut" topic (and it
is not too important if one server miss one message), tcp for reliable
transport.
Re: Several transportConnectors and clustering
Posted by James Strachan <ja...@gmail.com>.
On 9/25/06, gabriel kastenbaum <gk...@gmail.com> wrote:
> Hi everybody,
>
> Can we use several <transportConnector> in the same configuration.
> And can they share the same destinations - using clustering ?
Yes.
Note that an individual transportConnector is just a different
port/transport/protocol, you are still talking to the same broker &
destinations.
> Here is the reason of my question:
> I have client waiting for topics at a multicast adress.
> But the producer of message is on the same machine as one of the consumer.
> It means that as long as the consumer is using the Multicast Adress to
> listen, the producer can not connect.
> "javax.jms.JMSException: Could not connect to broker URL:
> multicast://225.0.0.1:61617. Address already in use"
>
> So I thought using a clustered destination to have the same Topic with
> two adresses.
> One - used by the producer - is in TCP
> One - used by the consumer- is in Multicast.
> Which leads to something like this:
> Am I just doing something too complex for
>
> <transportConnectors>
> <transportConnector name="internal" uri="tcp://localhost:61617"
> discoveryUri="multicast://225.0.0.1:61618"/>
> <transportConnector name="multicast"
> uri="multicast://225.0.0.1:61617"
> discoveryUri="multicast://225.0.0.1:61618"/>
> </transportConnectors>
>
> <networkConnectors>
> <networkConnector name="connexion"
> uri="multicast://225.0.0.1:61618"/>
> </networkConnectors>
I'd recommend using multicast for discovery and then using tcp for the
actual transports - its very reliable and fast.
--
James
-------
http://radio.weblogs.com/0112098/