Re: Activemq not listening to 61613

[Rob Davies]

The address [::0] is a new one on me  in  uri="stomp+nio://[::0]:61613 
”  - did you mean [::]  (without the trailing zero?)

I would try stomp+nio://0.0.0.0:61613   - which is 
IPv4 - but usually the platform (Windows/Linux)  can handle dual ipv4 and ipv6 
with no problems.



> On 14 Oct 2016, at 08:21, maneeshmp  wrote:
> 
> with the below simple configuration, I am not able to make activemq listen to
> 61613
> Service is running fine,
> sudo service activemq status
> * Checking status of ActiveMQ instance activemqOK
> but
> netstat -an | grep 61613
> doesnt now return anything. What am i doing wrong? Can anyone help me?
> 
> 
> 
>   xmlns="http://www.springframework.org/schema/beans;
>  xmlns:amq="http://activemq.apache.org/schema/core;
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>  xsi:schemaLocation="http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
>  http://activemq.apache.org/schema/core
> http://activemq.apache.org/schema/core/activemq-core.xsd;>
> 
> 
> class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"/>
> 
>http://activemq.apache.org/schema/core;
>useJmx="false"
>brokerName="mytest.com"
>dataDirectory="${activemq.base}/data"
>schedulePeriodForDestinationPurge="6000"
>> 
> 
> 
>
>
>
> 
>   
>
>
>   gcInactiveDestinations="false" memoryLimit="1mb">
>   producerFlowControl="true" gcInactiveDestinations="true"
> inactiveTimoutBeforeGC="30">
>
>
>   
> 
>   
>  
>  
>   groups="servers,client,everyone"/>
>   groups="servers,everyone"/>
>  
>  
> 
>  
>
>  
>
>   admin="clients" read="cliets" write="clients">
>   admin="clients" read="cliets" write="clients">
>   admin="servers" read="servers">
>   admin="servers" write="servers">
>   admin="servers" read="servers">
>   topic="mcollective.registration.agent" admin="servers" read="servers"
> write="servers">
>   admin="everyone" read="everyone" write="everyone">
>
>  
>
> 
>   
>   
>   uri="stomp+nio://[::0]:61613"/>
>   
> 
>
> 
>> 
> 
> 89,1  Bot
> 
> 
> 
> 
> --
> View this message in context: 
> http://activemq.2283324.n4.nabble.com/Activemq-not-listening-to-61613-tp4717902.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Virtual topics, custom prefix limitations

[Devlin]

Tim,

The documentation on this topic (haha!) was never 100% clear to me. Here's
what we want to achieve given our architecture:

Topology

12 broker network (full-mesh)
All destinations dynamic (no static definitions)
Clients connect and reconnect with random brokers (preference to local)
AMQ 6.2.1 (preping for 6.3)

What we need
---
+ Virtual topics working in above architecture.
* Virtual topics to support queue *and* normal topic subscribers (can live
without this if duplication cannot be avoided)

It's my understanding AMQ 6.3 still uses ActiveMQ 5.11, bummer if that's
true, so as you said, we can't use useVirtualDestSubs broker params.

Question

If we statically-defined all virtual topics (we don't have many), can we
meet the requirements above?



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Virtual-topics-custom-prefix-limitations-tp4717481p4717957.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: HornetQ client connect to Artemis server

[hcrobison]

Thanks for your response. 
I looked into the extra-tests you talked about. I created a simple
application acting as the hornetq client, using the code in the test. Here
is my java code.

package hornetqTest;

import java.util.HashMap;
import java.util.Map;
import java.util.UUID;
import org.hornetq.api.core.client.HornetQClient;

public class HornetqClientTest {

private static org.hornetq.api.core.client.ClientSession
createHQClientSession() throws Exception {
System.out.print("in createHQClientSession\n");
Map map = new HashMap<>();
map.put("host", "localhost");
map.put("port", 5445);

System.out.print("before create server locator\n");
org.hornetq.api.core.client.ServerLocator serverLocator =
HornetQClient.createServerLocatorWithoutHA(new
org.hornetq.api.core.TransportConfiguration(org.hornetq.core.remoting.impl.netty.NettyConnectorFactory.class.getName(),
map));
System.out.print("after create server locator\n");
System.out.print("before create session factory\n");
org.hornetq.api.core.client.ClientSessionFactory sf =
serverLocator.createSessionFactory();
System.out.print("after create session factory\n");
System.out.print("before create session\n");

return sf.createSession();
}

public static void main(String[] args) {
try {

System.out.print("in main\n");
org.hornetq.api.core.client.ClientSession session =
createHQClientSession();
System.out.print("after create session\n");

String queueName = "test.hq.queue";
session.createQueue(queueName, queueName, true);

org.hornetq.api.core.client.ClientProducer producer =
session.createProducer(queueName);
org.hornetq.api.core.client.ClientConsumer consumer =
session.createConsumer(queueName);
org.hornetq.api.core.client.ClientMessage message =
session.createMessage(false);

String messageId = UUID.randomUUID().toString();
   
message.putStringProperty(org.hornetq.api.core.Message.HDR_DUPLICATE_DETECTION_ID.toString(),
messageId);

session.start();
producer.send(message);
org.hornetq.api.core.client.ClientMessage m =
consumer.receive(1000);

producer.send(message);
m = consumer.receive(1000);

producer.send(message);
m = consumer.receive(1000);

session.close();
}
catch (Exception e) {
System.out.println(e.toString());
}
}

}


When I run this on the Artemis server, I got the following:


in main
in createHQClientSession
before create server locator
after create server locator
before create session factory
13:44:08.412 [main] DEBUG i.n.u.i.l.InternalLoggerFactory - Using SLF4J as
the default logging framework
13:44:08.424 [main] DEBUG i.n.util.internal.PlatformDependent0 -
java.nio.Buffer.address: available
13:44:08.425 [main] DEBUG i.n.util.internal.PlatformDependent0 -
sun.misc.Unsafe.theUnsafe: available
13:44:08.429 [main] DEBUG i.n.util.internal.PlatformDependent0 -
sun.misc.Unsafe.copyMemory: available
13:44:08.429 [main] DEBUG i.n.util.internal.PlatformDependent0 -
java.nio.Bits.unaligned: true
13:44:08.582 [main] DEBUG i.n.util.internal.PlatformDependent - UID: 0
13:44:08.582 [main] DEBUG i.n.util.internal.PlatformDependent - Java
version: 8
13:44:08.582 [main] DEBUG i.n.util.internal.PlatformDependent -
-Dio.netty.noUnsafe: false
13:44:08.583 [main] DEBUG i.n.util.internal.PlatformDependent -
sun.misc.Unsafe: available
13:44:08.583 [main] DEBUG i.n.util.internal.PlatformDependent -
-Dio.netty.noJavassist: false
13:44:08.755 [main] DEBUG i.n.util.internal.PlatformDependent - Javassist:
available
13:44:08.755 [main] DEBUG i.n.util.internal.PlatformDependent -
-Dio.netty.tmpdir: /tmp (java.io.tmpdir)
13:44:08.756 [main] DEBUG i.n.util.internal.PlatformDependent -
-Dio.netty.bitMode: 64 (sun.arch.data.model)
13:44:08.756 [main] DEBUG i.n.util.internal.PlatformDependent -
-Dio.netty.noPreferDirect: false
13:44:08.802 [main] DEBUG io.netty.util.ResourceLeakDetector -
-Dio.netty.leakDetectionLevel: simple
13:44:08.821 [main] DEBUG i.n.c.MultithreadEventLoopGroup -
-Dio.netty.eventLoopThreads: 2
13:44:08.878 [main] DEBUG io.netty.channel.nio.NioEventLoop -
-Dio.netty.noKeySetOptimization: false
13:44:08.878 [main] DEBUG io.netty.channel.nio.NioEventLoop -
-Dio.netty.selectorAutoRebuildThreshold: 512
13:44:08.918 [main] DEBUG i.n.buffer.PooledByteBufAllocator -
-Dio.netty.allocator.numHeapArenas: 1
13:44:08.918 [main] DEBUG i.n.buffer.PooledByteBufAllocator -
-Dio.netty.allocator.numDirectArenas: 1
13:44:08.919 [main] DEBUG i.n.buffer.PooledByteBufAllocator -
-Dio.netty.allocator.pageSize: 8192
13:44:08.919 [main] DEBUG i.n.buffer.PooledByteBufAllocator -
-Dio.netty.allocator.maxOrder: 

Re: sudo update-rc.d activemq multiuser throws error

[maneeshmp]

I am using ubuntu

$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.1 LTS"

Thanks,
Maneesh



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/sudo-update-rc-d-activemq-multiuser-throws-error-tp4717903p4717930.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Activemq not listening to 61613

[maneeshmp]

with the below simple configuration, I am not able to make activemq listen to
61613
Service is running fine,
sudo service activemq status
 * Checking status of ActiveMQ instance activemqOK
but
netstat -an | grep 61613
doesnt now return anything. What am i doing wrong? Can anyone help me?



http://www.springframework.org/schema/beans;
  xmlns:amq="http://activemq.apache.org/schema/core;
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
  http://activemq.apache.org/schema/core
http://activemq.apache.org/schema/core/activemq-core.xsd;>




http://activemq.apache.org/schema/core;
useJmx="false"
brokerName="mytest.com"
dataDirectory="${activemq.base}/data"
schedulePeriodForDestinationPurge="6000"
   >









  
  


   

   
  
  
  
  
  
  

  

  

  
  
  
  
  
  
  

  

 
   
   
  

  


>

  
89,1  Bot




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Activemq-not-listening-to-61613-tp4717902.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

sudo update-rc.d activemq multiuser throws error

[maneeshmp]

When I execute the command,
sudo update-rc.d activemq multiuser
I get below error,

$ sudo update-rc.d activemq multiuser
update-rc.d: warning: activemq start runlevel arguments (none) do not match
LSB Default-Start values (2 3 4 5)
update-rc.d: warning: activemq stop runlevel arguments (none) do not match
LSB Default-Stop values (0 1 6)
usage: update-rc.d [-n] [-f]  remove
   update-rc.d [-n]  defaults [NN | SS KK]
   update-rc.d [-n]  start|stop NN runlvl [runlvl] [...] .
   update-rc.d [-n]  disable|enable [S|2|3|4|5]
-n: not really
-f: force

The disable|enable API is not stable and might change in the future.

What needs to be changed?



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/sudo-update-rc-d-activemq-multiuser-throws-error-tp4717903.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: increasing number of pending message when consumer hit wrong url

[MariscaJane]

.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/increasing-number-of-pending-message-when-consumer-hit-wrong-url-tp4717857p4717893.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Virtual topics, custom prefix limitations

[Tim Bain]

The description on the Network of Brokers wiki page says that what you're
trying to do won't work without those flags set, so you should upgrade if
this is a feature you need to use.

Tim

On Oct 13, 2016 6:33 PM, "Devlin"  wrote:

> Hi Tim,
>
> We managed to get working virtual topics in a 2 broker network, but only
> for
> cases where producer and consumers are using the same broker; consumers
> connected to the broker where the producer is not present did not receive
> messages. We confirmed the network functions as expected for standard
> topics/queues, but not for virtual topics.
>
> I found this in the docs, looks interesting, not sure if it would help, but
> regardless, it's for 5.13, we're on 5.11.
>   useVirtualDestSubsOnCreation="true">
>  .
>   
>
> Here's our config:
>
> 
> 
>  prefix="*.*.*._vsub.*."  selectorAware="true"/>
> 
> 
> 
>
> 
> name="owire"
> uri="tcp://0.0.0.0:61616"
> updateClusterClients="true"
> updateClusterClientsOnRemove="true"/>
> 
>
> 
>  name="queueNetwork"
> userName="${auth.user}"
> password="${auth.password}"
> uri="${network.uri.1}?${network.options}"
> consumerTTL="1"
> messageTTL="100"
> conduitSubscriptions="false"
> decreaseNetworkConsumerPriority="true"
> suppressDuplicateQueueSubscriptions="true">
> 
> 
> 
> 
> 
> 
> 
>  name="topicNetwork"
> userName="${auth.user}"
> password="${auth.password}"
> uri="${network.uri.1}?${network.options}"
> consumerTTL="1"
> messageTTL="100"
> decreaseNetworkConsumerPriority="true">
> 
> 
> 
> 
> 
>
> 
>   
> 
>  topic=">"
>   producerFlowControl="true"
>   gcInactiveDestinations="true"
>   inactiveTimoutBeforeGC="60">
> 
>  limit="5000"/>
> 
>   
>  queue=">"
>   producerFlowControl="true"
>   memoryLimit="20mb"
>   enableAudit="false"
>   gcInactiveDestinations="true"
>   inactiveTimoutBeforeGC="60">
>   
>replayWhenNoConsumers="true"
>   replayDelay="1000" />
>   
>   
> 
>   
> 
>
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Virtual-topics-custom-prefix-limitations-tp4717481p4717887.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Re: Duplicating messages published to a Topic to a Queue

[Martyn Taylor]

Good to hear,

Re: Your comments

The "jms.topic." and "jms.queue." prefix requirements are causing a lot of
confusion for many users, hopefully it'll be resolved soon, as part of:
https://issues.apache.org/jira/browse/ARTEMIS-780

Regarding the divert name, we should probably throw an exception on boot to
make this clearer.  I've opened a JIRA here:
https://issues.apache.org/jira/browse/ARTEMIS-802

Thanks




On Thu, Oct 13, 2016 at 1:50 PM, Lachezar Dobrev  wrote:

>   Thanks!
>   Diverting was exactly what I was looking for. Creating a non-exclusive
> divert from the topic to the queue did the trick without any class changes.
> Very nice. Using the Spring support for declarative configuration
> management it is pretty easy to declare diverts.
>   A few things bit me on the way though:
>   - diver name must be specified, otherwise the diver is ignored with a log
> message (easily missed)
>   - to divert topic named "topic.whatever" the address must be
> "jms.topic.topic.whatever"
>   - to divert to a query named "query.whatever" the forwarding address must
> be "jms.queue.queue.whatever"
>
>   Otherwise the diverts work pretty well, I even managed to catch one queue
> message being processed on a different node than the one sending the topic
> message, which is exactly what I was hoping for.
>
>   Thanks again for the directions.
>
> 2016-10-07 13:10 GMT+03:00 Martyn Taylor :
>
> > I don't have enough information to understand you problem fully.  But
> > perhaps you could use a combination of duplicate detection and diverts
> > could solve your problem.
> >
> > https://activemq.apache.org/artemis/docs/1.4.0/duplicate-detection.htm
> > https://activemq.apache.org/artemis/docs/1.4.0/diverts.html
> >
> > Cheers
> > Martyn
> >
> >
> >
> > On Mon, Oct 3, 2016 at 2:54 PM, Lachezar Dobrev 
> > wrote:
> >
> > >   Hello all,
> > >
> > >   I have a design problem: a topic is clustered in a network of brokers
> > to
> > > allow multiple nodes to handle events occurring in other nodes: i.e. a
> > user
> > > logs in on one node, but all nodes *might* need to know that.
> > >   A new requirement has surfaced, that copies of these messages need to
> > be
> > > sent to an external system (not a messaging system). The trivial
> solution
> > > is to add a new subscriber to the Topic that handles the delivery, but
> > > since this is a distributed system of equivalent nodes that ends up
> > sending
> > > the message multiple times, one per node in the cluster.
> > >
> > >   My current solution is to use Springframework's infrastructure (which
> > the
> > > Application is based on), and override the JMSTemplate with a custom
> one
> > > that sends a copy of every message sent to the Topic to a special Queue
> > > that the deliverer is handling. This seems to work just fine.
> > >
> > >   I'm wondering if there is any out-of-the-box solution to this problem
> > > provided by Artemis. Like routing/duplication/monitoring that I can
> turn
> > on
> > > and get the same (or similar) functionality.
> > >
> > >   Lachezar
> > >
> >
>

Re: HornetQ client connect to Artemis server

[Martyn Taylor]

Hi,

Artemis does support HornetQ 2.4.7.final clients and should work out of the
box.

Could you provide a reproducer?  We actually have some tests under
/tests/extra-tests/protocols/hornetq that test the HornetQ client against
the latest broker.  If you could contribute a test here that'd be perfect.
Once I have this I will investigate.

Otherwise just your broker config + some java reproducer should suffice.

Thanks

On Thu, Oct 13, 2016 at 3:25 PM, hcrobison 
wrote:

> We are in the process upgrading from HornetQ (2.4.7) to Artemis (1.4.0).
> Artemis server migration itself is working - server running and Artemis
> client can talk to server. However, we still need to support clients who
> use
> HornetQ client. We need HornetQ clients to be able to talk to the Artemis
> server. The current problem I am running into is the following
> exception.org.hornetq.api.core.HornetQConnectionTimedOutException:
> HQ119013:
> Timed out waiting to receive cluster topology. Group:nullat
> org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(
> ServerLocatorImpl.java:946)
> ~[hornetq-core-client-2.4.7.Final.jar:na]Please let me know what I need to
> provide for further investigation.
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/HornetQ-client-connect-to-Artemis-server-tp4717861.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: java.io.EOFException when ActiveMQ starts

[divinedragon]

Thanks Tim for making things clear. I tried out with the two brokers with
each pointing to other broker in *JMS_X_SITE_CSV_URL* and both the brokers
came up without any warning. This rules out the issue for any SSL.

For the self configuration, I figured that if the value in
*JMS_X_SITE_CSV_URL* matches to that of activemq's internal hostname naming
scheme, then I don't see the WARNING.

For my case, my Transport connections were starting as below

 INFO | Listening for connections at: tcp://divinedragonbox:7029
 INFO | Connector openwire started
 INFO | Listening for connections at: stomp://divinedragonbox:7030
 INFO | Connector stomp started
 INFO | Listening for connections at: ssl://divinedragonbox:7031

So, when I configured my *JMS_X_SITE_CSV_URL=ssl://divinedragonbox:7031*,
there were no WARNING generated. I will review and get more details about
networkConnectors, but for now, I guess this understanding helps a lot to
set this value correctly.

Thanks for the help. Appreciate it.


On Thu, Oct 13, 2016 at 11:52 AM, Tim Bain [via ActiveMQ] <
ml-node+s2283324n4717855...@n4.nabble.com> wrote:

> I've never tried configuring a broker with a static networkConnector
> connected to itself (why would I, it's a useless configuration), but it
> wouldn't surprise me if the broker rejected that self-connection, which
> could result in the EOFException you saw.  It's also possible that there's
> something wrong with your SSL configuration as you suggested; there's no
> good way in a mailing list discussion to check whether your truststore
> trusts your keystore and the certs are being presented properly since
> that's all about the binary content and you shouldn't be sharing that
> publicly, but you could test the SSL configuration by setting up two
> brokers (in a test environment) that each have their JMS_X_SITE_CSV_URL
> pointed at each other.  If that configuration gives you EOFExceptions,
> then
> switch to using the tcp transport and see what happens.  If you get errors
> with the ssl transport but not the tcp one, there's a good chance it's
> something wrong with your keys.
>
> As far as the current configuration (where you have a broker whose only
> networkConnection is a static:ssl: one to itself), it's not a useful
> configuration (having a networkConnector to yourself serves no purpose),
> and you proved early on in this discussion that removing it removes the
> WARN log line that you're concerned about.  So I disagree with your
> statement that "I feel the configuration still seems fine."  Either switch
> to something that serves the purpose you said you're trying to achieve
> (like the discovery: transport instead of the static: transport, or like
> listing your cross-site servers if you're going to continue using the
> static: transport) or take it out and eliminate the WARN line.
>
> Tim
>
> On Wed, Oct 12, 2016 at 10:25 AM, divinedragon <[hidden email]
> > wrote:
>
> > Oh ok. Anyhow, I feel the configuration still seems fine.  It still
> doesnt
> > explain the WARNING entry.
> >
> > On Oct 12, 2016 8:53 PM, "Tim Bain [via ActiveMQ]" <
> > [hidden email] >
> wrote:
> >
> > > Unfortunately the use of the term "discovery" is misleading.  The term
> is
> > > used as a generic superset over the discovery transport (which allows
> > > dynamic discovery at runtime) and the static transport (which allows
> > > static
> > > discovery at configuration time based on what's in your config file,
> but
> > > no
> > > dynamic discovery at runtime; the phrase "hard code" from the page you
> > > linked to is the relevant one).  It doesn't inherently mean you get
> > > dynamic
> > > discovery; you need to use the discovery transport for that.
> > >
> > > On Oct 12, 2016 7:25 AM, "divinedragon" <[hidden email]
> > > > wrote:
> > >
> > > > I was referring to this(static discovery section).
> > > >
> > > > http://activemq.apache.org/networks-of-brokers.html
> > > >
> > > >
> > > > On Wed, Oct 12, 2016 at 6:44 PM, Tim Bain [via ActiveMQ] <
> > > > [hidden email]  > type=node=4717847=1>>
> > > wrote:
> > > >
> > > > > I don't see anywhere that you're using the discovery transport (
> > > > > http://activemq.apache.org/discovery-transport-reference.html); am
> I
> > > > just
> > > > > not seeing it?  Automatic broker discovery isn't the default
> > behavior;
> > > > you
> > > > > have to use the discovery transport if you want that behavior.
> > > > >
> > > > > On Oct 12, 2016 7:08 AM, "divinedragon" <[hidden email]
> > > > > > wrote:
> > > > >
> > > > > > I wanted to configure automatic broker discovery. As of now, I
> just
> > > > have
> > > > > > one broker(localhost) and that is what I configured. Isn't it
> how
> > > that
> > > > > > should be configured?
> > > > > >
> > > > > > On Wed, Oct 12,