Re: artemis 2.2.0 logging disaster

2017-06-02 Thread hwaastad
Hi guys, and thx for answering. a quick summary of my setup: 1. Its 2.1.0 so I'm not running any snapshot 2. The load is pretty constant.(performance checks from nagios), approx 1.1GB data per month, 2.5 mill entries over MQTT. 3. We've been running activemq with virtualdestinations (mqtt->jms) ea

Re: artemis 2.2.0 logging disaster

2017-06-02 Thread Tim Bain
A quick Google search this morning led me to believe that this could be a memory leak in the Netty code. There are several recent bugs in the Netty JIRA that might be relevant. Tim On Jun 2, 2017 1:27 PM, "Clebert Suconic" wrote: > There was a recent bug fix on MQTT. are you using a snapshot af

Re: why AvtiveMq is slowly than Kafka?

2017-06-02 Thread Tim Bain
Were you comparing to ActiveMQ 5.x or to Artemis (or both)? Another difference between Kafka and (I believe) both flavors of ActiveMQ is that Kafka doesn't remove consumed messages, doesn't allow out-of-order message acknowledgements (so if you want that, you have to implement it yourself), and si

Re: ActiveMQ Embedded with Tomcat missing messages while restart

2017-06-02 Thread Justin Bertram
I don't see in your code where you're calling rollback either on any Hibernate or JMS resource. Typically in this kind of scenario you'd want the consumption of the message and the database operation to be atomic to ensure the integrity of your data (i.e. one message equals one database operati

Re: ActiveMQ Embedded with Tomcat missing messages while restart

2017-06-02 Thread rsahadevan
HI Justin, What you understood is correct. Consumer is writing to database. I tried with rollback and is not happening. Commit is failing in the DB and not happening rollback into activemq_msgs. This is the reason I was thinking about this approach . Please let me know anything I am missing in co

Re: artemis 2.2.0 logging disaster

2017-06-02 Thread Clebert Suconic
There was a recent bug fix on MQTT. are you using a snapshot after the fix? On Fri, Jun 2, 2017 at 12:59 PM, Michael André Pearce wrote: > Also sorry just one other question. > > Does this occur with 2.1.0? > > Sent from my iPhone > >> On 2 Jun 2017, at 17:57, Michael André Pearce >> wrote: >>

Re: ActiveMQ Embedded with Tomcat missing messages while restart

2017-06-02 Thread Justin Bertram
I don't understand the flow here. Is your JMS listener consuming messages and then attempting to insert them into a database using the invalid Hibernate session? If so, why don't you just rollback the session if the Hibernate operation fails and set a redelivery delay on the messages? Justin

Re: ActiveMQ Embedded with Tomcat missing messages while restart

2017-06-02 Thread rsahadevan
HI All, Identified the issue. JMS Listener fires before Hibernate is setup on Server startup. Could you some one help on below points 1) How I can delay jms:listener-container for 3 minutes to start. This will solve the issue. By the time hibernate session will be ready.

Re: artemis 2.2.0 logging disaster

2017-06-02 Thread Michael André Pearce
Also sorry just one other question. Does this occur with 2.1.0? Sent from my iPhone > On 2 Jun 2017, at 17:57, Michael André Pearce > wrote: > > Essentially just from this log output I assume the server your broker is > running out of ram to use. > This can be either > A) genuine memory l

Re: artemis 2.2.0 logging disaster

2017-06-02 Thread Michael André Pearce
Essentially just from this log output I assume the server your broker is running out of ram to use. This can be either A) genuine memory leak in artemis B) you simply don't have enough ram for the load/throughout. Some questions: Is the load constant? Do you have server ram usage metrics avai

Re: why AvtiveMq is slowly than Kafka?

2017-06-02 Thread nigro_franz
Someone has summoned me :) I can add to set journal-datasync to false to make the Artemis journal behaviour to be the same of the default of Kafka (more here: https://activemq.apache.org/artemis/docs/2.1.0/persistence.html) Considering to have enough memory it enables the persistence to be effectiv

Re: why AvtiveMq is slowly than Kafka?

2017-06-02 Thread Clebert Suconic
Also: Notice that with Kafka you always require a write on the disk... if you are sending telemetry that you afford losing you may also opt for non persistent. On Fri, Jun 2, 2017 at 11:25 AM, Clebert Suconic wrote: > I have written this blog post here: > > https://blogs.apache.org/activemq/entry

Re: why AvtiveMq is slowly than Kafka?

2017-06-02 Thread Clebert Suconic
I have written this blog post here: https://blogs.apache.org/activemq/entry/fast_messaging_with_artemis You can combine that with using MAPPED at your journal type: MAPPED ** BTW: I'm actually changing this text on "this could be ASYNCIO, NIO.. adding MAPPED as well. On Thu

Re: why AvtiveMq is slowly than Kafka?

2017-06-02 Thread Michael André Pearce
MMap journal in activemq artemis has an option similar that means data is safe from process crash but not being sync allowing for higher throughout/lowerlatency you're happy with physical crash the data may not have flushed to disk which is what i understand from the below. Maybe suggest lookin

why AvtiveMq is slowly than Kafka?

2017-06-02 Thread wangqinghuan
I don't understand why activemq is so slowly. I read some design document about KafKa. In Kafka,data is immediately written to a persistence log on the filesystem without flushing to disk. In effect this just means that it is transferred into the kernel's pagecache. Does activemq have this style of

Re: Getting jboss ejb in ativemq rar deployed within jboss

2017-06-02 Thread aragoubi
Hi Tim, TokenAuthentificationBroker is a class used to intercept the client connection to get the username(The token for me). It's the same thing as MyBroker class here http://activemq.apache.org/interceptors.html . Within the addConnection function

Re: Getting jboss ejb in ativemq rar deployed within jboss

2017-06-02 Thread Tim Bain
What's TokenAuthentificationBroker, where the exception is occurring? Is that your code? What's it doing around that line that's causing a JNDI lookup? On Jun 2, 2017 5:32 AM, "aragoubi" wrote: > I have an activemq broker deployed within my jboss server. > activemq is deployed as a rar file plac

Re: Measurement points of "enqueue time" metric

2017-06-02 Thread Tim Bain
Enqueue Time is the time between when the message is enqueued on the broker and when it is dequeued because the broker receives an ack from the consumer. So it doesn't include any time the producer might spend waiting for a connection, though it would include time the consumer spent waiting for a c

Re: activemq-cpp-3.9.4 fails to build fedora rawhide - openssl-1.1.0e related.

2017-06-02 Thread traylenator
 https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes -- View this message in context: http://activemq.2283324.n4.nabble.com/activemq-cpp-3-9-4-fails-to-build-fedora-rawhide-openssl-1-1-0e-related-tp4724037p4726931.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Getting jboss ejb in ativemq rar deployed within jboss

2017-06-02 Thread aragoubi
I have an activemq broker deployed within my jboss server. activemq is deployed as a rar file placed in jboss standalone/deployment repository. An other project is also deployed within my jboss as an ear file. This last is exposing some ejb objects in my jboss. I tried to get an ejb from a jar fi

Measurement points of "enqueue time" metric

2017-06-02 Thread Oliver Wulff
Hi there We're facing some performance issues with ActiveMQ and came across a high value of average enqueue time of 8200ms which is quite high. I'm wondering what the measure points are of "enqueue time"? If the message producer has no available connection to the broker is the waiting time inc

artemis 2.2.0 logging disaster

2017-06-02 Thread Helge Waastad
Hi, I'm running artemis 2.2.0 as a docker container. I'm collecting MQTT messages an these are consumed by a JMS consumer (artemis-jms-client) It's running fine for a while, but suddenly this appear (docker *- json.log): {"log":"19:16:12,338 WARN  [org.apache.activemq.artemis.core.remoting.impl.