Oh, i also meant to ask about retroactive consumers which i stumbled
across on the website -
http://activemq.apache.org/retroactive-consumer.html. That sounded
useful but with a very quick try it looks like the remote broker needs
to be connected before the topic publish happens, does that sound
right?

   ...ant

On Fri, Dec 11, 2009 at 3:20 PM, ant elder <antel...@apache.org> wrote:
> Ok, i'll have to think about that option. Going back to what you said
> earlier about statically configured destinations on the network
> connector, is it right that the static destination only needs to be
> configured at the remote end of the network connector? Eg without
> changing the put code i tried replacing the addNetworkConnector in
> that browse code from the first email with this:
>
>        NetworkConnector nc =
> broker2.addNetworkConnector("multicast://default");
>        ActiveMQDestination destiantion = new ActiveMQQueue("d1");
>        nc.addStaticallyIncludedDestination(destiantion);
>
> and that does then get the first browse working.
>
> Looking at the doc on addStaticallyIncludedDestination at
> http://activemq.apache.org/networks-of-brokers.html near the bottom of
> the page its says "N.B. You can use wildcards in inclusive , exclusive
> destination properties" but trying a destination of "d*" doesn't seem
> to work, are wild cards not applicable in the statically included
> destinations?
>
> Even without wild cards this may be enough as i might be able to
> organize the clients to workout the set of destination they're
> interested in before starting the client broker.
>
>   ...ant
>
> On Fri, Dec 11, 2009 at 2:53 PM, Gary Tully <gary.tu...@gmail.com> wrote:
>> interesting... this could work but would have some limitations. If you use a
>> regular consumer, client ack with prefetch=0 and don't ack, by using a
>> blocking receive(timeout) - the demand will have time to propagate and the
>> messages will be visible.
>> However, because the network is store and forward, the message will only be
>> visible from one broker at a time and following a forward, only from another
>> broker. Currently the network does not allow forwarding back to an
>> originator as this can lead to out of control message bouncing.
>>
>> You will also have to, at some stage, delete the message which may require
>> locating the broker that currently holds the message.
>>
>> 2009/12/11 ant elder <antel...@apache.org>
>>
>>> Heh, well its probably not a very valid use case of ActiveMQ - I was
>>> toying with using an ActiveMQ broker network for a sort of simple
>>> distributed storage, with clients able to put a message on a queue and
>>> have other clients read the message nondestructively. None of the
>>> other technologies for that type of thing that I've looked at seemed
>>> do quite what i wanted in a simple way with a good license. The
>>> ActiveMQ network facilities look pretty powerful and easy to use to
>>> setup a distributed network so it would be perfect if there was a way
>>> to get the messages replicated to any client.
>>>
>>>   ...ant
>>>
>>> On Fri, Dec 11, 2009 at 1:22 PM, Gary Tully <gary.tu...@gmail.com> wrote:
>>> > fraid not. What is your use case?
>>> >
>>> > 2009/12/11 ant elder <antel...@apache.org>
>>> >
>>> >> I see, thanks for the explanation.
>>> >>
>>> >> The statically configured destination isn't really an option as the
>>> >> queue names aren't known till runtime. Are there any other options
>>> >> that might help get the messages forwarded irrespective of demand?
>>> >>
>>> >>   ...ant
>>> >>
>>> >> On Fri, Dec 11, 2009 at 12:40 PM, Gary Tully <gary.tu...@gmail.com>
>>> wrote:
>>> >> > This is expected. A queue browser takes a shapshot of the queue
>>> through a
>>> >> > short lived consumer. The network bridge is by default a demand
>>> >> forwarder,
>>> >> > such that messages are only forwarded when there are consumers on
>>> other
>>> >> > brokers.
>>> >> >
>>> >> > With the browser, the consumer (and hence demand) is transient, so it
>>> may
>>> >> > take a snapshot before the forwarding has a chance to kick in. And the
>>> >> > forwarding stops when the consumer goes away once the browse shapshot
>>> >> > completes.
>>> >> >
>>> >> > One way to make this more deterministic would be to have a statically
>>> >> > configured destination in the network connector configuration such
>>> that
>>> >> > messages for that destination are forwarded irrespective of demand.
>>> >> >
>>> >> > 2009/12/11 ant elder <ant.el...@gmail.com>
>>> >> >
>>> >> >> I'm trying to track down an problem where a queue browser on a VM
>>> >> >> connection to one AMQ broker is sometimes not seeing messages put on
>>> a
>>> >> >> queue from a VM connection to another broker in the same network. The
>>> >> >> code below can recreate the problem, running the put() on JVM and the
>>> >> >> browse() on another JVM the first QueueBrowser never sees the message
>>> >> >> but the second QueueBrowser does though sometimes it doesn't without
>>> >> >> the Thread.sleep for a few seconds.
>>> >> >>
>>> >> >> Is there anything obviously wrong with this setup or are there any
>>> >> >> config settings that could help?
>>> >> >>
>>> >> >>   ...ant
>>> >> >>
>>> >> >> The code to put a message on a queue:
>>> >> >>
>>> >> >>    public void put() throws Exception {
>>> >> >>        BrokerService broker1 = new BrokerService();
>>> >> >>        broker1.setBrokerName("default");
>>> >> >>        broker1.setPersistent(false);
>>> >> >>        broker1.setUseJmx(false);
>>> >> >>        TransportConnector tc =
>>> >> broker1.addConnector("tcp://localhost:0");
>>> >> >>        tc.setDiscoveryUri(URI.create("multicast://default"));
>>> >> >>        broker1.addNetworkConnector("multicast://default");
>>> >> >>        broker1.start();
>>> >> >>
>>> >> >>        Connection conn1 = new
>>> >> >>
>>> >>
>>> ActiveMQConnectionFactory("vm://default?create=false").createConnection();
>>> >> >>        conn1.start();
>>> >> >>        Session sess1 = conn1.createSession(false, 1);
>>> >> >>        Queue d1 = sess1.createQueue("d1");
>>> >> >>        MessageProducer p1 = sess1.createProducer(d1);
>>> >> >>        TextMessage m1 = sess1.createTextMessage("test");
>>> >> >>        p1.send(m1);
>>> >> >>   }
>>> >> >>
>>> >> >>
>>> >> >> The code to browse the messages on the queue:
>>> >> >>
>>> >> >>    public void browse() throws Exception {
>>> >> >>
>>> >> >>        BrokerService broker2 = new BrokerService();
>>> >> >>        broker2.setBrokerName("default");
>>> >> >>        broker2.setPersistent(false);
>>> >> >>        broker2.setUseJmx(false);
>>> >> >>        TransportConnector tc =
>>> >> broker2.addConnector("tcp://localhost:0");
>>> >> >>        tc.setDiscoveryUri(URI.create("multicast://default"));
>>> >> >>        broker2.addNetworkConnector("multicast://default");
>>> >> >>        broker2.start();
>>> >> >>
>>> >> >>        Connection conn2 = new
>>> >> >>
>>> >>
>>> ActiveMQConnectionFactory("vm://default?create=false").createConnection();
>>> >> >>        conn2.start();
>>> >> >>        Session sess2 = conn2.createSession(false, 1);
>>> >> >>        Queue d1 = sess2.createQueue("d1");
>>> >> >>        QueueBrowser b = sess2.createBrowser(d1);
>>> >> >>
>>> >> >>        Enumeration x2 = b.getEnumeration();
>>> >> >>        while (x2.hasMoreElements()) {
>>> >> >>            System.out.println(x2.nextElement()); // this never gets
>>> >> >> the message
>>> >> >>        }
>>> >> >>
>>> >> >>        Thread.sleep(5000);
>>> >> >>
>>> >> >>        b = sess2.createBrowser(d1);
>>> >> >>        Enumeration x2a = b.getEnumeration();
>>> >> >>        while (x2a.hasMoreElements()) {
>>> >> >>            System.out.println(x2a.nextElement()); // this does get
>>> the
>>> >> >> message
>>> >> >>        }
>>> >> >>
>>> >> >>    }
>>> >> >>
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > http://blog.garytully.com
>>> >> >
>>> >> > Open Source Integration
>>> >> > http://fusesource.com
>>> >> >
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > http://blog.garytully.com
>>> >
>>> > Open Source Integration
>>> > http://fusesource.com
>>> >
>>>
>>
>>
>>
>> --
>> http://blog.garytully.com
>>
>> Open Source Integration
>> http://fusesource.com
>>
>

Reply via email to