activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gabriel kastenbaum <gkastenbaummailingl...@gmail.com>
Subject Re: Several transportConnectors and clustering
Date Tue, 26 Sep 2006 15:10:06 GMT
gabriel kastenbaum a écrit :
> James Strachan a écrit :
>> On 9/25/06, gabriel kastenbaum <gkastenbaummailinglist@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 :-)


Mime
View raw message