Mailing-List: contact activemq-dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: activemq-dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of rajdavies@gmail.com designates
 66.249.92.173 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer;
        b=pcvquMjzIPtw6mIKBAcVM24zzxv1YnW6oemnRl+4zc6zkggIDPb1b1qQ79qZNT8KFMsPtqqNhIcsKq4j1oz0lWhss5BpYANIQPC+ymhL07bQLlgycS5OtEkxZY+9yawMcCZmraoOMbmYa/liFUB2D7FHynnWGu7ywqQAniHZhmU=
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <39D9C0E8-28FA-435A-AA87-950048C1C3EB@planet57.com>
References: <7F9EF457-C561-4358-AEAE-09AE212A636D@planet57.com>
 <af2843cd0610152130w59b7f630ra7de6507d7df51ef@mail.gmail.com>
 <39D9C0E8-28FA-435A-AA87-950048C1C3EB@planet57.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <431223F3-7EC4-4280-A124-AC6A41AFE3F4@gmail.com>
Content-Transfer-Encoding: 7bit
From: Rob Davies <rajdavies@gmail.com>
Subject: Re: Having some trouble making a simple network...
Date: Mon, 16 Oct 2006 07:38:54 +0100
To: activemq-dev@geronimo.apache.org

Hi Jason,

I just created a jira for this: http://issues.apache.org/activemq/ 
browse/AMQ-979

On 16 Oct 2006, at 05:40, Jason Dillon wrote:

> How then do I setup a hub/spoke network where the hub does not know  
> about all of the spokes, and where the spokes may be behind  
> firewalls, only allowing outgoing connections?  I had thought that  
> having the remote broker define a network connection to the central  
> broker would have been enough to connect them or bi-directional  
> message flow.  But it sounds like that is not the case based on  
> what you've said.
>
> How should I configure the brokers assuming that the remote brokers  
> maybe behind a firewall then?
>
> --jason
>
>
> On Oct 15, 2006, at 9:30 PM, Hiram Chirino wrote:
>
>> Hey Jason,
>>
>> Not sure what those errors are about, but first off... if network
>> connections are only defined from the remote brokers to the  
>> central broker,
>> then only messages can sent to the central broker.  The central  
>> broker will
>> not be able to send message back to the remote broker.
>>
>> Regards,
>> Hiram
>>
>> On 10/15/06, Jason Dillon <jason@planet57.com> wrote:
>>>
>>> Hiya... I'm having some trouble making a simple broker network for
>>> GBuild.  The idea was to embed a broker in each node, and then have
>>> the slave nodes connect to the master node, so that all client code
>>> will always be connected, and let activemq handle broker to broker
>>> connectivity.
>>>
>>> But, I can not seems to get it to work.
>>>
>>> NOTE: This is not master/slave in terms of broker fail-over... its
>>> just hub/spoke where the hub is the master and slave a spoke... just
>>> for clarity on the bits below.
>>>
>>> My central manager (which is what slave nodes connect to) has:
>>>
>>> <beans xmlns="http://activemq.org/config/1.0">
>>>      <bean
>>> class="org.springframework.beans.factory.config.PropertyPlaceholderC 
>>> onfi
>>> gurer"/>
>>>      <broker useJmx="true">
>>>          <managementContext>
>>>              <managementContext connectorPort="5003"
>>> jmxDomainName="org.apache.activemq"/>
>>>          </managementContext>
>>>          <persistenceAdapter>
>>>              <journaledJDBC journalLogFiles="5" dataDirectory="$
>>> {gshell.home}/activemq"/>
>>>          </persistenceAdapter>
>>>          <transportConnectors>
>>>              <transportConnector uri="vm://localhost"/>
>>>              <transportConnector uri="tcp://localhost:16161"/>
>>>          </transportConnectors>
>>>      </broker>
>>> </beans>
>>>
>>> And my slave nodes have:
>>>
>>> <beans xmlns="http://activemq.org/config/1.0">
>>>      <bean
>>> class="org.springframework.beans.factory.config.PropertyPlaceholderC 
>>> onfi
>>> gurer"/>
>>>      <broker useJmx="true">
>>>          <managementContext>
>>>              <managementContext connectorPort="5004"
>>> jmxDomainName="org.apache.activemq"/>
>>>          </managementContext>
>>>          <persistenceAdapter>
>>>              <journaledJDBC journalLogFiles="5" dataDirectory="$
>>> {gshell.home}/activemq"/>
>>>          </persistenceAdapter>
>>>          <transportConnectors>
>>>              <transportConnector uri="vm://localhost"/>
>>>          </transportConnectors>
>>>          <networkConnectors>
>>>              <networkConnector uri="static:(tcp://gbuild.org:16161)"
>>> failover="true"/>
>>>          </networkConnectors>
>>>      </broker>
>>> </beans>
>>>
>>> But... for some reason this is not working... and I don't know why.
>>> Connectivity is good, as when I change the slave client's to connect
>>> with "tcp://gbuild.org:16161" instead of "vm://localhost" everything
>>> works fine.
>>>
>>> But when the slaves use "vm://localhost" then they never see any
>>> messages, and the master node complains with "No subscriptions
>>> registered, will not dispatch message at this time" when new  
>>> messages
>>> are queued... though when the slave starts I do see it connecting to
>>> gbuild.org:16161 and I see the master node create a consumer for the
>>> client (and remove it when I stop the slave).
>>>
>>> Not sure if this matters, but I also see these logs on the master  
>>> node:
>>>
>>> <snip>
>>> 19:54:45,283 DEBUG [Service] Async error occurred:
>>> java.lang.NullPointerException
>>> java.lang.NullPointerException
>>>          at
>>> edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap.has 
>>> h
>>> (ConcurrentHashMap.java:154)
>>>          at
>>> edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap.get
>>> (ConcurrentHashMap.java:759)
>>>          at
>>> org.apache.activemq.broker.AbstractConnection.processAddConnection
>>> (AbstractConnection.java:616)
>>>          at
>>> org.apache.activemq.broker.jmx.ManagedTransportConnection.processAdd 
>>> Conn
>>> ection(ManagedTransportConnection.java:87)
>>>          at org.apache.activemq.command.ConnectionInfo.visit
>>> (ConnectionInfo.java:121)
>>>          at org.apache.activemq.broker.AbstractConnection.service
>>> (AbstractConnection.java:238)
>>>          at org.apache.activemq.broker.TransportConnection 
>>> $1.onCommand
>>> (TransportConnection.java:63)
>>>          at  
>>> org.apache.activemq.transport.ResponseCorrelator.onCommand
>>> (ResponseCorrelator.java:95)
>>>          at org.apache.activemq.transport.TransportFilter.onCommand
>>> (TransportFilter.java:65)
>>>          at
>>> org.apache.activemq.transport.WireFormatNegotiator.onCommand
>>> (WireFormatNegotiator.java:133)
>>>          at  
>>> org.apache.activemq.transport.InactivityMonitor.onCommand
>>> (InactivityMonitor.java:122)
>>>          at org.apache.activemq.transport.TransportSupport.doConsume
>>> (TransportSupport.java:84)
>>>          at org.apache.activemq.transport.tcp.TcpTransport.run
>>> (TcpTransport.java:136)
>>>          at java.lang.Thread.run(Thread.java:595)
>>> 19:54:45,284 DEBUG [Transport] Transport failed:  
>>> java.io.IOException:
>>> Unknown data type: 68
>>> java.io.IOException: Unknown data type: 68
>>>          at org.apache.activemq.openwire.OpenWireFormat.doUnmarshal
>>> (OpenWireFormat.java:344)
>>>          at org.apache.activemq.openwire.OpenWireFormat.unmarshal
>>> (OpenWireFormat.java:275)
>>>          at org.apache.activemq.transport.tcp.TcpTransport.run
>>> (TcpTransport.java:135)
>>>          at java.lang.Thread.run(Thread.java:595)
>>> </snip>
>>>
>>> I'm using the latest 4.1-incubator-SNAPSHOT in m2:
>>>
>>> <dependency>
>>>      <groupId>org.apache.activemq</groupId>
>>>      <artifactId>activeio-core</artifactId>
>>>      <version>3.0-SNAPSHOT</version>
>>> </dependency>
>>>
>>> <dependency>
>>>      <groupId>org.apache.activemq</groupId>
>>>      <artifactId>activemq-core</artifactId>
>>>      <version>4.1-incubator-SNAPSHOT</version>
>>> </dependency>
>>>
>>>   * * *
>>>
>>> I really want to get this broker network working so that the client
>>> code can be free from reconnect fluff... and just assume that the
>>> local embedded broker will handle all inter-broker connectivity  
>>> issues.
>>>
>>> Anyone have any idea what's wrong?
>>>
>>> Thanks,
>>>
>>> --jason
>>>
>>
>>
>>
>> -- 
>> Regards,
>> Hiram
>>
>> Blog: http://hiramchirino.com
>