[jira] [Closed] (ARTEMIS-1973) Consumers connected but not consuming messages
[ https://issues.apache.org/jira/browse/ARTEMIS-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Chalmers closed ARTEMIS-1973. --- Resolution: Not A Problem > Consumers connected but not consuming messages > -- > > Key: ARTEMIS-1973 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1973 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 2.6.2 > Environment: Broker configuration attached as broker.xml >Reporter: Simon Chalmers >Priority: Blocker > Attachments: broker.xml > > > We have set up a number of queues, written message to those queues and then > we can see the consumers connected to the broker but they are not consuming > the messages from the queues. > When we restart the broker, the consumers now start processing and consuming > the messages. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1959) server startup failure caused by './artemis data print'
[
https://issues.apache.org/jira/browse/ARTEMIS-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic updated ARTEMIS-1959:
-
Fix Version/s: 2.7.0
> server startup failure caused by './artemis data print'
> ---
>
> Key: ARTEMIS-1959
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1959
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.6.2
>Reporter: tang pu
>Priority: Minor
> Fix For: 2.7.0
>
>
> "./artemis data print" causes artemis to fail to start
> set the journal-file-size to 100M.
> After executing " ./artemis data print", the Journal file list is as follows:
> -rw-r--r-- 1 artemis activemq 104857600 Jun 28 15:56 activemq-data-1.amq
> -rw-r--r-- 1 artemis activemq 104857600 Jun 28 15:56 activemq-data-2.amq
> {color:#FF}*-rw-r--r-- 1 artemis activemq 10485760 Jun 28 16:12
> activemq-data-3.amq*{color}
> {color:#FF}*-rw-r--r-- 1 artemis activemq 10485760 Jun 28 16:12
> activemq-data-4.amq*{color}
> "./artemis run"
> 2018-06-28 16:25:05,601 INFO [org.apache.activemq.artemis.core.server]
> AMQ221034: Waiting indefinitely to obtain live lock
> 2018-06-28 16:25:05,602 INFO [org.apache.activemq.artemis.core.server]
> AMQ221035: Live Server Obtained live lock
> *2018-06-28 16:25:05,788 ERROR [org.apache.activemq.artemis.core.server]
> AMQ224000: Failure in initialisation: java.lang.IllegalStateException: the
> file is not 104857600 bytes long!*
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1959) server startup failure caused by './artemis data print'
[
https://issues.apache.org/jira/browse/ARTEMIS-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic closed ARTEMIS-1959.
Resolution: Fixed
> server startup failure caused by './artemis data print'
> ---
>
> Key: ARTEMIS-1959
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1959
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.6.2
>Reporter: tang pu
>Priority: Minor
> Fix For: 2.7.0
>
>
> "./artemis data print" causes artemis to fail to start
> set the journal-file-size to 100M.
> After executing " ./artemis data print", the Journal file list is as follows:
> -rw-r--r-- 1 artemis activemq 104857600 Jun 28 15:56 activemq-data-1.amq
> -rw-r--r-- 1 artemis activemq 104857600 Jun 28 15:56 activemq-data-2.amq
> {color:#FF}*-rw-r--r-- 1 artemis activemq 10485760 Jun 28 16:12
> activemq-data-3.amq*{color}
> {color:#FF}*-rw-r--r-- 1 artemis activemq 10485760 Jun 28 16:12
> activemq-data-4.amq*{color}
> "./artemis run"
> 2018-06-28 16:25:05,601 INFO [org.apache.activemq.artemis.core.server]
> AMQ221034: Waiting indefinitely to obtain live lock
> 2018-06-28 16:25:05,602 INFO [org.apache.activemq.artemis.core.server]
> AMQ221035: Live Server Obtained live lock
> *2018-06-28 16:25:05,788 ERROR [org.apache.activemq.artemis.core.server]
> AMQ224000: Failure in initialisation: java.lang.IllegalStateException: the
> file is not 104857600 bytes long!*
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1959) server startup failure caused by './artemis data print'
[
https://issues.apache.org/jira/browse/ARTEMIS-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540100#comment-16540100
]
ASF subversion and git services commented on ARTEMIS-1959:
--
Commit 7c0f6633f1e6f4fbcfc754dd2be723e8eefbdca6 in activemq-artemis's branch
refs/heads/master from Clebert Suconic
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=7c0f663 ]
ARTEMIS-1959 Fixing JournalDataPrintTest
> server startup failure caused by './artemis data print'
> ---
>
> Key: ARTEMIS-1959
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1959
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.6.2
>Reporter: tang pu
>Priority: Minor
>
> "./artemis data print" causes artemis to fail to start
> set the journal-file-size to 100M.
> After executing " ./artemis data print", the Journal file list is as follows:
> -rw-r--r-- 1 artemis activemq 104857600 Jun 28 15:56 activemq-data-1.amq
> -rw-r--r-- 1 artemis activemq 104857600 Jun 28 15:56 activemq-data-2.amq
> {color:#FF}*-rw-r--r-- 1 artemis activemq 10485760 Jun 28 16:12
> activemq-data-3.amq*{color}
> {color:#FF}*-rw-r--r-- 1 artemis activemq 10485760 Jun 28 16:12
> activemq-data-4.amq*{color}
> "./artemis run"
> 2018-06-28 16:25:05,601 INFO [org.apache.activemq.artemis.core.server]
> AMQ221034: Waiting indefinitely to obtain live lock
> 2018-06-28 16:25:05,602 INFO [org.apache.activemq.artemis.core.server]
> AMQ221035: Live Server Obtained live lock
> *2018-06-28 16:25:05,788 ERROR [org.apache.activemq.artemis.core.server]
> AMQ224000: Failure in initialisation: java.lang.IllegalStateException: the
> file is not 104857600 bytes long!*
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1866) Make wait time for reply configurable once vote goes out to acquire a quorum.
[ https://issues.apache.org/jira/browse/ARTEMIS-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540099#comment-16540099 ] ASF subversion and git services commented on ARTEMIS-1866: -- Commit 048f46bd4f4b24109dd186f585730f6b14d05187 in activemq-artemis's branch refs/heads/master from Clebert Suconic [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=048f46b ] ARTEMIS-1866 Fixing QuorumResultWaitTest > Make wait time for reply configurable once vote goes out to acquire a quorum. > - > > Key: ARTEMIS-1866 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1866 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.5.0 >Reporter: Saurabh Rai >Priority: Major > Fix For: 2.7.0 > > > Quorum voting is used by both the live and the backup to decide what to do if > a replication connection is disconnected. Basically, the server will request > each live server in the cluster to vote as to whether it thinks the server it > is replicating to or from is still alive. You can also configure the time for > which the quorum manager will wait for the quorum vote response. Currently, > the value is hardcoded as 30 sec. We should change this 30-second wait to be > configurable. > Please find the logs for reference: > 2018-05-06 11:20:42,906 INFO [org.apache.activemq.artemis.core.server] > AMQ221066: Initiating quorum vote: LiveFailoverQuorumVote 2018-05-06 > 11:20:42,906 INFO [org.apache.activemq.artemis.core.server] AMQ221067: > Waiting 30 seconds for quorum vote results. 2018-05-06 11:20:42,914 INFO > [org.apache.activemq.artemis.core.server] AMQ221060: Sending quorum vote > request to amq2a/10.92.151.33:61716: ServerConnectVote > [nodeId=d41a0e0f-50da-11e8-9b2d-005056b01f85, vote=false] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1977) ASYNCIO can reduce sys-calls to retrieve I/O events
[ https://issues.apache.org/jira/browse/ARTEMIS-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540042#comment-16540042 ] ASF GitHub Bot commented on ARTEMIS-1977: - Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/2178 I close this because It needs to be refined and battle tested...it is a WIP :+1: > ASYNCIO can reduce sys-calls to retrieve I/O events > --- > > Key: ARTEMIS-1977 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1977 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.6.2 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Minor > Fix For: 2.7.0 > > > On LibAIO is possible to retrieve the I/O completion events without > using io_getevents sys-calls by reading the user-space ring buffer used by the > kernel to store them. > This is already beneficial for very fast disks and necessary for further > improvements > of ASYNCIO Journal to leverage (very) fast low-latency disks by going > completly > lock-free. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1977) ASYNCIO can reduce sys-calls to retrieve I/O events
[ https://issues.apache.org/jira/browse/ARTEMIS-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540043#comment-16540043 ] ASF GitHub Bot commented on ARTEMIS-1977: - Github user franz1981 closed the pull request at: https://github.com/apache/activemq-artemis/pull/2178 > ASYNCIO can reduce sys-calls to retrieve I/O events > --- > > Key: ARTEMIS-1977 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1977 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.6.2 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Minor > Fix For: 2.7.0 > > > On LibAIO is possible to retrieve the I/O completion events without > using io_getevents sys-calls by reading the user-space ring buffer used by the > kernel to store them. > This is already beneficial for very fast disks and necessary for further > improvements > of ASYNCIO Journal to leverage (very) fast low-latency disks by going > completly > lock-free. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-7009) ActiveMQ stop delivering messages
[ https://issues.apache.org/jira/browse/AMQ-7009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated AMQ-7009: -- Priority: Major (was: Critical) > ActiveMQ stop delivering messages > - > > Key: AMQ-7009 > URL: https://issues.apache.org/jira/browse/AMQ-7009 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.13.4 >Reporter: Nezih BEN FREDJ >Priority: Major > Attachments: MemoryMessageStore.java, activemq.log > > > We have a problem with ActiveMQ 5.13.4, it stop deliver messages to clients. > This happens completely randomly and we are not able to give a test case that > reproduce the problem > Activemq is configured to use the « memoryPersistenceAdapter » > > When examining memory dumps, we identified incoherent situation in the class > MemoryMessageStore that can lead to stop delivering messages. When : > - MemoryMessageStore.recoverNextMessages(...) is called > - « lastBatchId » is not null > - « messageTable » does not contains any entry with « lastBatchId » as key > no messages are recovered > > We added logs to try to understand how it is possible to have a non null « > lastBatchId » and « messageTable » with no entry having « lastBatchId » as > key. > > We noticed that the method setBatch is called with a non null « messageId » > parameter, but no message with this id is inserted in « messageTable ». After > that, when the method MemoryMessageStore.recoverNextMessages(...) is called, > it does nothing and no messages are recoverd. And the system go in a what > looks like an endless loop. > > We are testing a temporary solution by resetting « lastBatchId » to null when > the incoherent situation is detected. > > Can you help us resolving the problem at the source and not just get around. > I joined modified source code of the class MemoryMessageStore and an extract > of the log file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7009) ActiveMQ stop delivering messages
[ https://issues.apache.org/jira/browse/AMQ-7009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540036#comment-16540036 ] Timothy Bish commented on AMQ-7009: --- The version you are using is old an not a supported release, please upgrade to the latest release and then report back if the problem persists. > ActiveMQ stop delivering messages > - > > Key: AMQ-7009 > URL: https://issues.apache.org/jira/browse/AMQ-7009 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.13.4 >Reporter: Nezih BEN FREDJ >Priority: Critical > Attachments: MemoryMessageStore.java, activemq.log > > > We have a problem with ActiveMQ 5.13.4, it stop deliver messages to clients. > This happens completely randomly and we are not able to give a test case that > reproduce the problem > Activemq is configured to use the « memoryPersistenceAdapter » > > When examining memory dumps, we identified incoherent situation in the class > MemoryMessageStore that can lead to stop delivering messages. When : > - MemoryMessageStore.recoverNextMessages(...) is called > - « lastBatchId » is not null > - « messageTable » does not contains any entry with « lastBatchId » as key > no messages are recovered > > We added logs to try to understand how it is possible to have a non null « > lastBatchId » and « messageTable » with no entry having « lastBatchId » as > key. > > We noticed that the method setBatch is called with a non null « messageId » > parameter, but no message with this id is inserted in « messageTable ». After > that, when the method MemoryMessageStore.recoverNextMessages(...) is called, > it does nothing and no messages are recoverd. And the system go in a what > looks like an endless loop. > > We are testing a temporary solution by resetting « lastBatchId » to null when > the incoherent situation is detected. > > Can you help us resolving the problem at the source and not just get around. > I joined modified source code of the class MemoryMessageStore and an extract > of the log file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-7009) ActiveMQ stop delivering messages
[ https://issues.apache.org/jira/browse/AMQ-7009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nezih BEN FREDJ updated AMQ-7009: - Priority: Critical (was: Major) > ActiveMQ stop delivering messages > - > > Key: AMQ-7009 > URL: https://issues.apache.org/jira/browse/AMQ-7009 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.13.4 >Reporter: Nezih BEN FREDJ >Priority: Critical > Attachments: MemoryMessageStore.java, activemq.log > > > We have a problem with ActiveMQ 5.13.4, it stop deliver messages to clients. > This happens completely randomly and we are not able to give a test case that > reproduce the problem > Activemq is configured to use the « memoryPersistenceAdapter » > > When examining memory dumps, we identified incoherent situation in the class > MemoryMessageStore that can lead to stop delivering messages. When : > - MemoryMessageStore.recoverNextMessages(...) is called > - « lastBatchId » is not null > - « messageTable » does not contains any entry with « lastBatchId » as key > no messages are recovered > > We added logs to try to understand how it is possible to have a non null « > lastBatchId » and « messageTable » with no entry having « lastBatchId » as > key. > > We noticed that the method setBatch is called with a non null « messageId » > parameter, but no message with this id is inserted in « messageTable ». After > that, when the method MemoryMessageStore.recoverNextMessages(...) is called, > it does nothing and no messages are recoverd. And the system go in a what > looks like an endless loop. > > We are testing a temporary solution by resetting « lastBatchId » to null when > the incoherent situation is detected. > > Can you help us resolving the problem at the source and not just get around. > I joined modified source code of the class MemoryMessageStore and an extract > of the log file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1976) AMQP IdleTimeout ignoring user defined value
[
https://issues.apache.org/jira/browse/ARTEMIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed ARTEMIS-1976.
---
Resolution: Invalid
You are apparently using Artemis 2.6.2, which does not contain the
functionality from ARTEMIS-1924 according to the JIRA.
Seperately, you are misinterpretting the actual activity shown by the logs.
They show the python client *receiving* lots of heartbeats (probably every
750ms), which the broker has sent to satisfy the python clients 1500ms
idle-timeout value advertised in its Open frame (because you set the actual
timeout to 3000ms). The client will be sending every 15sec to satisfy the
brokers advertised 30sec Open frame idle-timeout (based on its default 60sec
actual timeout).
The final logs, from a JMS client, dont show any heartbeats because actual
traffic is occurring in both directions (presumably from a consumer recieve
call with 3sec timeout completing without any message being available). There
will be no heartbeats in that case, since it would require 15 seconds of
inactivity in either direction.
> AMQP IdleTimeout ignoring user defined value
>
>
> Key: ARTEMIS-1976
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1976
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Oleg Sushchenko
>Priority: Major
>
> Steps:
> * configure broker.xml with amqpIdleTimeout=4000 value:
> {code:java}
> name="amqp">tcp://0.0.0.0:5672?amqpIdleTimeout=4000;tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=AMQP;useEpoll=true;amqpCredits=1000;amqpLowCredits=300
> {code}
>
> * start broker
> * connect to broker with client
> * check broker logs
> Expected result:
> * I get Empty Frames every 2 seconds
> Actual results:
> * Seems that value is not working because I get an Empty Frame every 15
> seconds
> {code:java}
> 2018-07-10 10:08:29,282 FINE [proton.trace] IN: CH[0] : Empty Frame
> 2018-07-10 10:08:44,282 FINE [proton.trace] IN: CH[0] : Empty Frame
> 2018-07-10 10:08:59,282 FINE [proton.trace] IN: CH[0] : Empty Frame
> 2018-07-10 10:09:14,282 FINE [proton.trace] IN: CH[0] : Empty Frame
> 2018-07-10 10:09:29,283 FINE [proton.trace] IN: CH[0] : Empty Frame
> 2018-07-10 10:09:44,282 FINE [proton.trace] IN: CH[0] : Empty Frame
> 2018-07-10 10:09:59,282 FINE [proton.trace] IN: CH[0] : Empty Frame
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (ARTEMIS-1976) AMQP IdleTimeout ignoring user defined value
[
https://issues.apache.org/jira/browse/ARTEMIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539775#comment-16539775
]
Oleg Sushchenko edited comment on ARTEMIS-1976 at 7/11/18 9:32 AM:
---
Sorry for reopening.. But I need some help. Please, provide more information
how it works and what I should see in logs.
My steps:
I configured broker.xml by adding this value:
{code}tcp://0.0.0.0:5672?amqpIdleTimeout=1;tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=AMQP;useEpoll=true;amqpCredits=1000;amqpLowCredits=300
{code}
start a client (java/python - behaviour the same):
{code}python receiver.py --conn-heartbeat 3 --broker-url
localhost:5672/examples --timeout 3000{code}
(you can use https://pypi.python.org/pypi/cli-proton-python client for trying)
and get this log:
{code:java}
[0x220df00]: -> SASL
[0x220df00]: <- SASL
[0x220df00]:0 <- @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
[0x220df00]:0 ->
@sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b"anonymous@dhcp"]
[0x220df00]:0 <- @sasl-outcome(68) [code=0]
[0x220df00]: <- AMQP
[0x220df00]: -> AMQP
[0x220df00]:0 -> @open(16)
[container-id="a7752400-0758-4db0-b619-740569e63941", hostname="localhost",
channel-max=32767, idle-time-out=1500]
[0x220df00]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=2147483647]
[0x220df00]:0 -> @attach(18)
[name="a7752400-0758-4db0-b619-740569e63941-examples", handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="exa
mples", durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0,
timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0]
[0x220df00]:0 -> @flow(19) [incoming-window=2147483647,
next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0,
link-credit=10, drain=false]
[0x220df00]:0 <- @open(16) [container-id="my-broker-2.6.2",
max-frame-size=131072, channel-max=65535, idle-time-out=3,
offered-capabilities=@PN_SYMBOL[:"sole-connection-for-container",
:"DELAYED_DELIVERY", :"SHARED-SUBS", :"ANONYMOUS-RELAY"],
properties={:product="apache-activemq-artemis", :version="2.6.2"}]
[0x220df00]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1,
incoming-window=2147483647, outgoing-window=2147483647, handle-max=65535]
[0x220df00]:0 <- @attach(18)
[name="a7752400-0758-4db0-b619-740569e63941-examples", handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="ex
amples"], target=@target(41) [], incomplete-unsettled=false,
initial-delivery-count=0]
[0x220df00]:0 <- (EMPTY FRAME)
[0x220df00]:0 <- (EMPTY FRAME)
[0x220df00]:0 <- (EMPTY FRAME)
[0x220df00]:0 <- (EMPTY FRAME)
[0x220df00]:0 <- (EMPTY FRAME)
[0x220df00]:0 <- (EMPTY FRAME)
[0x220df00]:0 <- (EMPTY FRAME)
[jira] [Reopened] (ARTEMIS-1976) AMQP IdleTimeout ignoring user defined value
[
https://issues.apache.org/jira/browse/ARTEMIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Sushchenko reopened ARTEMIS-1976:
--
> AMQP IdleTimeout ignoring user defined value
>
>
> Key: ARTEMIS-1976
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1976
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Oleg Sushchenko
>Priority: Major
>
> Steps:
> * configure broker.xml with amqpIdleTimeout=4000 value:
> {code:java}
> name="amqp">tcp://0.0.0.0:5672?amqpIdleTimeout=4000;tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=AMQP;useEpoll=true;amqpCredits=1000;amqpLowCredits=300
> {code}
>
> * start broker
> * connect to broker with client
> * check broker logs
> Expected result:
> * I get Empty Frames every 2 seconds
> Actual results:
> * Seems that value is not working because I get an Empty Frame every 15
> seconds
> {code:java}
> 2018-07-10 10:08:29,282 FINE [proton.trace] IN: CH[0] : Empty Frame
> 2018-07-10 10:08:44,282 FINE [proton.trace] IN: CH[0] : Empty Frame
> 2018-07-10 10:08:59,282 FINE [proton.trace] IN: CH[0] : Empty Frame
> 2018-07-10 10:09:14,282 FINE [proton.trace] IN: CH[0] : Empty Frame
> 2018-07-10 10:09:29,283 FINE [proton.trace] IN: CH[0] : Empty Frame
> 2018-07-10 10:09:44,282 FINE [proton.trace] IN: CH[0] : Empty Frame
> 2018-07-10 10:09:59,282 FINE [proton.trace] IN: CH[0] : Empty Frame
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1977) ASYNCIO can reduce sys-calls to retrieve I/O events
[ https://issues.apache.org/jira/browse/ARTEMIS-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539782#comment-16539782 ] ASF GitHub Bot commented on ARTEMIS-1977: - Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/2178 I think that @clebertsuconic and @michaelandrepearce would be interested in this :+1: I would like to be reviewed on this: in particular given that I have target x86_64 to define the barriers: AFAIK C11 allow to define them without any assembly definition as I have done, but I don't know how many architecture we are supporting. > ASYNCIO can reduce sys-calls to retrieve I/O events > --- > > Key: ARTEMIS-1977 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1977 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.6.2 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Minor > Fix For: 2.7.0 > > > On LibAIO is possible to retrieve the I/O completion events without > using io_getevents sys-calls by reading the user-space ring buffer used by the > kernel to store them. > This is already beneficial for very fast disks and necessary for further > improvements > of ASYNCIO Journal to leverage (very) fast low-latency disks by going > completly > lock-free. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1977) ASYNCIO can reduce sys-calls to retrieve I/O events
[ https://issues.apache.org/jira/browse/ARTEMIS-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539781#comment-16539781 ] ASF GitHub Bot commented on ARTEMIS-1977: - GitHub user franz1981 opened a pull request: https://github.com/apache/activemq-artemis/pull/2178 ARTEMIS-1977 ASYNCIO can reduce sys-calls to retrieve I/O events On LibAIO is possible to retrieve the I/O completion events without using io_getevents sys-calls by reading the user-space ring buffer used by the kernel to store them. This commit include another optimization to avoid calling a method to obtain the buffers address, saving safepoint polls, a method call and implicit instance of checks performed. You can merge this pull request into a Git repository by running: $ git pull https://github.com/franz1981/activemq-artemis user_space_io_getevents Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2178.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2178 commit 77e577f40b8993729f6b9c357a1276f6bf930571 Author: Francesco Nigro Date: 2018-07-04T08:43:19Z ARTEMIS-1977 ASYNCIO can reduce sys-calls to retrieve I/O events On LibAIO is possible to retrieve the I/O completion events without using io_getevents sys-calls by reading the user-space ring buffer used by the kernel to store them. This commit include another optimization to avoid calling a method to obtain the buffers address, saving safepoint polls, a method call and implicit instance of checks performed. > ASYNCIO can reduce sys-calls to retrieve I/O events > --- > > Key: ARTEMIS-1977 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1977 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.6.2 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Minor > Fix For: 2.7.0 > > > On LibAIO is possible to retrieve the I/O completion events without > using io_getevents sys-calls by reading the user-space ring buffer used by the > kernel to store them. > This is already beneficial for very fast disks and necessary for further > improvements > of ASYNCIO Journal to leverage (very) fast low-latency disks by going > completly > lock-free. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1976) AMQP IdleTimeout ignoring user defined value
[
https://issues.apache.org/jira/browse/ARTEMIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539775#comment-16539775
]
Oleg Sushchenko commented on ARTEMIS-1976:
--
Please, provide more information how it works and what I should see in logs.
My steps:
I configured broker.xml by adding this value:
{code}tcp://0.0.0.0:5672?amqpIdleTimeout=1;tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=AMQP;useEpoll=true;amqpCredits=1000;amqpLowCredits=300
{code}
start a client (java/python - behaviour the same):
{code}python receiver.py --conn-heartbeat 3 --broker-url
localhost:5672/examples --timeout 3000{code}
(you can use https://pypi.python.org/pypi/cli-proton-python client for trying)
and get this log:
{code:java}
[0x220df00]: -> SASL
[0x220df00]: <- SASL
[0x220df00]:0 <- @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
[0x220df00]:0 ->
@sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b"anonymous@dhcp"]
[0x220df00]:0 <- @sasl-outcome(68) [code=0]
[0x220df00]: <- AMQP
[0x220df00]: -> AMQP
[0x220df00]:0 -> @open(16)
[container-id="a7752400-0758-4db0-b619-740569e63941", hostname="localhost",
channel-max=32767, idle-time-out=1500]
[0x220df00]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=2147483647]
[0x220df00]:0 -> @attach(18)
[name="a7752400-0758-4db0-b619-740569e63941-examples", handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="exa
mples", durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0,
timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0]
[0x220df00]:0 -> @flow(19) [incoming-window=2147483647,
next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0,
link-credit=10, drain=false]
[0x220df00]:0 <- @open(16) [container-id="my-broker-2.6.2",
max-frame-size=131072, channel-max=65535, idle-time-out=3,
offered-capabilities=@PN_SYMBOL[:"sole-connection-for-container",
:"DELAYED_DELIVERY", :"SHARED-SUBS", :"ANONYMOUS-RELAY"],
properties={:product="apache-activemq-artemis", :version="2.6.2"}]
[0x220df00]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1,
incoming-window=2147483647, outgoing-window=2147483647, handle-max=65535]
[0x220df00]:0 <- @attach(18)
[name="a7752400-0758-4db0-b619-740569e63941-examples", handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="ex
amples"], target=@target(41) [], incomplete-unsettled=false,
initial-delivery-count=0]
[0x220df00]:0 <- (EMPTY FRAME)
[0x220df00]:0 <- (EMPTY FRAME)
[0x220df00]:0 <- (EMPTY FRAME)
[0x220df00]:0 <- (EMPTY FRAME)
[0x220df00]:0 <- (EMPTY FRAME)
[0x220df00]:0 <- (EMPTY FRAME)
[0x220df00]:0 <- (EMPTY FRAME)
[jira] [Updated] (ARTEMIS-1977) ASYNCIO can reduce sys-calls to retrieve I/O events
[ https://issues.apache.org/jira/browse/ARTEMIS-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Nigro updated ARTEMIS-1977: - Summary: ASYNCIO can reduce sys-calls to retrieve I/O events (was: ASYNCIO can reduce sys-calls to retrieve I/O completion events) > ASYNCIO can reduce sys-calls to retrieve I/O events > --- > > Key: ARTEMIS-1977 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1977 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.6.2 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Minor > Fix For: 2.7.0 > > > On LibAIO is possible to retrieve the I/O completion events without > using io_getevents sys-calls by reading the user-space ring buffer used by the > kernel to store them. > This is already beneficial for very fast disks and necessary for further > improvements > of ASYNCIO Journal to leverage (very) fast low-latency disks by going > completly > lock-free. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (ARTEMIS-1977) ASYNCIO can reduce sys-calls to retrieve I/O completion events
[ https://issues.apache.org/jira/browse/ARTEMIS-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539754#comment-16539754 ] Francesco Nigro edited comment on ARTEMIS-1977 at 7/11/18 9:04 AM: --- Currently there are low-latency DBMS that support this feature with success: [https://groups.google.com/forum/#!msg/seastar-dev/DSXC5UcIsTg/LD13i1vmAAAJ;context-place=topic/seastar-dev/zdr01znzUes]. The next step is to expose through JNI this feature and allow an even loop style of processing of I/O events, possibly lock-free and with smart batching to reduce the submit sys-calls without impacting on latencies. was (Author: nigro@gmail.com): Currently there are low-latency DBMS that support this feature with success: [PATCH seastar v2 2/6 linux-aio: try to perform io_getevents in userspace|[https://groups.google.com/forum/#!msg/seastar-dev/DSXC5UcIsTg/LD13i1vmAAAJ;context-place=topic/seastar-dev/zdr01znzUes]] The next step is to expose through JNI this feature and allow an even loop style of processing of I/O events, possibly lock-free and with smart batching to reduce the submit sys-calls without impacting on latencies. > ASYNCIO can reduce sys-calls to retrieve I/O completion events > -- > > Key: ARTEMIS-1977 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1977 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.6.2 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Minor > Fix For: 2.7.0 > > > On LibAIO is possible to retrieve the I/O completion events without > using io_getevents sys-calls by reading the user-space ring buffer used by the > kernel to store them. > This is already beneficial for very fast disks and necessary for further > improvements > of ASYNCIO Journal to leverage (very) fast low-latency disks by going > completly > lock-free. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (ARTEMIS-1977) ASYNCIO can reduce sys-calls to retrieve I/O completion events
[ https://issues.apache.org/jira/browse/ARTEMIS-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539754#comment-16539754 ] Francesco Nigro edited comment on ARTEMIS-1977 at 7/11/18 9:03 AM: --- Currently there are low-latency DBMS that support this feature with success: [PATCH seastar v2 2/6 linux-aio: try to perform io_getevents in userspace|[https://groups.google.com/forum/#!msg/seastar-dev/DSXC5UcIsTg/LD13i1vmAAAJ;context-place=topic/seastar-dev/zdr01znzUes]] The next step is to expose through JNI this feature and allow an even loop style of processing of I/O events, possibly lock-free and with smart batching to reduce the submit sys-calls without impacting on latencies. was (Author: nigro@gmail.com): Currently there are low-latency DBMS that support this feature with success: [PATCH seastar v2 2/6 linux-aio: try to perform io_getevents in userspace|[https://groups.google.com/forum/#!msg/seastar-dev/DSXC5UcIsTg/LD13i1vmAAAJ;context-place=topic/seastar-dev/zdr01znzUes].] The next step is to expose through JNI this feature and allow an even loop style of processing of I/O events, possibly lock-free and with smart batching to reduce the submit sys-calls without impacting on latencies. > ASYNCIO can reduce sys-calls to retrieve I/O completion events > -- > > Key: ARTEMIS-1977 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1977 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.6.2 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Minor > Fix For: 2.7.0 > > > On LibAIO is possible to retrieve the I/O completion events without > using io_getevents sys-calls by reading the user-space ring buffer used by the > kernel to store them. > This is already beneficial for very fast disks and necessary for further > improvements > of ASYNCIO Journal to leverage (very) fast low-latency disks by going > completly > lock-free. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (ARTEMIS-1977) ASYNCIO can reduce sys-calls to retrieve I/O completion events
[ https://issues.apache.org/jira/browse/ARTEMIS-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539754#comment-16539754 ] Francesco Nigro edited comment on ARTEMIS-1977 at 7/11/18 9:02 AM: --- Currently there are low-latency DBMS that support this feature with success: [PATCH seastar v2 2/6 linux-aio: try to perform io_getevents in userspace|[https://groups.google.com/forum/#!msg/seastar-dev/DSXC5UcIsTg/LD13i1vmAAAJ;context-place=topic/seastar-dev/zdr01znzUes].] The next step is to expose through JNI this feature and allow an even loop style of processing of I/O events, possibly lock-free and with smart batching to reduce the submit sys-calls without impacting on latencies. was (Author: nigro@gmail.com): Currently there are low-latency DBMS that support this feature with success: [[PATCH seastar v2 2/6] linux-aio: try to perform io_getevents in userspace|[https://groups.google.com/forum/#!msg/seastar-dev/DSXC5UcIsTg/LD13i1vmAAAJ;context-place=topic/seastar-dev/zdr01znzUes].] The next step is to expose through JNI this feature and allow an even loop style of processing of I/O events, possibly lock-free and with smart batching to reduce the submit sys-calls without impacting on latencies. > ASYNCIO can reduce sys-calls to retrieve I/O completion events > -- > > Key: ARTEMIS-1977 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1977 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.6.2 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Minor > Fix For: 2.7.0 > > > On LibAIO is possible to retrieve the I/O completion events without > using io_getevents sys-calls by reading the user-space ring buffer used by the > kernel to store them. > This is already beneficial for very fast disks and necessary for further > improvements > of ASYNCIO Journal to leverage (very) fast low-latency disks by going > completly > lock-free. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1977) ASYNCIO can reduce sys-calls to retrieve I/O completion events
[ https://issues.apache.org/jira/browse/ARTEMIS-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539754#comment-16539754 ] Francesco Nigro commented on ARTEMIS-1977: -- Currently there are low-latency DBMS that support this feature with success: [[PATCH seastar v2 2/6] linux-aio: try to perform io_getevents in userspace|[https://groups.google.com/forum/#!msg/seastar-dev/DSXC5UcIsTg/LD13i1vmAAAJ;context-place=topic/seastar-dev/zdr01znzUes].] The next step is to expose through JNI this feature and allow an even loop style of processing of I/O events, possibly lock-free and with smart batching to reduce the submit sys-calls without impacting on latencies. > ASYNCIO can reduce sys-calls to retrieve I/O completion events > -- > > Key: ARTEMIS-1977 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1977 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.6.2 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Minor > Fix For: 2.7.0 > > > On LibAIO is possible to retrieve the I/O completion events without > using io_getevents sys-calls by reading the user-space ring buffer used by the > kernel to store them. > This is already beneficial for very fast disks and necessary for further > improvements > of ASYNCIO Journal to leverage (very) fast low-latency disks by going > completly > lock-free. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-1977) ASYNCIO can reduce sys-calls to retrieve I/O completion events
Francesco Nigro created ARTEMIS-1977: Summary: ASYNCIO can reduce sys-calls to retrieve I/O completion events Key: ARTEMIS-1977 URL: https://issues.apache.org/jira/browse/ARTEMIS-1977 Project: ActiveMQ Artemis Issue Type: Improvement Components: Broker Affects Versions: 2.6.2 Reporter: Francesco Nigro Assignee: Francesco Nigro Fix For: 2.7.0 On LibAIO is possible to retrieve the I/O completion events without using io_getevents sys-calls by reading the user-space ring buffer used by the kernel to store them. This is already beneficial for very fast disks and necessary for further improvements of ASYNCIO Journal to leverage (very) fast low-latency disks by going completly lock-free. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
