Re: Virtual Topics without existing consumers

[Tim Bain]

Messages sent to topics are kept until they have been delivered to all
consumers, so messages sent to topics with no consumers are deleted
immediately.

Tim

On Jun 22, 2017 10:06 AM, "sebasalvo"  wrote:

> Hi,
>
> I'm kind of a newbie in the ActiveMQ world. Please, let me ask you the
> following:
>
> What happens with messages delivered to a virtual topic that doesn't have a
> consumer (queues or regular topics) behind it? I mean, where do all those
> messages go? Are they kept in memory or in the kahadb storage?
>
> Thanks!
> Sebastian
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Virtual-Topics-without-existing-consumers-tp4727764.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.IllegalArgumentException: No JMSDestination parameter specified

[gq]

从官网新下的activemq,启动后浏览器访问，创建队列，一点create就报下面的错，不只是创建队列，创建topics也报这个错，
org.springframework.web.util.NestedServletException: Request processing
failed; nested exception is java.lang.IllegalArgumentException: No
JMSDestination parameter specified
at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:948)
at
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:838)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
at
org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:812)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at 
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:652)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1320)
at org.apache.activemq.web.AuditFilter.doFilter(AuditFilter.java:59)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1291)
at
org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1291)
at
org.apache.activemq.web.filter.ApplicationContextFilter.doFilter(ApplicationContextFilter.java:102)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1291)
at
com.opensymphony.sitemesh.webapp.SiteMeshFilter.obtainContent(SiteMeshFilter.java:129)
at
com.opensymphony.sitemesh.webapp.SiteMeshFilter.doFilter(SiteMeshFilter.java:77)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1291)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:443)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:521)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1044)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:372)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:189)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:978)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:521)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:367)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:486)
at
org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:937)
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:998)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:861)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
at
org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:628)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalArgumentException: No JMSDestination parameter
specified
at
org.apache.activemq.web.DestinationFacade.getValidDestination(DestinationFacade.java:112)
at
org.apache.activemq.web.DestinationFacade.addDestination(DestinationFacade.java:56)
at
org.apache.activemq.web.controller.CreateDestination.handleRequest(CreateDestination.java:38)
at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:925)
at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:856)
at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:936)
... 41 more
2017-06-23 08:52:54,024 | WARN  | /admin/createDestination.action |
org.eclipse.je

Re: org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.IllegalArgumentException: No JMSDestination parameter specified

[gq]

才开始以为是版本的问题，下了三四个不同的版本，都报这个错
以前也从官网下过，没报这个错啊，静等大虾解救



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/org-springframework-web-util-NestedServletException-Request-processing-failed-nested-exception-is-jad-tp4727806p4727807.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Virtual Topics without existing consumers

[sebasalvo]

Hi,

I'm kind of a newbie in the ActiveMQ world. Please, let me ask you the
following:

What happens with messages delivered to a virtual topic that doesn't have a
consumer (queues or regular topics) behind it? I mean, where do all those
messages go? Are they kept in memory or in the kahadb storage?

Thanks!
Sebastian



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Virtual-Topics-without-existing-consumers-tp4727764.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Artemis v2.1 divert

[abhijith]

Thanks Justin.   flag was the reason for store
filling up.  We were thinking address itself is storing messages, but it was
DLQ.  Thanks for the help



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Artemis-v2-1-divert-tp4727498p4727759.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Artemis 2.1.0 compatibility with 1.5.x

[nigro_franz]

Thanks to your comment on the branch I've noticed I've posted the wrong
branch, now I've fixed the branch name in the comment :P thanks!



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Artemis-2-1-0-compatibility-with-1-5-x-tp4727741p4727758.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Message grouping and MQTT

[Stuart Small]

That's what I was afraid of.  Thank you!

On Thu, Jun 22, 2017 at 7:46 AM, Timothy Bish  wrote:

> On 06/21/2017 08:51 PM, Stuart Small wrote:
>
>> I'm evaluating ActiveMQ for a new application I am building.  Message
>> grouping is the feature that has brought me to ActiveMQ and it looks
>> perfect for what I want.  The only problem is that I'm constrained to only
>> using MQTT.  It's unfortunately but sadly it is a hard requirement.  The
>> state of AMQP v1 and STOMP is the ecosystem we are working in isn't up to
>> speed.
>>
>> What short comings can I expect using MQTT vs the Core API or JMS?  Is
>> this
>> feature available over MQTT?  I've already started trying to code out a
>> couple clients to test it, but I figured it'd be best to ask the experts
>> first and save myself some time.
>>
>> Any help will be much appreciated
>>
>> I'm not aware of any way to assign MQTT messages into the groups that JMS
> or AMQP clients can do as the MQTT message has no metadata only a raw
> binary payload so the broker can't determine what group you'd be wanting to
> assign the message to.
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

Re: Message grouping and MQTT

[Timothy Bish]

On 06/21/2017 08:51 PM, Stuart Small wrote:

I'm evaluating ActiveMQ for a new application I am building.  Message
grouping is the feature that has brought me to ActiveMQ and it looks
perfect for what I want.  The only problem is that I'm constrained to only
using MQTT.  It's unfortunately but sadly it is a hard requirement.  The
state of AMQP v1 and STOMP is the ecosystem we are working in isn't up to
speed.

What short comings can I expect using MQTT vs the Core API or JMS?  Is this
feature available over MQTT?  I've already started trying to code out a
couple clients to test it, but I figured it'd be best to ask the experts
first and save myself some time.

Any help will be much appreciated

I'm not aware of any way to assign MQTT messages into the groups that 
JMS or AMQP clients can do as the MQTT message has no metadata only a 
raw binary payload so the broker can't determine what group you'd be 
wanting to assign the message to.


--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/

Re: CMS 3.9.2 process hangs when calling setMessageListener(..) in onMessage(...)

[Timothy Bish]

On 06/22/2017 04:48 AM, klaus.holst.jacobsen wrote:

Hello!

I would like to send a request and get a reply from a message handlers
onMessage(...) method.

Something like this:


void MyClass::onMessage(cms::Message m)
{
cms::Destination* tempDest = session_->createTemporaryQueue();
cms::MessageConsumer* responseConsumer = session_->createConsumer(tempDest);

SomeOtherMessageHandler replyHandler;
responseConsumer->setMessageListener(&replyHandler);

cms::Message* request = session_->createTextMessage();
m->setCMSReplyTo(tempDest);
p->send(m);

...wait for response...

cms::Message* response = replyHandler.getResponse();

}

...but my code hangs in setMessageListener(...);
My guess is that because I am in the onMessage method i have locked a mutex
that is required to do setMessageHandler(...)

Is this an error or not?
In any case, what is the work-around to be able to do request/reply from a
message handler?


Do a blocking receive call instead and wait for the response that way.



Thanks in advance.

Regards
Klaus




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/CMS-3-9-2-process-hangs-when-calling-setMessageListener-in-onMessage-tp4727730.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.



--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/

Re: High swap usage and network timeouts during heavy publishing

[Tim Bain]

Have you confirmed (via techniques such as the ones described in
https://www.cyberciti.biz/faq/linux-which-process-is-using-swap/) that the
ActiveMQ process is the one whose pages are getting swapped?

Also, what does top show your buffer usage (i.e. Linux using memory to
buffer disk writes for performance reasons) during this period of time?

Linux has an OS setting (vm.swappiness) that will let you control how
willing the OS is to swap out pages. You could adjust this value to make
paging less likely (or forbid it entirely) if you wanted.

Tim

On Jun 21, 2017 12:53 PM, "Abhinav2510"  wrote:

> In ActiveMQ 5.13.2 .
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/High-swap-usage-and-network-timeouts-during-heavy-publishing-
> tp4661946p4727692.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Re: Artemis 2.1.0 compatibility with 1.5.x

[Justin Bertram]

A 1.5.1 client should be able to interact with a 2.1.0 broker.  I don't
know why there would be a difference in the size of the messages.

To be clear, the new encoding applies to AMQP messages which you don't
appear to be using.

Can you work up a simple, reproducible test-case to demonstrate the issue
you're seeing?


Justin

On Thu, Jun 22, 2017 at 7:33 AM, hcrobison 
wrote:

> We have been using Artemis 1.5.1. Recently we upgrade the server to 2.1.0.
> While it can communicate with 2.1.0 client successfully, it does not seem
> to
> work properly with 1.5.1 client.
>
> We are passing messages in protobuf format. The end result is the receiving
> end can no longer deserialize the protobuf messages due to the message body
> length problem. (com.google.protobuf.InvalidProtocolBufferException: While
> parsing a protocol message, the input ended unexpectedly in the middle of a
> field.  This could mean either than the input has been truncated or that an
> embedded message misreported its own length.)
>
> Our investigation shows that the message sent and received have a length
> difference of 4 bytes. What is causing this? Could the new message encoding
> has anything to do with this? Can a 2.1.0 server work with 1.5.1 client?
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Artemis-2-1-0-compatibility-with-1-5-x-tp4727741.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Re: Artemis 2.1.0 compatibility with 1.5.x

[nigro_franz]

Hi,

Yep, I'm testing what could be the cause right now.
My fix is here:
https://github.com/franz1981/activemq-artemis/tree/jms_core_q_already_exists_fix
if you want to try it
If the tests will be successfull I'll make a PR with it :)

Regards,
Franz



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Artemis-2-1-0-compatibility-with-1-5-x-tp4727741p4727743.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Artemis 2.1.0 compatibility with 1.5.x

[hcrobison]

We have been using Artemis 1.5.1. Recently we upgrade the server to 2.1.0.
While it can communicate with 2.1.0 client successfully, it does not seem to
work properly with 1.5.1 client. 

We are passing messages in protobuf format. The end result is the receiving
end can no longer deserialize the protobuf messages due to the message body
length problem. (com.google.protobuf.InvalidProtocolBufferException: While
parsing a protocol message, the input ended unexpectedly in the middle of a
field.  This could mean either than the input has been truncated or that an
embedded message misreported its own length.)

Our investigation shows that the message sent and received have a length
difference of 4 bytes. What is causing this? Could the new message encoding
has anything to do with this? Can a 2.1.0 server work with 1.5.1 client?



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Artemis-2-1-0-compatibility-with-1-5-x-tp4727741.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

CMS 3.9.2 process hangs when calling setMessageListener(..) in onMessage(...)

[klaus.holst.jacobsen]

Hello!

I would like to send a request and get a reply from a message handlers
onMessage(...) method.

Something like this:


void MyClass::onMessage(cms::Message m)
{
cms::Destination* tempDest = session_->createTemporaryQueue();
cms::MessageConsumer* responseConsumer = session_->createConsumer(tempDest);

SomeOtherMessageHandler replyHandler;
responseConsumer->setMessageListener(&replyHandler);

cms::Message* request = session_->createTextMessage();
m->setCMSReplyTo(tempDest);
p->send(m);

...wait for response...

cms::Message* response = replyHandler.getResponse();

}

...but my code hangs in setMessageListener(...);
My guess is that because I am in the onMessage method i have locked a mutex
that is required to do setMessageHandler(...)

Is this an error or not? 
In any case, what is the work-around to be able to do request/reply from a
message handler?

Thanks in advance.

Regards
Klaus




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/CMS-3-9-2-process-hangs-when-calling-setMessageListener-in-onMessage-tp4727730.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Switch to Artemis from ActiveMQ v5.14.4?

[Justin Bertram]

> protocol interoperability is available but still It looks like code
changes are required from the client side.

What code changes are required for OpenWire clients to connect to Artemis?
Please be as specific as possible.


> Will clients using ActiveMQ client jar be able to connect to the broker
running with Artemis ?

Yes.


> Currently clients uses ActiveMQConnectionFactory to initialize the
connection factory and gets connections. Do they have to make changes if we
switch broker to Artimis ?

No, they shouldn't have to.


Justin

On Thu, Jun 22, 2017 at 5:57 AM, khandelwalanuj <
anuj.cool.khandel...@gmail.com> wrote:

> Regarding interoperability: As you mentioned protocol interoperability is
> available but still It looks like code changes are required from the client
> side.
>
> To be more specific : Will clients using ActiveMQ client jar be able to
> connect to the broker running with Artemis ?
>
> Eg: Currently clients uses ActiveMQConnectionFactory to initialize the
> connection factory and gets connections. Do they have to make changes if we
> switch broker to Artimis ?
>
> Thanks,
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Switch-to-Artemis-from-ActiveMQ-v5-14-4-tp4727014p4727734.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Artemis as MQTT broker fail when load testing 10k publishers QoS1

[ublanquet]

Hello, I am currently using an artemis server as a mqtt broker for load
testing, and it seems sending messages with QoS1 make it blow up pretty fast
(10k connections publishing  1 message/s, usually break right at the end of
the first 10k batch, my client receive 10k messages or less): 
I get a lot of duplicate ack in the server log, queues freeze "taking too
long to flush deliveries", then I get "unable to send message" errors
because "AMQ119027: Could not find reference on consumer ID=15", and when
killing the frozen process, I get "Timed out waiting for write lock on
consumer." and a thread dump. 
Do you guys think it's a config problem, or a bug ? (a mosquitto server
takes way longer to accept the connections, but deal with the messages just
fine).

Attached are server log, thread dump, broker.xml
artemis.log
  
l artemis-thread_dump.log
  
broker.xml   

Typical relevant logs part




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Artemis-as-MQTT-broker-fail-when-load-testing-10k-publishers-QoS1-tp4727737.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Switch to Artemis from ActiveMQ v5.14.4?

[khandelwalanuj]

Regarding interoperability: As you mentioned protocol interoperability is
available but still It looks like code changes are required from the client
side. 

To be more specific : Will clients using ActiveMQ client jar be able to
connect to the broker running with Artemis ? 

Eg: Currently clients uses ActiveMQConnectionFactory to initialize the
connection factory and gets connections. Do they have to make changes if we
switch broker to Artimis ?

Thanks,




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Switch-to-Artemis-from-ActiveMQ-v5-14-4-tp4727014p4727734.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.