[jira] [Commented] (ARTEMIS-2246) Documentation for configuration max-disk-usage is inaccurate.
[
https://issues.apache.org/jira/browse/ARTEMIS-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761376#comment-16761376
]
Justin Bertram commented on ARTEMIS-2246:
-
Technically speaking the documentation is accurate. The default
{{max-disk-usage}} is {{100}} as can be seen in [the
code|https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/api/config/ActiveMQDefaultConfiguration.java#L470].
Therefore, is {{max-disk-usage}} is *not set* in the broker configuration it
will default to {{100}}. However, this default [is
overridden|https://github.com/apache/activemq-artemis/blob/master/artemis-cli/src/main/resources/org/apache/activemq/artemis/cli/commands/etc/broker.xml#L63]
out of the box in broker.xml. This setting is accompanied by a comment which
explains the behavior so it wouldn't have been necessary to review all the
default configuration values but simply to look at the broker.xml.
That said, the documentation should be clarified.
> Documentation for configuration max-disk-usage is inaccurate.
> -
>
> Key: ARTEMIS-2246
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2246
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.6.4
>Reporter: Leo Provido
>Priority: Major
>
> During the execution of tests involving sending messages to the System, we
> observed that the System started blocking messages before the disk is full.
> According to the Configuration Reference
> ([https://activemq.apache.org/artemis/docs/1.4.0/configuration-index.html])
> documentation, the default value of the configuration max-disk-usage is 100.
> However, we discovered that the actual default value of max-disk-usage is 90.
> The file inspected is ./etc/broker.xml. Thus, the documentation is deemed
> inaccurate.
> We have the opinion that severity of this incident is Major because a) the
> documentation provides an inaccurate piece of information that influences the
> way we design our mitigation strategies for risks surrounding hardware
> resources utilization, and b) we don’t necessarily have the bandwidth to
> review all default configuration values.
> Inaccurate information may cause failure to provide message brokering
> services despite mitigation strategies being in place.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARTEMIS-2247) Value of an argument node related to ./bin/artermis-service.xml is incorrect
[ https://issues.apache.org/jira/browse/ARTEMIS-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leo Provido updated ARTEMIS-2247: - Summary: Value of an argument node related to ./bin/artermis-service.xml is incorrect (was: Value of an argument node related in ./bin/artermis-service.xml is incorrect) > Value of an argument node related to ./bin/artermis-service.xml is incorrect > > > Key: ARTEMIS-2247 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2247 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.4 >Reporter: Leo Provido >Priority: Major > > When we tried When we tried starting a broker we created, we observed that > the broker failed to start.starting a broker we created, we observed that the > broker failed to start. > According to the Using the Server > (https://activemq.apache.org/artemis/docs/latest/using-server.html) > documentation, we simply have to do: > _Or you can run the broker in the background using: >"/user/server/bin/artemis-service" start_ > We observed that a log file ./log/artermis-service.err.log was generated > after doing so, containing an error Error: Could not find or load main class > Files\Artemis\etc > We later figured out that, > _-Dartemis.instance.etc="%ARTEMIS_INSTANCE_ETC%"_ > Should be (without “): > -Dartemis.instance.etc=%ARTEMIS_INSTANCE_ETC% > We have the opinion that the severity of this incident is High because this > issue prevents running the broker without fixing it. > An incorrect argument in ./bin/artermis-service.xml causes failure to run a > broker. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-2247) Value of an argument node related in ./bin/artermis-service.xml is incorrect
Leo Provido created ARTEMIS-2247: Summary: Value of an argument node related in ./bin/artermis-service.xml is incorrect Key: ARTEMIS-2247 URL: https://issues.apache.org/jira/browse/ARTEMIS-2247 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 2.6.4 Reporter: Leo Provido When we tried When we tried starting a broker we created, we observed that the broker failed to start.starting a broker we created, we observed that the broker failed to start. According to the Using the Server (https://activemq.apache.org/artemis/docs/latest/using-server.html) documentation, we simply have to do: _Or you can run the broker in the background using: "/user/server/bin/artemis-service" start_ We observed that a log file ./log/artermis-service.err.log was generated after doing so, containing an error Error: Could not find or load main class Files\Artemis\etc We later figured out that, _-Dartemis.instance.etc="%ARTEMIS_INSTANCE_ETC%"_ Should be (without “): -Dartemis.instance.etc=%ARTEMIS_INSTANCE_ETC% We have the opinion that the severity of this incident is High because this issue prevents running the broker without fixing it. An incorrect argument in ./bin/artermis-service.xml causes failure to run a broker. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-2246) Documentation for configuration max-disk-usage is inaccurate.
Leo Provido created ARTEMIS-2246: Summary: Documentation for configuration max-disk-usage is inaccurate. Key: ARTEMIS-2246 URL: https://issues.apache.org/jira/browse/ARTEMIS-2246 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 2.6.4 Reporter: Leo Provido During the execution of tests involving sending messages to the System, we observed that the System started blocking messages before the disk is full. According to the Configuration Reference ([https://activemq.apache.org/artemis/docs/1.4.0/configuration-index.html]) documentation, the default value of the configuration max-disk-usage is 100. However, we discovered that the actual default value of max-disk-usage is 90. The file inspected is ./etc/broker.xml. Thus, the documentation is deemed inaccurate. We have the opinion that severity of this incident is Major because a) the documentation provides an inaccurate piece of information that influences the way we design our mitigation strategies for risks surrounding hardware resources utilization, and b) we don’t necessarily have the bandwidth to review all default configuration values. Inaccurate information may cause failure to provide message brokering services despite mitigation strategies being in place. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMQ-7147) Stale DefaultIOExceptionHandler Thread stuck in while loop
sunil created AMQ-7147:
--
Summary: Stale DefaultIOExceptionHandler Thread stuck in while loop
Key: AMQ-7147
URL: https://issues.apache.org/jira/browse/AMQ-7147
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 5.14.3
Reporter: sunil
Attachments: activemq.log
Hi,
We are currently using activemq version 5.14.3 with Master/Slave/Slave
architecture with JDBC Persistence adapter , LeaseDatabaseLocker and
IoException handler.
Below are the configuration:
Persistence Adapter:
{code:java}
{code}
IoException Handler:
{code:java}
{code}
We had a network patition event on the master node and after it was removed
from the partition eventough it stopped the transports and stopped the broker ,
it failed to exit the JVM .
But the new broker instance came up and it entered in to slave mode which is
good. But when we looked at the logs we saw that every 5 secs:
2019-02-05 16:29:11,098 | INFO | waiting for broker persistence adapter
checkpoint to succeed before restarting transports |
org.apache.activemq.util.DefaultIOExceptionHandler | IOExceptionHandler:
restart transports
When we took the thread dump to see what the ioExceptionHandler thread is hung
at :
{code:java}
"IOExceptionHandler: restart transports@6055" daemon prio=5 tid=0x1d9 nid=NA
sleeping
java.lang.Thread.State: TIMED_WAITING
at java.lang.Thread.sleep(Unknown Source:-1)
at java.lang.Thread.sleep(Unknown Source:-1)
at java.util.concurrent.TimeUnit.sleep(Unknown Source:-1)
at
org.apache.activemq.util.DefaultIOExceptionHandler$1$1.run(DefaultIOExceptionHandler.java:111){code}
It is stuck in the while loop:
{code:java}
while (hasLockOwnership() && isPersistenceAdapterDown()) {
LOG.info("waiting for broker persistence adapter checkpoint to succeed before
restarting transports");
TimeUnit.MILLISECONDS.sleep(resumeCheckSleepPeriod);
}{code}
The broker persistenceAdapter value is null and it fails to exit the while loop
and the thread is hung there.
What is the scenario when the persistence Adapter is set to null? and is it bug
in a code since there is a stale thread running and also reference to the old
brokerInstance which has the persistence Adapter set to null.
Also can anyone clarify why the systemExitOnShutdown didn't kill the JVM when
the stop on broker was initiated due to ExceptionHandler code.
Any Help will be appreciated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2244) checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout
[ https://issues.apache.org/jira/browse/ARTEMIS-2244?focusedWorklogId=194801=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194801 ] ASF GitHub Bot logged work on ARTEMIS-2244: --- Author: ASF GitHub Bot Created on: 05/Feb/19 20:51 Start Date: 05/Feb/19 20:51 Worklog Time Spent: 10m Work Description: asfgit commented on pull request #2533: ARTEMIS-2244 checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout URL: https://github.com/apache/activemq-artemis/pull/2533 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194801) Time Spent: 2h 10m (was: 2h) > checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer > timeout > -- > > Key: ARTEMIS-2244 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2244 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: yuebao >Priority: Major > Attachments: threaddump.txt > > Time Spent: 2h 10m > Remaining Estimate: 0h > > We found server crash becauseof critical analyzer timeout, thread dump can be > seen in attachment. > Suppose that there is a topic t with two subscriber ta and tb. Some messages > were routed to subscriber ta, not to tb. When a consumer that subscribe tb is > created and send ConsumerCredits to server, ServerConsumerImpl will call > promptDelivery method, then forceDelivery() -> messageQueue.deliverAsync() -> > deliverRunner will executed in the pageSubscription's executor(step1), then > checkDepage(step2) -> pageIterator.hasNext(synchronized method) -> next -> > moveNext, moveNext method will iterate through queue until find a matching > message. At this time(step1), DeliverRunner call deliver method -> > checkDepage -> pageIterator.hasNext, this step blocked on CursorIterator > which was locked by step2, then critical analyzer timeout. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2244) checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout
[ https://issues.apache.org/jira/browse/ARTEMIS-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761205#comment-16761205 ] ASF subversion and git services commented on ARTEMIS-2244: -- Commit 4111707c268189ed8d7c96275bc366e207492dee in activemq-artemis's branch refs/heads/2.6.x from yb [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=4111707 ] ARTEMIS-2244 checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout (cherry picked from commit 8799615a136946c39bb49bd4069cff2df0035997) > checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer > timeout > -- > > Key: ARTEMIS-2244 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2244 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: yuebao >Priority: Major > Attachments: threaddump.txt > > Time Spent: 2h 10m > Remaining Estimate: 0h > > We found server crash becauseof critical analyzer timeout, thread dump can be > seen in attachment. > Suppose that there is a topic t with two subscriber ta and tb. Some messages > were routed to subscriber ta, not to tb. When a consumer that subscribe tb is > created and send ConsumerCredits to server, ServerConsumerImpl will call > promptDelivery method, then forceDelivery() -> messageQueue.deliverAsync() -> > deliverRunner will executed in the pageSubscription's executor(step1), then > checkDepage(step2) -> pageIterator.hasNext(synchronized method) -> next -> > moveNext, moveNext method will iterate through queue until find a matching > message. At this time(step1), DeliverRunner call deliver method -> > checkDepage -> pageIterator.hasNext, this step blocked on CursorIterator > which was locked by step2, then critical analyzer timeout. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2244) checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout
[ https://issues.apache.org/jira/browse/ARTEMIS-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761206#comment-16761206 ] ASF subversion and git services commented on ARTEMIS-2244: -- Commit 2a8b29995ff5a54d1caa54cc2e82239d21aecbd3 in activemq-artemis's branch refs/heads/2.6.x from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=2a8b299 ] ARTEMIS-2244 Adding critical check around checkDepage (cherry picked from commit e09ffe14f488efd1013005da9ecc588466dc2905) > checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer > timeout > -- > > Key: ARTEMIS-2244 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2244 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: yuebao >Priority: Major > Attachments: threaddump.txt > > Time Spent: 2h 10m > Remaining Estimate: 0h > > We found server crash becauseof critical analyzer timeout, thread dump can be > seen in attachment. > Suppose that there is a topic t with two subscriber ta and tb. Some messages > were routed to subscriber ta, not to tb. When a consumer that subscribe tb is > created and send ConsumerCredits to server, ServerConsumerImpl will call > promptDelivery method, then forceDelivery() -> messageQueue.deliverAsync() -> > deliverRunner will executed in the pageSubscription's executor(step1), then > checkDepage(step2) -> pageIterator.hasNext(synchronized method) -> next -> > moveNext, moveNext method will iterate through queue until find a matching > message. At this time(step1), DeliverRunner call deliver method -> > checkDepage -> pageIterator.hasNext, this step blocked on CursorIterator > which was locked by step2, then critical analyzer timeout. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2244) checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout
[ https://issues.apache.org/jira/browse/ARTEMIS-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761200#comment-16761200 ] ASF subversion and git services commented on ARTEMIS-2244: -- Commit 8799615a136946c39bb49bd4069cff2df0035997 in activemq-artemis's branch refs/heads/master from yb [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=8799615 ] ARTEMIS-2244 checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout > checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer > timeout > -- > > Key: ARTEMIS-2244 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2244 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: yuebao >Priority: Major > Attachments: threaddump.txt > > Time Spent: 2h > Remaining Estimate: 0h > > We found server crash becauseof critical analyzer timeout, thread dump can be > seen in attachment. > Suppose that there is a topic t with two subscriber ta and tb. Some messages > were routed to subscriber ta, not to tb. When a consumer that subscribe tb is > created and send ConsumerCredits to server, ServerConsumerImpl will call > promptDelivery method, then forceDelivery() -> messageQueue.deliverAsync() -> > deliverRunner will executed in the pageSubscription's executor(step1), then > checkDepage(step2) -> pageIterator.hasNext(synchronized method) -> next -> > moveNext, moveNext method will iterate through queue until find a matching > message. At this time(step1), DeliverRunner call deliver method -> > checkDepage -> pageIterator.hasNext, this step blocked on CursorIterator > which was locked by step2, then critical analyzer timeout. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2244) checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout
[ https://issues.apache.org/jira/browse/ARTEMIS-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761201#comment-16761201 ] ASF subversion and git services commented on ARTEMIS-2244: -- Commit e09ffe14f488efd1013005da9ecc588466dc2905 in activemq-artemis's branch refs/heads/master from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=e09ffe1 ] ARTEMIS-2244 Adding critical check around checkDepage > checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer > timeout > -- > > Key: ARTEMIS-2244 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2244 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: yuebao >Priority: Major > Attachments: threaddump.txt > > Time Spent: 2h > Remaining Estimate: 0h > > We found server crash becauseof critical analyzer timeout, thread dump can be > seen in attachment. > Suppose that there is a topic t with two subscriber ta and tb. Some messages > were routed to subscriber ta, not to tb. When a consumer that subscribe tb is > created and send ConsumerCredits to server, ServerConsumerImpl will call > promptDelivery method, then forceDelivery() -> messageQueue.deliverAsync() -> > deliverRunner will executed in the pageSubscription's executor(step1), then > checkDepage(step2) -> pageIterator.hasNext(synchronized method) -> next -> > moveNext, moveNext method will iterate through queue until find a matching > message. At this time(step1), DeliverRunner call deliver method -> > checkDepage -> pageIterator.hasNext, this step blocked on CursorIterator > which was locked by step2, then critical analyzer timeout. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2244) checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout
[ https://issues.apache.org/jira/browse/ARTEMIS-2244?focusedWorklogId=194789=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194789 ] ASF GitHub Bot logged work on ARTEMIS-2244: --- Author: ASF GitHub Bot Created on: 05/Feb/19 20:03 Start Date: 05/Feb/19 20:03 Worklog Time Spent: 10m Work Description: clebertsuconic commented on issue #2533: ARTEMIS-2244 checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout URL: https://github.com/apache/activemq-artemis/pull/2533#issuecomment-460783133 sorry for my monolog here.. I see the issue... on your case you had getNext moving the cursor while checking... The fix is valid.. Although I would prefer either keep the Critical Analyzer call around the checkDepage... or create a new CriticalAnalyzer check. I will do the later. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194789) Time Spent: 2h (was: 1h 50m) > checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer > timeout > -- > > Key: ARTEMIS-2244 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2244 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: yuebao >Priority: Major > Attachments: threaddump.txt > > Time Spent: 2h > Remaining Estimate: 0h > > We found server crash becauseof critical analyzer timeout, thread dump can be > seen in attachment. > Suppose that there is a topic t with two subscriber ta and tb. Some messages > were routed to subscriber ta, not to tb. When a consumer that subscribe tb is > created and send ConsumerCredits to server, ServerConsumerImpl will call > promptDelivery method, then forceDelivery() -> messageQueue.deliverAsync() -> > deliverRunner will executed in the pageSubscription's executor(step1), then > checkDepage(step2) -> pageIterator.hasNext(synchronized method) -> next -> > moveNext, moveNext method will iterate through queue until find a matching > message. At this time(step1), DeliverRunner call deliver method -> > checkDepage -> pageIterator.hasNext, this step blocked on CursorIterator > which was locked by step2, then critical analyzer timeout. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2244) checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout
[ https://issues.apache.org/jira/browse/ARTEMIS-2244?focusedWorklogId=194787=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194787 ] ASF GitHub Bot logged work on ARTEMIS-2244: --- Author: ASF GitHub Bot Created on: 05/Feb/19 19:58 Start Date: 05/Feb/19 19:58 Worklog Time Spent: 10m Work Description: clebertsuconic commented on issue #2533: ARTEMIS-2244 checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout URL: https://github.com/apache/activemq-artemis/pull/2533#issuecomment-460781468 @CNNJYB what version did you use on this thread dump? 2.6.3 ? I'm not sure the real issue is addressed here??? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194787) Time Spent: 1h 50m (was: 1h 40m) > checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer > timeout > -- > > Key: ARTEMIS-2244 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2244 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: yuebao >Priority: Major > Attachments: threaddump.txt > > Time Spent: 1h 50m > Remaining Estimate: 0h > > We found server crash becauseof critical analyzer timeout, thread dump can be > seen in attachment. > Suppose that there is a topic t with two subscriber ta and tb. Some messages > were routed to subscriber ta, not to tb. When a consumer that subscribe tb is > created and send ConsumerCredits to server, ServerConsumerImpl will call > promptDelivery method, then forceDelivery() -> messageQueue.deliverAsync() -> > deliverRunner will executed in the pageSubscription's executor(step1), then > checkDepage(step2) -> pageIterator.hasNext(synchronized method) -> next -> > moveNext, moveNext method will iterate through queue until find a matching > message. At this time(step1), DeliverRunner call deliver method -> > checkDepage -> pageIterator.hasNext, this step blocked on CursorIterator > which was locked by step2, then critical analyzer timeout. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2244) checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout
[ https://issues.apache.org/jira/browse/ARTEMIS-2244?focusedWorklogId=194777=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194777 ] ASF GitHub Bot logged work on ARTEMIS-2244: --- Author: ASF GitHub Bot Created on: 05/Feb/19 19:46 Start Date: 05/Feb/19 19:46 Worklog Time Spent: 10m Work Description: clebertsuconic commented on issue #2533: ARTEMIS-2244 checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout URL: https://github.com/apache/activemq-artemis/pull/2533#issuecomment-460777363 This is actually nice I thought I wrote the Critical Analyzer in vain and it seems the Critical Analyzer kicked the server after a real dead lock.. !!! This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194777) Time Spent: 1h 40m (was: 1.5h) > checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer > timeout > -- > > Key: ARTEMIS-2244 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2244 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: yuebao >Priority: Major > Attachments: threaddump.txt > > Time Spent: 1h 40m > Remaining Estimate: 0h > > We found server crash becauseof critical analyzer timeout, thread dump can be > seen in attachment. > Suppose that there is a topic t with two subscriber ta and tb. Some messages > were routed to subscriber ta, not to tb. When a consumer that subscribe tb is > created and send ConsumerCredits to server, ServerConsumerImpl will call > promptDelivery method, then forceDelivery() -> messageQueue.deliverAsync() -> > deliverRunner will executed in the pageSubscription's executor(step1), then > checkDepage(step2) -> pageIterator.hasNext(synchronized method) -> next -> > moveNext, moveNext method will iterate through queue until find a matching > message. At this time(step1), DeliverRunner call deliver method -> > checkDepage -> pageIterator.hasNext, this step blocked on CursorIterator > which was locked by step2, then critical analyzer timeout. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2244) checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout
[ https://issues.apache.org/jira/browse/ARTEMIS-2244?focusedWorklogId=194776=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194776 ] ASF GitHub Bot logged work on ARTEMIS-2244: --- Author: ASF GitHub Bot Created on: 05/Feb/19 19:44 Start Date: 05/Feb/19 19:44 Worklog Time Spent: 10m Work Description: clebertsuconic commented on issue #2533: ARTEMIS-2244 checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout URL: https://github.com/apache/activemq-artemis/pull/2533#issuecomment-460776797 Just saw it... it seems that the Critical Analyzer did its job and kicked the server of after a real dead lock? and which you are fixing it here? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194776) Time Spent: 1.5h (was: 1h 20m) > checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer > timeout > -- > > Key: ARTEMIS-2244 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2244 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: yuebao >Priority: Major > Attachments: threaddump.txt > > Time Spent: 1.5h > Remaining Estimate: 0h > > We found server crash becauseof critical analyzer timeout, thread dump can be > seen in attachment. > Suppose that there is a topic t with two subscriber ta and tb. Some messages > were routed to subscriber ta, not to tb. When a consumer that subscribe tb is > created and send ConsumerCredits to server, ServerConsumerImpl will call > promptDelivery method, then forceDelivery() -> messageQueue.deliverAsync() -> > deliverRunner will executed in the pageSubscription's executor(step1), then > checkDepage(step2) -> pageIterator.hasNext(synchronized method) -> next -> > moveNext, moveNext method will iterate through queue until find a matching > message. At this time(step1), DeliverRunner call deliver method -> > checkDepage -> pageIterator.hasNext, this step blocked on CursorIterator > which was locked by step2, then critical analyzer timeout. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2244) checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout
[ https://issues.apache.org/jira/browse/ARTEMIS-2244?focusedWorklogId=194775=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194775 ] ASF GitHub Bot logged work on ARTEMIS-2244: --- Author: ASF GitHub Bot Created on: 05/Feb/19 19:43 Start Date: 05/Feb/19 19:43 Worklog Time Spent: 10m Work Description: clebertsuconic commented on issue #2533: ARTEMIS-2244 checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout URL: https://github.com/apache/activemq-artemis/pull/2533#issuecomment-460776375 do you have a thread dump for when the issue happened? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194775) Time Spent: 1h 20m (was: 1h 10m) > checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer > timeout > -- > > Key: ARTEMIS-2244 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2244 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: yuebao >Priority: Major > Attachments: threaddump.txt > > Time Spent: 1h 20m > Remaining Estimate: 0h > > We found server crash becauseof critical analyzer timeout, thread dump can be > seen in attachment. > Suppose that there is a topic t with two subscriber ta and tb. Some messages > were routed to subscriber ta, not to tb. When a consumer that subscribe tb is > created and send ConsumerCredits to server, ServerConsumerImpl will call > promptDelivery method, then forceDelivery() -> messageQueue.deliverAsync() -> > deliverRunner will executed in the pageSubscription's executor(step1), then > checkDepage(step2) -> pageIterator.hasNext(synchronized method) -> next -> > moveNext, moveNext method will iterate through queue until find a matching > message. At this time(step1), DeliverRunner call deliver method -> > checkDepage -> pageIterator.hasNext, this step blocked on CursorIterator > which was locked by step2, then critical analyzer timeout. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-1058) Jars in web tmp dir locked on Windows
[ https://issues.apache.org/jira/browse/ARTEMIS-1058?focusedWorklogId=194774=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194774 ] ASF GitHub Bot logged work on ARTEMIS-1058: --- Author: ASF GitHub Bot Created on: 05/Feb/19 19:43 Start Date: 05/Feb/19 19:43 Worklog Time Spent: 10m Work Description: clebertsuconic commented on issue #2534: ARTEMIS-1058 Jars in web tmp dir locked on Windows URL: https://github.com/apache/activemq-artemis/pull/2534#issuecomment-460776232 @gaohoward Please check #2537 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194774) Time Spent: 2h (was: 1h 50m) > Jars in web tmp dir locked on Windows > - > > Key: ARTEMIS-1058 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1058 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.5.3 > Environment: Windows >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Minor > Fix For: unscheduled > > Time Spent: 2h > Remaining Estimate: 0h > > The embedded jetty web server's WebAppClassloader holds up webapp's jar files > and does not release them after close. For that reason the web app's temp dir > cannot be cleaned up on Windows. (Other platforms like Linux doesn't prevent > a force delete of files even they are not released). > As long as this behavior exists we need to have a workaround to let > the tmp dir be cleaned up. > It is possible that we use a 'customized' classloader to replace jetty's > WebAppClassloader, in which we manually iterate every JarFile resources > and close them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2245) Implement Docker images
[ https://issues.apache.org/jira/browse/ARTEMIS-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761120#comment-16761120 ] ASF subversion and git services commented on ARTEMIS-2245: -- Commit 02505fc004aafa96708af5987137cefa0af5fa45 in activemq-artemis's branch refs/heads/master from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=02505fc ] ARTEMIS-2245 Moving docker files under artemis-docker and other improvements > Implement Docker images > --- > > Key: ARTEMIS-2245 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2245 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 2.6.4 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 4h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2245) Implement Docker images
[ https://issues.apache.org/jira/browse/ARTEMIS-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761118#comment-16761118 ] ASF subversion and git services commented on ARTEMIS-2245: -- Commit f2a2d6d99fcffccddec411fbff50c655c3ba1dd1 in activemq-artemis's branch refs/heads/master from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=f2a2d6d ] ARTEMIS-2245 Implement Docker images > Implement Docker images > --- > > Key: ARTEMIS-2245 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2245 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 2.6.4 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 4.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2245) Implement Docker images
[ https://issues.apache.org/jira/browse/ARTEMIS-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761119#comment-16761119 ] ASF subversion and git services commented on ARTEMIS-2245: -- Commit 8c89c3584fbd12f6a26de9fdaabab3061c2a6f59 in activemq-artemis's branch refs/heads/master from Francesco Nigro [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=8c89c35 ] ARTEMIS-2245 adding Docker images User guide > Implement Docker images > --- > > Key: ARTEMIS-2245 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2245 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 2.6.4 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 4.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2245) Implement Docker images
[ https://issues.apache.org/jira/browse/ARTEMIS-2245?focusedWorklogId=194746=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194746 ] ASF GitHub Bot logged work on ARTEMIS-2245: --- Author: ASF GitHub Bot Created on: 05/Feb/19 18:57 Start Date: 05/Feb/19 18:57 Worklog Time Spent: 10m Work Description: asfgit commented on pull request #2536: ARTEMIS-2245 Implement Docker images URL: https://github.com/apache/activemq-artemis/pull/2536 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194746) Time Spent: 4h 40m (was: 4.5h) > Implement Docker images > --- > > Key: ARTEMIS-2245 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2245 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 2.6.4 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 4h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2245) Implement Docker images
[ https://issues.apache.org/jira/browse/ARTEMIS-2245?focusedWorklogId=194728=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194728 ] ASF GitHub Bot logged work on ARTEMIS-2245: --- Author: ASF GitHub Bot Created on: 05/Feb/19 18:26 Start Date: 05/Feb/19 18:26 Worklog Time Spent: 10m Work Description: clebertsuconic commented on pull request #2536: ARTEMIS-2245 Implement Docker images URL: https://github.com/apache/activemq-artemis/pull/2536#discussion_r253988781 ## File path: artemis-docker/Dockerfile-centos ## @@ -0,0 +1,71 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. + +# ActiveMQ Artemis + +FROM jboss/base-jdk:8 Review comment: @michaelandrepearce I tried Alpine and it was missing a few dependencies. We can certainly do it.. I would merge this PR now and we (or anyone else) can send a new PR later. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194728) Time Spent: 4.5h (was: 4h 20m) > Implement Docker images > --- > > Key: ARTEMIS-2245 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2245 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 2.6.4 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 4.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2245) Implement Docker images
[ https://issues.apache.org/jira/browse/ARTEMIS-2245?focusedWorklogId=194687=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194687 ] ASF GitHub Bot logged work on ARTEMIS-2245: --- Author: ASF GitHub Bot Created on: 05/Feb/19 17:10 Start Date: 05/Feb/19 17:10 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on pull request #2536: ARTEMIS-2245 Implement Docker images URL: https://github.com/apache/activemq-artemis/pull/2536#discussion_r253959463 ## File path: artemis-docker/Dockerfile-centos ## @@ -0,0 +1,71 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. + +# ActiveMQ Artemis + +FROM jboss/base-jdk:8 Review comment: https://nickjanetakis.com/blog/the-3-biggest-wins-when-using-alpine-as-a-base-docker-image This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194687) Time Spent: 4h 20m (was: 4h 10m) > Implement Docker images > --- > > Key: ARTEMIS-2245 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2245 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 2.6.4 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 4h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2245) Implement Docker images
[ https://issues.apache.org/jira/browse/ARTEMIS-2245?focusedWorklogId=194684=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194684 ] ASF GitHub Bot logged work on ARTEMIS-2245: --- Author: ASF GitHub Bot Created on: 05/Feb/19 17:03 Start Date: 05/Feb/19 17:03 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on pull request #2536: ARTEMIS-2245 Implement Docker images URL: https://github.com/apache/activemq-artemis/pull/2536#discussion_r253956720 ## File path: artemis-docker/Dockerfile-centos ## @@ -0,0 +1,71 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. + +# ActiveMQ Artemis + +FROM jboss/base-jdk:8 Review comment: Any chance for an alpine one too? pretty pretty please. https://github.com/docker-library/openjdk/tree/922344e3283ef2c87cb17cc04ded9cef5e13a1e5/8/jdk/alpine This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194684) Time Spent: 4h 10m (was: 4h) > Implement Docker images > --- > > Key: ARTEMIS-2245 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2245 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 2.6.4 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 4h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2245) Implement Docker images
[ https://issues.apache.org/jira/browse/ARTEMIS-2245?focusedWorklogId=194678=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194678 ] ASF GitHub Bot logged work on ARTEMIS-2245: --- Author: ASF GitHub Bot Created on: 05/Feb/19 16:51 Start Date: 05/Feb/19 16:51 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2536: ARTEMIS-2245 Implement Docker images URL: https://github.com/apache/activemq-artemis/pull/2536#issuecomment-460713074 Another option is to have a dedicated submodule specifically for docker and kubernetes, e.g. like Apache Ignite. https://github.com/apache/ignite/tree/master/docker https://github.com/apache/ignite/tree/master/modules/kubernetes This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194678) Time Spent: 3h 50m (was: 3h 40m) > Implement Docker images > --- > > Key: ARTEMIS-2245 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2245 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 2.6.4 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2245) Implement Docker images
[ https://issues.apache.org/jira/browse/ARTEMIS-2245?focusedWorklogId=194667=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194667 ] ASF GitHub Bot logged work on ARTEMIS-2245: --- Author: ASF GitHub Bot Created on: 05/Feb/19 16:47 Start Date: 05/Feb/19 16:47 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2536: ARTEMIS-2245 Implement Docker images URL: https://github.com/apache/activemq-artemis/pull/2536#issuecomment-460711935 Another option then maybe like what occurs for some other apache projects (e.g. tomcat and httpd, ), is host it under docker-library and maintain it there, as "official" https://github.com/docker-library/tomcat https://github.com/docker-library/httpd just putting options and ideas out there, im +0 where it sits, just looking at options. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194667) Time Spent: 3h 20m (was: 3h 10m) > Implement Docker images > --- > > Key: ARTEMIS-2245 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2245 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 2.6.4 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 3h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2245) Implement Docker images
[ https://issues.apache.org/jira/browse/ARTEMIS-2245?focusedWorklogId=194680=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194680 ] ASF GitHub Bot logged work on ARTEMIS-2245: --- Author: ASF GitHub Bot Created on: 05/Feb/19 16:54 Start Date: 05/Feb/19 16:54 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2536: ARTEMIS-2245 Implement Docker images URL: https://github.com/apache/activemq-artemis/pull/2536#issuecomment-460714818 For me, docker/kubernetes support is becoming quite a defacto, so think it warrants being a bit more top level thing for us to have, than just being some example. Just to iterate I think what @franz1981 has done is really great. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194680) Time Spent: 4h (was: 3h 50m) > Implement Docker images > --- > > Key: ARTEMIS-2245 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2245 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 2.6.4 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 4h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2245) Implement Docker images
[ https://issues.apache.org/jira/browse/ARTEMIS-2245?focusedWorklogId=194665=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194665 ] ASF GitHub Bot logged work on ARTEMIS-2245: --- Author: ASF GitHub Bot Created on: 05/Feb/19 16:47 Start Date: 05/Feb/19 16:47 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2536: ARTEMIS-2245 Implement Docker images URL: https://github.com/apache/activemq-artemis/pull/2536#issuecomment-460711935 Another option then maybe like what occurs for some other apache projects (e.g. tomcat and httpd, ), is host it under docker-library and maintain it there, as "official" https://github.com/docker-library/tomcat https://github.com/docker-library/httpd This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194665) Time Spent: 3h 10m (was: 3h) > Implement Docker images > --- > > Key: ARTEMIS-2245 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2245 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 2.6.4 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 3h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2245) Implement Docker images
[ https://issues.apache.org/jira/browse/ARTEMIS-2245?focusedWorklogId=194669=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194669 ] ASF GitHub Bot logged work on ARTEMIS-2245: --- Author: ASF GitHub Bot Created on: 05/Feb/19 16:47 Start Date: 05/Feb/19 16:47 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2536: ARTEMIS-2245 Implement Docker images URL: https://github.com/apache/activemq-artemis/pull/2536#issuecomment-460711935 Another option then maybe like what occurs for some other apache projects (e.g. tomcat and httpd, ), is host it under docker-library and maintain it there, as "official" https://github.com/docker-library/tomcat https://github.com/docker-library/httpd just putting options and ideas out there, im +0 where it sits, just looking at options, and how others achieve. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194669) Time Spent: 3.5h (was: 3h 20m) > Implement Docker images > --- > > Key: ARTEMIS-2245 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2245 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 2.6.4 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 3.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2244) checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout
[ https://issues.apache.org/jira/browse/ARTEMIS-2244?focusedWorklogId=194663=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194663 ] ASF GitHub Bot logged work on ARTEMIS-2244: --- Author: ASF GitHub Bot Created on: 05/Feb/19 16:43 Start Date: 05/Feb/19 16:43 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2533: ARTEMIS-2244 checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout URL: https://github.com/apache/activemq-artemis/pull/2533#issuecomment-460706195 -1 (and im sorry, feature was added for a very specific requirement, after a number of issues with broker lockups, where simply failing to slave could have saved day), critical analyzer was implemented specifically to pick up locking issues (such as deadlock and live locks), disk and other issues with something not running as performantly as expected), that are on critical path, and if found, kill the broker so it would fail over to slave. Solution should be to remove or improve the locking, or improve performance in this area. (or even increase critical timeout in your system) This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194663) Time Spent: 1h 10m (was: 1h) > checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer > timeout > -- > > Key: ARTEMIS-2244 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2244 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: yuebao >Priority: Major > Attachments: threaddump.txt > > Time Spent: 1h 10m > Remaining Estimate: 0h > > We found server crash becauseof critical analyzer timeout, thread dump can be > seen in attachment. > Suppose that there is a topic t with two subscriber ta and tb. Some messages > were routed to subscriber ta, not to tb. When a consumer that subscribe tb is > created and send ConsumerCredits to server, ServerConsumerImpl will call > promptDelivery method, then forceDelivery() -> messageQueue.deliverAsync() -> > deliverRunner will executed in the pageSubscription's executor(step1), then > checkDepage(step2) -> pageIterator.hasNext(synchronized method) -> next -> > moveNext, moveNext method will iterate through queue until find a matching > message. At this time(step1), DeliverRunner call deliver method -> > checkDepage -> pageIterator.hasNext, this step blocked on CursorIterator > which was locked by step2, then critical analyzer timeout. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2244) checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout
[ https://issues.apache.org/jira/browse/ARTEMIS-2244?focusedWorklogId=194661=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194661 ] ASF GitHub Bot logged work on ARTEMIS-2244: --- Author: ASF GitHub Bot Created on: 05/Feb/19 16:39 Start Date: 05/Feb/19 16:39 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2533: ARTEMIS-2244 checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout URL: https://github.com/apache/activemq-artemis/pull/2533#issuecomment-460706195 -1 (and im sorry, feature was added for a very specific requirement, after a number of issues with broker lockups, where simply failing to slave could have saved day), critical analyzer was implemented specifically to pick up locking issues (such as deadlock and live locks), disk and other issues with something not running as performantly as expected), that are on critical path, and if found, kill the broker so it would fail over to slave. Solution should be to remove or improve the locking, or improve performance in this area. (or even increase critical timeout in your system) This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194661) Time Spent: 1h (was: 50m) > checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer > timeout > -- > > Key: ARTEMIS-2244 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2244 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: yuebao >Priority: Major > Attachments: threaddump.txt > > Time Spent: 1h > Remaining Estimate: 0h > > We found server crash becauseof critical analyzer timeout, thread dump can be > seen in attachment. > Suppose that there is a topic t with two subscriber ta and tb. Some messages > were routed to subscriber ta, not to tb. When a consumer that subscribe tb is > created and send ConsumerCredits to server, ServerConsumerImpl will call > promptDelivery method, then forceDelivery() -> messageQueue.deliverAsync() -> > deliverRunner will executed in the pageSubscription's executor(step1), then > checkDepage(step2) -> pageIterator.hasNext(synchronized method) -> next -> > moveNext, moveNext method will iterate through queue until find a matching > message. At this time(step1), DeliverRunner call deliver method -> > checkDepage -> pageIterator.hasNext, this step blocked on CursorIterator > which was locked by step2, then critical analyzer timeout. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2244) checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout
[ https://issues.apache.org/jira/browse/ARTEMIS-2244?focusedWorklogId=194660=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194660 ] ASF GitHub Bot logged work on ARTEMIS-2244: --- Author: ASF GitHub Bot Created on: 05/Feb/19 16:37 Start Date: 05/Feb/19 16:37 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2533: ARTEMIS-2244 checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout URL: https://github.com/apache/activemq-artemis/pull/2533#issuecomment-460706195 -1 (and im sorry, feature was added for a very specific requirement), but critical analyzer was implemented specifically to pick up locking issues (such as deadlock and live locks), disk and other issues with something not running as performantly as expected), that are on critical path, and if found, kill the broker so it would fail over to slave. Solution should be to remove or improve the locking, or improve performance in this area. (or even increase critical timeout in your system) This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194660) Time Spent: 50m (was: 40m) > checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer > timeout > -- > > Key: ARTEMIS-2244 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2244 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: yuebao >Priority: Major > Attachments: threaddump.txt > > Time Spent: 50m > Remaining Estimate: 0h > > We found server crash becauseof critical analyzer timeout, thread dump can be > seen in attachment. > Suppose that there is a topic t with two subscriber ta and tb. Some messages > were routed to subscriber ta, not to tb. When a consumer that subscribe tb is > created and send ConsumerCredits to server, ServerConsumerImpl will call > promptDelivery method, then forceDelivery() -> messageQueue.deliverAsync() -> > deliverRunner will executed in the pageSubscription's executor(step1), then > checkDepage(step2) -> pageIterator.hasNext(synchronized method) -> next -> > moveNext, moveNext method will iterate through queue until find a matching > message. At this time(step1), DeliverRunner call deliver method -> > checkDepage -> pageIterator.hasNext, this step blocked on CursorIterator > which was locked by step2, then critical analyzer timeout. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2244) checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout
[ https://issues.apache.org/jira/browse/ARTEMIS-2244?focusedWorklogId=194657=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194657 ] ASF GitHub Bot logged work on ARTEMIS-2244: --- Author: ASF GitHub Bot Created on: 05/Feb/19 16:35 Start Date: 05/Feb/19 16:35 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2533: ARTEMIS-2244 checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout URL: https://github.com/apache/activemq-artemis/pull/2533#issuecomment-460706195 -1 (and im sorry, feature was added for a very specific requirement), but critical analyzer was implemented specifically to pick up locking issues (such as deadlock and live locks), disk and other issues deadlocks non performant code), that are on critical path, and if found, kill the broker so it would fail over to slave. Solution should be to remove or improve the locking, or improve performance in this area. (or even increase critical timeout in your system) This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194657) Time Spent: 40m (was: 0.5h) > checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer > timeout > -- > > Key: ARTEMIS-2244 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2244 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: yuebao >Priority: Major > Attachments: threaddump.txt > > Time Spent: 40m > Remaining Estimate: 0h > > We found server crash becauseof critical analyzer timeout, thread dump can be > seen in attachment. > Suppose that there is a topic t with two subscriber ta and tb. Some messages > were routed to subscriber ta, not to tb. When a consumer that subscribe tb is > created and send ConsumerCredits to server, ServerConsumerImpl will call > promptDelivery method, then forceDelivery() -> messageQueue.deliverAsync() -> > deliverRunner will executed in the pageSubscription's executor(step1), then > checkDepage(step2) -> pageIterator.hasNext(synchronized method) -> next -> > moveNext, moveNext method will iterate through queue until find a matching > message. At this time(step1), DeliverRunner call deliver method -> > checkDepage -> pageIterator.hasNext, this step blocked on CursorIterator > which was locked by step2, then critical analyzer timeout. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2244) checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout
[ https://issues.apache.org/jira/browse/ARTEMIS-2244?focusedWorklogId=194652=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194652 ] ASF GitHub Bot logged work on ARTEMIS-2244: --- Author: ASF GitHub Bot Created on: 05/Feb/19 16:34 Start Date: 05/Feb/19 16:34 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2533: ARTEMIS-2244 checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout URL: https://github.com/apache/activemq-artemis/pull/2533#issuecomment-460706195 -1 (and im sorry, feature was added for a very specific requirement), but critical analyzer was implemented specifically to pick up locking issues (such as deadlock and live locks), disk and other issues deadlocks non performant code), that are on critical path. Solution should be to remove or improve the locking. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194652) Time Spent: 0.5h (was: 20m) > checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer > timeout > -- > > Key: ARTEMIS-2244 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2244 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: yuebao >Priority: Major > Attachments: threaddump.txt > > Time Spent: 0.5h > Remaining Estimate: 0h > > We found server crash becauseof critical analyzer timeout, thread dump can be > seen in attachment. > Suppose that there is a topic t with two subscriber ta and tb. Some messages > were routed to subscriber ta, not to tb. When a consumer that subscribe tb is > created and send ConsumerCredits to server, ServerConsumerImpl will call > promptDelivery method, then forceDelivery() -> messageQueue.deliverAsync() -> > deliverRunner will executed in the pageSubscription's executor(step1), then > checkDepage(step2) -> pageIterator.hasNext(synchronized method) -> next -> > moveNext, moveNext method will iterate through queue until find a matching > message. At this time(step1), DeliverRunner call deliver method -> > checkDepage -> pageIterator.hasNext, this step blocked on CursorIterator > which was locked by step2, then critical analyzer timeout. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2226) (MQTT)In the cluster,the last consumer connection should close the previous consumer connection
[ https://issues.apache.org/jira/browse/ARTEMIS-2226?focusedWorklogId=194645=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194645 ] ASF GitHub Bot logged work on ARTEMIS-2226: --- Author: ASF GitHub Bot Created on: 05/Feb/19 16:24 Start Date: 05/Feb/19 16:24 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2528: ARTEMIS-2226 last consumer connection should close the previous consu… URL: https://github.com/apache/activemq-artemis/pull/2528#issuecomment-460702843 I am off now for 48 hours (pto). This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194645) Time Spent: 19h 10m (was: 19h) > (MQTT)In the cluster,the last consumer connection should close the previous > consumer connection > --- > > Key: ARTEMIS-2226 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2226 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Shiping Liang >Priority: Major > Time Spent: 19h 10m > Remaining Estimate: 0h > > Multiple consumers using the same clientId in the cluster, the last consumer > connection should close the previous consumer connection! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2244) checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout
[ https://issues.apache.org/jira/browse/ARTEMIS-2244?focusedWorklogId=194649=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194649 ] ASF GitHub Bot logged work on ARTEMIS-2244: --- Author: ASF GitHub Bot Created on: 05/Feb/19 16:32 Start Date: 05/Feb/19 16:32 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2533: ARTEMIS-2244 checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer timeout URL: https://github.com/apache/activemq-artemis/pull/2533#issuecomment-460706195 -1 critical analyzer was implemented specifically to pick up disk and other issues, that are on critical path but not performant. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194649) Time Spent: 20m (was: 10m) > checkDepage method placed outside CRITICAL_DELIVER avoid critical analyzer > timeout > -- > > Key: ARTEMIS-2244 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2244 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: yuebao >Priority: Major > Attachments: threaddump.txt > > Time Spent: 20m > Remaining Estimate: 0h > > We found server crash becauseof critical analyzer timeout, thread dump can be > seen in attachment. > Suppose that there is a topic t with two subscriber ta and tb. Some messages > were routed to subscriber ta, not to tb. When a consumer that subscribe tb is > created and send ConsumerCredits to server, ServerConsumerImpl will call > promptDelivery method, then forceDelivery() -> messageQueue.deliverAsync() -> > deliverRunner will executed in the pageSubscription's executor(step1), then > checkDepage(step2) -> pageIterator.hasNext(synchronized method) -> next -> > moveNext, moveNext method will iterate through queue until find a matching > message. At this time(step1), DeliverRunner call deliver method -> > checkDepage -> pageIterator.hasNext, this step blocked on CursorIterator > which was locked by step2, then critical analyzer timeout. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2226) (MQTT)In the cluster,the last consumer connection should close the previous consumer connection
[ https://issues.apache.org/jira/browse/ARTEMIS-2226?focusedWorklogId=194644=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194644 ] ASF GitHub Bot logged work on ARTEMIS-2226: --- Author: ASF GitHub Bot Created on: 05/Feb/19 16:22 Start Date: 05/Feb/19 16:22 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2528: ARTEMIS-2226 last consumer connection should close the previous consu… URL: https://github.com/apache/activemq-artemis/pull/2528#issuecomment-460700605 First of all mqtt connect = create session in core. I dont want to introduce anything thats protocol specific. Nor introduce something that is already represented. Im happy with current create session being a top level supported notification as this is agnostic and will cause little extra traffic compared with create consumer which already is. And im happy with extra data being added to this notification. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194644) Time Spent: 19h (was: 18h 50m) > (MQTT)In the cluster,the last consumer connection should close the previous > consumer connection > --- > > Key: ARTEMIS-2226 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2226 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Shiping Liang >Priority: Major > Time Spent: 19h > Remaining Estimate: 0h > > Multiple consumers using the same clientId in the cluster, the last consumer > connection should close the previous consumer connection! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2226) (MQTT)In the cluster,the last consumer connection should close the previous consumer connection
[ https://issues.apache.org/jira/browse/ARTEMIS-2226?focusedWorklogId=194647=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194647 ] ASF GitHub Bot logged work on ARTEMIS-2226: --- Author: ASF GitHub Bot Created on: 05/Feb/19 16:27 Start Date: 05/Feb/19 16:27 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2528: ARTEMIS-2226 last consumer connection should close the previous consu… URL: https://github.com/apache/activemq-artemis/pull/2528#issuecomment-460700605 First of all mqtt connect = create session in core. I dont want to introduce anything thats protocol specific. Nor introduce something that is already represented. Im happy with current create session being a top level supported notification (eg move it from plugin and have it in session like consumer notification is) as this is agnostic and will cause little extra traffic compared with create consumer which already is. And im happy with extra data being added to this notification. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194647) Time Spent: 19h 20m (was: 19h 10m) > (MQTT)In the cluster,the last consumer connection should close the previous > consumer connection > --- > > Key: ARTEMIS-2226 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2226 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Shiping Liang >Priority: Major > Time Spent: 19h 20m > Remaining Estimate: 0h > > Multiple consumers using the same clientId in the cluster, the last consumer > connection should close the previous consumer connection! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2226) (MQTT)In the cluster,the last consumer connection should close the previous consumer connection
[ https://issues.apache.org/jira/browse/ARTEMIS-2226?focusedWorklogId=194643=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194643 ] ASF GitHub Bot logged work on ARTEMIS-2226: --- Author: ASF GitHub Bot Created on: 05/Feb/19 16:19 Start Date: 05/Feb/19 16:19 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2528: ARTEMIS-2226 last consumer connection should close the previous consu… URL: https://github.com/apache/activemq-artemis/pull/2528#issuecomment-460700605 First of all mqtt connect = create session in core. I dont want to introduce anything thats protocol specific. Im happy with current create session being a top level supported notification as this is agnostic and will cause little extra traffic compared with create consumer which already is. And im happy with extra data being added to this notification This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194643) Time Spent: 18h 50m (was: 18h 40m) > (MQTT)In the cluster,the last consumer connection should close the previous > consumer connection > --- > > Key: ARTEMIS-2226 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2226 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Shiping Liang >Priority: Major > Time Spent: 18h 50m > Remaining Estimate: 0h > > Multiple consumers using the same clientId in the cluster, the last consumer > connection should close the previous consumer connection! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2226) (MQTT)In the cluster,the last consumer connection should close the previous consumer connection
[ https://issues.apache.org/jira/browse/ARTEMIS-2226?focusedWorklogId=194642=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194642 ] ASF GitHub Bot logged work on ARTEMIS-2226: --- Author: ASF GitHub Bot Created on: 05/Feb/19 16:18 Start Date: 05/Feb/19 16:18 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2528: ARTEMIS-2226 last consumer connection should close the previous consu… URL: https://github.com/apache/activemq-artemis/pull/2528#issuecomment-460700605 First of all mqtt connect = create session in core. I dont want to introduce anything thats protocol specific. Im happy with current create session being a top level supported notification as this is agnostic and will cause little extra traffic compared with create consumer which already is. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194642) Time Spent: 18h 40m (was: 18.5h) > (MQTT)In the cluster,the last consumer connection should close the previous > consumer connection > --- > > Key: ARTEMIS-2226 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2226 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Shiping Liang >Priority: Major > Time Spent: 18h 40m > Remaining Estimate: 0h > > Multiple consumers using the same clientId in the cluster, the last consumer > connection should close the previous consumer connection! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2245) Implement Docker images
[ https://issues.apache.org/jira/browse/ARTEMIS-2245?focusedWorklogId=194634=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194634 ] ASF GitHub Bot logged work on ARTEMIS-2245: --- Author: ASF GitHub Bot Created on: 05/Feb/19 16:02 Start Date: 05/Feb/19 16:02 Worklog Time Spent: 10m Work Description: clebertsuconic commented on issue #2536: ARTEMIS-2245 Implement Docker images URL: https://github.com/apache/activemq-artemis/pull/2536#issuecomment-460694427 Even if we decided to deploy it as part of apache account, we still need the docker files.. which is this step here. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194634) Time Spent: 3h (was: 2h 50m) > Implement Docker images > --- > > Key: ARTEMIS-2245 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2245 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 2.6.4 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 3h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2226) (MQTT)In the cluster,the last consumer connection should close the previous consumer connection
[ https://issues.apache.org/jira/browse/ARTEMIS-2226?focusedWorklogId=194632=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194632 ] ASF GitHub Bot logged work on ARTEMIS-2226: --- Author: ASF GitHub Bot Created on: 05/Feb/19 16:01 Start Date: 05/Feb/19 16:01 Worklog Time Spent: 10m Work Description: onlyMIT commented on issue #2528: ARTEMIS-2226 last consumer connection should close the previous consu… URL: https://github.com/apache/activemq-artemis/pull/2528#issuecomment-460693569 Now let's solve it step by step. First, we need to determine whether to use the existing notification or add a new notification to handle this logic. as I comment, it seems that the existing notification is not suitable. In the second step, if we use the new notification, we need to determine how to make it more reasonable. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194632) Time Spent: 18.5h (was: 18h 20m) > (MQTT)In the cluster,the last consumer connection should close the previous > consumer connection > --- > > Key: ARTEMIS-2226 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2226 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Shiping Liang >Priority: Major > Time Spent: 18.5h > Remaining Estimate: 0h > > Multiple consumers using the same clientId in the cluster, the last consumer > connection should close the previous consumer connection! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2226) (MQTT)In the cluster,the last consumer connection should close the previous consumer connection
[ https://issues.apache.org/jira/browse/ARTEMIS-2226?focusedWorklogId=194631=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194631 ] ASF GitHub Bot logged work on ARTEMIS-2226: --- Author: ASF GitHub Bot Created on: 05/Feb/19 16:00 Start Date: 05/Feb/19 16:00 Worklog Time Spent: 10m Work Description: onlyMIT commented on issue #2528: ARTEMIS-2226 last consumer connection should close the previous consu… URL: https://github.com/apache/activemq-artemis/pull/2528#issuecomment-460693569 Now let's solve it step by step. First, we need to determine whether to use the existing notification or add a new notification to handle this logic. If I comment, it seems that the existing notification is not suitable. In the second step, if we use the new notification, we need to determine how to make it more reasonable. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194631) Time Spent: 18h 20m (was: 18h 10m) > (MQTT)In the cluster,the last consumer connection should close the previous > consumer connection > --- > > Key: ARTEMIS-2226 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2226 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Shiping Liang >Priority: Major > Time Spent: 18h 20m > Remaining Estimate: 0h > > Multiple consumers using the same clientId in the cluster, the last consumer > connection should close the previous consumer connection! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2226) (MQTT)In the cluster,the last consumer connection should close the previous consumer connection
[ https://issues.apache.org/jira/browse/ARTEMIS-2226?focusedWorklogId=194622=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194622 ] ASF GitHub Bot logged work on ARTEMIS-2226: --- Author: ASF GitHub Bot Created on: 05/Feb/19 15:54 Start Date: 05/Feb/19 15:54 Worklog Time Spent: 10m Work Description: onlyMIT commented on issue #2528: ARTEMIS-2226 last consumer connection should close the previous consu… URL: https://github.com/apache/activemq-artemis/pull/2528#issuecomment-460691058 @michaelandrepearce As described in my comment.Even if use a plugin, we can't use notifications in the plugin like SESSION_CREATED，it can't achieve our goal, modify the SESSION_CREATED filter? I think we need to think carefully, and if we modify their filtering rules, we can't affect the existing logic. We need to conduct comprehensive testing and evaluation.I think the plugin should be where the optional code is placed, and the logic that is must required is not suitable for the plugin. Like the first version I submitted, the logic was placed in CONSUMER_CREATE, the readability was too poor and not exactly matched with the MQTT specification; This version the logic was added by adding CONNECTED_CREATED. It seems that not all protocols are used, and it is not the most Good plan. If you want to use SESSION_CREATED, CONNECTION_CREATED, must force the MQTT protocol to open all plugins? and modify the filter so that the SESSION_CREATED notification can communicate between the clusters. This is the risk of making the original notification rules undefined，and need to modify their filtering rules, I am not sure if modifying the filtering rules will introduce other issues. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194622) Time Spent: 18h 10m (was: 18h) > (MQTT)In the cluster,the last consumer connection should close the previous > consumer connection > --- > > Key: ARTEMIS-2226 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2226 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Shiping Liang >Priority: Major > Time Spent: 18h 10m > Remaining Estimate: 0h > > Multiple consumers using the same clientId in the cluster, the last consumer > connection should close the previous consumer connection! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (AMQ-7080) Keep track of free pages - Update db.free file during checkpoints
[ https://issues.apache.org/jira/browse/AMQ-7080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760958#comment-16760958 ] Alan Protasio edited comment on AMQ-7080 at 2/5/19 3:54 PM: I'm trying to do it here... but every time that think about i find a case where i can break it.. Now I was implementing using HashIndex where FreePageKey is only a Long with a customized hashCode (and so, we would achieve the same goal to "restrict the updates to the pages that have changed" - and also " preallocated block of the first 10 pages or something like that." as the hashIndex preallocate 'binCapacity'); In this solution i was thinking that for instances pages from 1-1000 would have the same hash and so storage in the same Bin (page) inside the HashIndex - so if pages 1-1000 get modified, only the first page of the index would be written). Then I created a pageFile Method to update this index: void updatePageMap(Transaction tx, SequenceSet freeList, SequenceSet allocatedList) That was invoked on Transaction#commit The problem here is the circular self dependency. When I call updatePageMap inside the transaction.commit, i pass the transaction's free and allocated pages. But the "updatePageMap" itself can allocate and write more pages using the same transaction. If updatePageMap allocate one page for instance, the freeList will have a stale data. I cannot also create another transaction to call updatePageMap. As this second transaction itself has to be committed creating another transaction. To make short... If i use the same transaction to update the SequenceSet index, I can have stale data. Transaction.commit -> UpdateIndex with freePages data (this operation can allocate or free pages) -> If the UpdateIndex allocated/freed pages then we need UpdateIndex again. We can try to update the SequenceSet index until it stabilize and stop freeing or allocating page (this seems not right). If i use other transaction to call UpdateIndex, this new transaction will also be committed creating a new transaction. This will happen if i use any index implementation. :( This is the change i was doing. See: [https://github.com/alanprot/activemq/commit/18730a14db2f88d5a2ac8765fa1de50864fd2c4c#diff-1de6e29861ce2a712a3bd575dd25a013R663] [https://github.com/alanprot/activemq/commit/18730a14db2f88d5a2ac8765fa1de50864fd2c4c#diff-b36dac7750d0c2eb9cd7e102704bee77R817] I know you are not comfortable with this change... that's why i'm asking if its not better put it behind a feature flag (config) and came back with the data.free in the clean shutdown (so no change at all if this flag is no enabled). was (Author: alanprot): I'm trying to do it here... but every time that think about i find a case where i can break it.. Now I was implementing using HashIndex where FreePageKey is only a Long with a customized hashCode (and so, we would achieve the same goal to "restrict the updates to the pages that have changed" - and also " preallocated block of the first 10 pages or something like that." as the hashIndex preallocate 'binCapacity'); In this solution i was thinking that for instances pages from 1-1000 would have the same hash and so storage in the same Bin (page) inside the HashIndex - so if pages 1-1000 get modified, only the first page of the index would be written). Then I created a pageFile Method to update this index: void updatePageMap(Transaction tx, SequenceSet freeList, SequenceSet allocatedList) That was invoked on Transaction#commit The problem here is the circular self dependency. When I call updatePageMap inside the transaction.commit, i pass the transaction's free and allocated pages. But the "updatePageMap" itself can allocate and write more pages using the same transaction. If updatePageMap allocate one page for instance, the freeList will have a stale data. I cannot also create another transaction to call updatePageMap. As this second transaction itself has to be committed creating another transaction. To make short... If i use the same transaction to update the SequenceSet index, I can have stale data. Transaction.commit -> UpdateIndex with freePages data (this operation can allocate or free pages) -> If the UpdateIndex allocated/freed pages then we need UpdateIndex again. We can try to update the SequenceSet index until it stabilize and stop freeing or allocating page (this seems not right). If i use other transaction to call UpdateIndex, this new transaction will also be committed creating a new transaction. This will happen if i use any index implementation. :( This is the change i was doing. See: [https://github.com/alanprot/activemq/commit/18730a14db2f88d5a2ac8765fa1de50864fd2c4c#diff-1de6e29861ce2a712a3bd575dd25a013R663]
[jira] [Comment Edited] (AMQ-7080) Keep track of free pages - Update db.free file during checkpoints
[ https://issues.apache.org/jira/browse/AMQ-7080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760958#comment-16760958 ] Alan Protasio edited comment on AMQ-7080 at 2/5/19 3:52 PM: I'm trying to do it here... but every time that think about i find a case where i can break it.. Now I was implementing using HashIndex where FreePageKey is only a Long with a customized hashCode (and so, we would achieve the same goal to "restrict the updates to the pages that have changed" - and also " preallocated block of the first 10 pages or something like that." as the hashIndex preallocate 'binCapacity'); In this solution i was thinking that for instances pages from 1-1000 would have the same hash and so storage in the same Bin (page) inside the HashIndex - so if pages 1-1000 get modified, only the first page of the index would be written). Then I created a pageFile Method to update this index: void updatePageMap(Transaction tx, SequenceSet freeList, SequenceSet allocatedList) That was invoked on Transaction#commit The problem here is the circular self dependency. When I call updatePageMap inside the transaction.commit, i pass the transaction's free and allocated pages. But the "updatePageMap" itself can allocate and write more pages using the same transaction. If updatePageMap allocate one page for instance, the freeList will have a stale data. I cannot also create another transaction to call updatePageMap. As this second transaction itself has to be committed creating another transaction. To make short... If i use the same transaction to update the SequenceSet index, I can have stale data. Transaction.commit -> UpdateIndex with freePages data (this operation can allocate or free pages) -> If the UpdateIndex allocated/freed pages then we need UpdateIndex again. We can try to update the SequenceSet index until it stabilize and stop freeing or allocating page (this seems not right). If i use other transaction to call UpdateIndex, this new transaction will also be committed creating a new transaction. This will happen if i use any index implementation. :( This is the change i was doing. See: [https://github.com/alanprot/activemq/commit/18730a14db2f88d5a2ac8765fa1de50864fd2c4c#diff-1de6e29861ce2a712a3bd575dd25a013R663] [https://github.com/alanprot/activemq/commit/18730a14db2f88d5a2ac8765fa1de50864fd2c4c#diff-b36dac7750d0c2eb9cd7e102704bee77R817] was (Author: alanprot): I'm trying to do it here... but every time that think about i find a case where i can break it.. Now I was implementing using HashIndex where FreePageKey is only a Long with a customized hashCode (and so, we would achieve the same goal to "restrict the updates to the pages that have changed" - and also " preallocated block of the first 10 pages or something like that." as the hashIndex preallocate 'binCapacity'); In this solution i was thinking that for instances pages from 1-1000 would have the same hash and so storage in the same Bin (page) inside the HashIndex - so if pages 1-1000 get modified, only the first page of the index would be written). Then I created a pageFile Method to update this index: void updatePageMap(Transaction tx, SequenceSet freeList, SequenceSet allocatedList) That was invoked on Transaction#commit The problem here is the circular self dependency. When I call updatePageMap inside the transaction.commit, i pass the transaction's free and allocated pages. But the "updatePageMap" itself can allocate and write more pages using the same transaction. If updatePageMap allocate one page for instance, the freeList will have a stale data. I cannot also create another transaction to call updatePageMap. As this second transaction itself has to be committed creating another transaction. To make short... If i use the same transaction to update the SequenceSet index, I can have stale data. Transaction.commit -> UpdateIndex with freePages data (this operation can allocate or free pages) -> If the UpdateIndex allocated/freed pages then we need UpdateIndex again. We can try to update the SequenceSet index until it stabilize and stop freeing or allocating page (this seems not right). If i use other transaction to call UpdateIndex, this new transaction will also be committed creating a new transaction. This is the change i was doing. See: [https://github.com/alanprot/activemq/commit/18730a14db2f88d5a2ac8765fa1de50864fd2c4c#diff-1de6e29861ce2a712a3bd575dd25a013R663] https://github.com/alanprot/activemq/commit/18730a14db2f88d5a2ac8765fa1de50864fd2c4c#diff-b36dac7750d0c2eb9cd7e102704bee77R817 > Keep track of free pages - Update db.free file during checkpoints > - > > Key: AMQ-7080 > URL: https://issues.apache.org/jira/browse/AMQ-7080 > Project:
[jira] [Commented] (AMQ-7080) Keep track of free pages - Update db.free file during checkpoints
[
https://issues.apache.org/jira/browse/AMQ-7080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760958#comment-16760958
]
Alan Protasio commented on AMQ-7080:
I'm trying to do it here... but every time that think about i find a case where
i can break it..
Now I was implementing using HashIndex where FreePageKey
is only a Long with a customized hashCode (and so, we would achieve the same
goal to "restrict the updates to the pages that have changed" - and also "
preallocated block of the first 10 pages or something like that." as the
hashIndex preallocate 'binCapacity'); In this solution i was thinking that for
instances pages from 1-1000 would have the same hash and so storage in the same
Bin (page) inside the HashIndex - so if pages 1-1000 get modified, only the
first page of the index would be written).
Then I created a pageFile Method to update this index:
void updatePageMap(Transaction tx, SequenceSet freeList, SequenceSet
allocatedList)
That was invoked on Transaction#commit
The problem here is the circular self dependency. When I call updatePageMap
inside the transaction.commit, i pass the transaction's free and allocated
pages. But the "updatePageMap" itself can allocate and write more pages using
the same transaction. If updatePageMap allocate one page for instance, the
freeList will have a stale data.
I cannot also create another transaction to call updatePageMap. As this second
transaction itself has to be committed creating another transaction.
To make short...
If i use the same transaction to update the SequenceSet index, I can have stale
data.
Transaction.commit -> UpdateIndex with freePages data (this operation can
allocate or free pages) -> If the UpdateIndex allocated/freed pages then we
need UpdateIndex again.
We can try to update the SequenceSet index until it stabilize and stop freeing
or allocating page (this seems not right).
If i use other transaction to call UpdateIndex, this new transaction will also
be committed creating a new transaction.
This is the change i was doing. See:
[https://github.com/alanprot/activemq/commit/18730a14db2f88d5a2ac8765fa1de50864fd2c4c#diff-1de6e29861ce2a712a3bd575dd25a013R663]
https://github.com/alanprot/activemq/commit/18730a14db2f88d5a2ac8765fa1de50864fd2c4c#diff-b36dac7750d0c2eb9cd7e102704bee77R817
> Keep track of free pages - Update db.free file during checkpoints
> -
>
> Key: AMQ-7080
> URL: https://issues.apache.org/jira/browse/AMQ-7080
> Project: ActiveMQ
> Issue Type: Improvement
> Components: KahaDB
>Affects Versions: 5.15.6
>Reporter: Alan Protasio
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0
>
> Attachments: AMQ-7080-freeList-update.diff
>
>
> In a event of an unclean shutdown, Activemq loses the information about the
> free pages in the index. In order to recover this information, ActiveMQ read
> the whole index during shutdown searching for free pages and then save the
> db.free file. This operation can take a long time, making the failover
> slower. (during the shutdown, activemq will still hold the lock).
> From http://activemq.apache.org/shared-file-system-master-slave.html
> {quote}"If you have a SAN or shared file system it can be used to provide
> high availability such that if a broker is killed, another broker can take
> over immediately."
> {quote}
> Is important to note if the shutdown takes more than ACTIVEMQ_KILL_MAXSECONDS
> seconds, any following shutdown will be unclean. This broker will stay in
> this state unless the index is deleted (this state means that every failover
> will take more then ACTIVEMQ_KILL_MAXSECONDS, so, if you increase this time
> to 5 minutes, you fail over can take more than 5 minutes).
>
> In order to prevent ActiveMQ reading the whole index file to search for free
> pages, we can keep track of those on every Checkpoint. In order to do that we
> need to be sure that db.data and db.free are in sync. To achieve that we can
> have a attribute in the db.free page that is referenced by the db.data.
> So during the checkpoint we have:
> 1 - Save db.free and give a freePageUniqueId
> 2 - Save this freePageUniqueId in the db.data (metadata)
> In a crash, we can see if the db.data has the same freePageUniqueId as the
> db.free. If this is the case we can safely use the free page information
> contained in the db.free
> Now, the only way to read the whole index file again is IF the crash happens
> btw step 1 and 2 (what is very unlikely).
> The drawback of this implementation is that we will have to save db.free
> during the checkpoint, what can possibly increase the checkpoint time.
> Is also important to note that we CAN (and should) have stale data in db.free
> as it
[jira] [Work logged] (ARTEMIS-2226) (MQTT)In the cluster,the last consumer connection should close the previous consumer connection
[ https://issues.apache.org/jira/browse/ARTEMIS-2226?focusedWorklogId=194584=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194584 ] ASF GitHub Bot logged work on ARTEMIS-2226: --- Author: ASF GitHub Bot Created on: 05/Feb/19 15:27 Start Date: 05/Feb/19 15:27 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2528: ARTEMIS-2226 last consumer connection should close the previous consu… URL: https://github.com/apache/activemq-artemis/pull/2528#issuecomment-460672007 As ive already said you have two options either make mqtt to ensure plugin is enabled or simply make this notification more perm as like consumer one is. Also in that would be adding that session created is passed through This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194584) Time Spent: 18h (was: 17h 50m) > (MQTT)In the cluster,the last consumer connection should close the previous > consumer connection > --- > > Key: ARTEMIS-2226 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2226 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Shiping Liang >Priority: Major > Time Spent: 18h > Remaining Estimate: 0h > > Multiple consumers using the same clientId in the cluster, the last consumer > connection should close the previous consumer connection! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2245) Implement Docker images
[ https://issues.apache.org/jira/browse/ARTEMIS-2245?focusedWorklogId=194587=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194587 ] ASF GitHub Bot logged work on ARTEMIS-2245: --- Author: ASF GitHub Bot Created on: 05/Feb/19 15:31 Start Date: 05/Feb/19 15:31 Worklog Time Spent: 10m Work Description: clebertsuconic commented on issue #2536: ARTEMIS-2245 Implement Docker images URL: https://github.com/apache/activemq-artemis/pull/2536#issuecomment-460681547 That part is a bit more complex as Apache infra is still in early days for this. What we are trying to do here is to provide the docker files so this could be built anywhere else. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194587) Time Spent: 2h 50m (was: 2h 40m) > Implement Docker images > --- > > Key: ARTEMIS-2245 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2245 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 2.6.4 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2245) Implement Docker images
[ https://issues.apache.org/jira/browse/ARTEMIS-2245?focusedWorklogId=194580=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194580 ] ASF GitHub Bot logged work on ARTEMIS-2245: --- Author: ASF GitHub Bot Created on: 05/Feb/19 15:22 Start Date: 05/Feb/19 15:22 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2536: ARTEMIS-2245 Implement Docker images URL: https://github.com/apache/activemq-artemis/pull/2536#issuecomment-460677515 For me the ultimate would be an image in docker hub, just as we push java artifacts to maven central. Its about making things as easy to consume as possible This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194580) Time Spent: 2h 40m (was: 2.5h) > Implement Docker images > --- > > Key: ARTEMIS-2245 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2245 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 2.6.4 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 2h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2226) (MQTT)In the cluster,the last consumer connection should close the previous consumer connection
[ https://issues.apache.org/jira/browse/ARTEMIS-2226?focusedWorklogId=194576=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194576 ] ASF GitHub Bot logged work on ARTEMIS-2226: --- Author: ASF GitHub Bot Created on: 05/Feb/19 15:08 Start Date: 05/Feb/19 15:08 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2528: ARTEMIS-2226 last consumer connection should close the previous consu… URL: https://github.com/apache/activemq-artemis/pull/2528#issuecomment-460672007 As ive already said you have two options either make mqtt to ensure plugin is enabled or simply make this notification more perm as like consumer one is. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194576) Time Spent: 17h 50m (was: 17h 40m) > (MQTT)In the cluster,the last consumer connection should close the previous > consumer connection > --- > > Key: ARTEMIS-2226 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2226 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Shiping Liang >Priority: Major > Time Spent: 17h 50m > Remaining Estimate: 0h > > Multiple consumers using the same clientId in the cluster, the last consumer > connection should close the previous consumer connection! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2226) (MQTT)In the cluster,the last consumer connection should close the previous consumer connection
[ https://issues.apache.org/jira/browse/ARTEMIS-2226?focusedWorklogId=194575=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194575 ] ASF GitHub Bot logged work on ARTEMIS-2226: --- Author: ASF GitHub Bot Created on: 05/Feb/19 15:07 Start Date: 05/Feb/19 15:07 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2528: ARTEMIS-2226 last consumer connection should close the previous consu… URL: https://github.com/apache/activemq-artemis/pull/2528#issuecomment-460672007 As ive already said you have two options either make mqtt to ensure plugin js enabled or simply make this notification more perm as like consumer one is. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194575) Time Spent: 17h 40m (was: 17.5h) > (MQTT)In the cluster,the last consumer connection should close the previous > consumer connection > --- > > Key: ARTEMIS-2226 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2226 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Shiping Liang >Priority: Major > Time Spent: 17h 40m > Remaining Estimate: 0h > > Multiple consumers using the same clientId in the cluster, the last consumer > connection should close the previous consumer connection! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2226) (MQTT)In the cluster,the last consumer connection should close the previous consumer connection
[
https://issues.apache.org/jira/browse/ARTEMIS-2226?focusedWorklogId=194527=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194527
]
ASF GitHub Bot logged work on ARTEMIS-2226:
---
Author: ASF GitHub Bot
Created on: 05/Feb/19 14:16
Start Date: 05/Feb/19 14:16
Worklog Time Spent: 10m
Work Description: onlyMIT commented on pull request #2528: ARTEMIS-2226
last consumer connection should close the previous consu…
URL: https://github.com/apache/activemq-artemis/pull/2528#discussion_r253880048
##
File path:
artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/management/CoreNotificationType.java
##
@@ -47,7 +47,8 @@
SESSION_CREATED(26),
SESSION_CLOSED(27),
MESSAGE_DELIVERED(28),
- MESSAGE_EXPIRED(29);
+ MESSAGE_EXPIRED(29),
+ CONNECTION_CONNECTED(30);
Review comment:
```
if (hasBrokerSessionPlugins()) {
callBrokerSessionPlugins(plugin -> plugin.afterCreateSession(session));
}
```
SESSION_CREATED will only be sent if BrokerSessionPlugins is turned on in
the configuration file.
Also the notifications of CONNECTION_CREATE and SESSIONTION_CREATE will be
filtered and will not be sent to other nodes in the cluster.You can see
`ClusterConnectionBridge.setupNotificationConsumer()` method, where the
cluster-connection filter is set .
This is why I want to modify the filtering rules, CONNECTION_CREATE,
SESSIONTION_CREATE and other connection-related notifications, only can use the
`ManagementNotificationAddress` address to route messages.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 194527)
Time Spent: 17h 20m (was: 17h 10m)
> (MQTT)In the cluster,the last consumer connection should close the previous
> consumer connection
> ---
>
> Key: ARTEMIS-2226
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2226
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Shiping Liang
>Priority: Major
> Time Spent: 17h 20m
> Remaining Estimate: 0h
>
> Multiple consumers using the same clientId in the cluster, the last consumer
> connection should close the previous consumer connection!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2226) (MQTT)In the cluster,the last consumer connection should close the previous consumer connection
[
https://issues.apache.org/jira/browse/ARTEMIS-2226?focusedWorklogId=194532=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194532
]
ASF GitHub Bot logged work on ARTEMIS-2226:
---
Author: ASF GitHub Bot
Created on: 05/Feb/19 14:22
Start Date: 05/Feb/19 14:22
Worklog Time Spent: 10m
Work Description: onlyMIT commented on pull request #2528: ARTEMIS-2226
last consumer connection should close the previous consu…
URL: https://github.com/apache/activemq-artemis/pull/2528#discussion_r253882381
##
File path:
artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/management/CoreNotificationType.java
##
@@ -47,7 +47,8 @@
SESSION_CREATED(26),
SESSION_CLOSED(27),
MESSAGE_DELIVERED(28),
- MESSAGE_EXPIRED(29);
+ MESSAGE_EXPIRED(29),
+ CONNECTION_CONNECTED(30);
Review comment:
```
private void handleNotificationMessage(ClientMessage message,
CoreNotificationType ntype) throws Exception {
// TODO - optimised this by just passing int in header - but filter
needs to be extended to support IN with
switch (ntype) {
case BINDING_ADDED: {
doBindingAdded(message);
break;
}
case BINDING_REMOVED: {
doBindingRemoved(message);
break;
}
case CONSUMER_CREATED: {
doConsumerCreated(message);
break;
}
case CONSUMER_CLOSED: {
doConsumerClosed(message);
break;
}
case PROPOSAL: {
doProposalReceived(message);
break;
}
case PROPOSAL_RESPONSE: {
doProposalResponseReceived(message);
break;
}
case UNPROPOSAL: {
doUnProposalReceived(message);
break;
}
default: {
throw ActiveMQMessageBundle.BUNDLE.invalidType(ntype);
}
}
}
```
Only these notifications will pass between cluster nodes
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 194532)
Time Spent: 17.5h (was: 17h 20m)
> (MQTT)In the cluster,the last consumer connection should close the previous
> consumer connection
> ---
>
> Key: ARTEMIS-2226
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2226
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Shiping Liang
>Priority: Major
> Time Spent: 17.5h
> Remaining Estimate: 0h
>
> Multiple consumers using the same clientId in the cluster, the last consumer
> connection should close the previous consumer connection!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (AMQ-7080) Keep track of free pages - Update db.free file during checkpoints
[
https://issues.apache.org/jira/browse/AMQ-7080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760790#comment-16760790
]
Alan Protasio edited comment on AMQ-7080 at 2/5/19 1:42 PM:
I see... I did this way to keep it simple with the minimum performance impact.
What is your suggestion? I see some possibilities:
* create a HashIndex.
* update the bit map at the end of the pages (end of the index file)
* write the bit map (or the sequenceSet) in pages (with overflow)
The first solution we will write way more bytes to keep track of the same
information. And also, we will have to read all those bytes during startup.
(key = pageFile and value = true if page is free)
The second solution, everything that we allocate a new page we will have to
write the whole map again.
The third one, we will have to always write the whole bitmap (or sequenceSet)
into pages. I thought that this could cause more performance degradation than
the proposed solution. Remember that with the proposed solution only the bytes
that changed are updated.
The last option that I can think of is create a sequenceset index. This can be
a little better than the first but not a lot in a fragmented pagefile.
Do you have any other idea [~gtully]?
was (Author: alanprot):
I see... I did this way to keep it simple with the minimum performance impact.
What is your suggestion? I see some possibilities:
* create a listindex.
* update the map bit at the end of the pages (end of the index file)
The first solution we will write way more bytes to keep track of the same
information. And also, we will have to read all those bytes during startup.
The second solution, everything that we allocate a new page we will have to
write the whole map again.
The last option that I can think of is create a sequenceset index. This can be
a little better than the first but not a lot in a fragmented pagefile.
Do you have any other idea [~gtully]?
> Keep track of free pages - Update db.free file during checkpoints
> -
>
> Key: AMQ-7080
> URL: https://issues.apache.org/jira/browse/AMQ-7080
> Project: ActiveMQ
> Issue Type: Improvement
> Components: KahaDB
>Affects Versions: 5.15.6
>Reporter: Alan Protasio
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0
>
> Attachments: AMQ-7080-freeList-update.diff
>
>
> In a event of an unclean shutdown, Activemq loses the information about the
> free pages in the index. In order to recover this information, ActiveMQ read
> the whole index during shutdown searching for free pages and then save the
> db.free file. This operation can take a long time, making the failover
> slower. (during the shutdown, activemq will still hold the lock).
> From http://activemq.apache.org/shared-file-system-master-slave.html
> {quote}"If you have a SAN or shared file system it can be used to provide
> high availability such that if a broker is killed, another broker can take
> over immediately."
> {quote}
> Is important to note if the shutdown takes more than ACTIVEMQ_KILL_MAXSECONDS
> seconds, any following shutdown will be unclean. This broker will stay in
> this state unless the index is deleted (this state means that every failover
> will take more then ACTIVEMQ_KILL_MAXSECONDS, so, if you increase this time
> to 5 minutes, you fail over can take more than 5 minutes).
>
> In order to prevent ActiveMQ reading the whole index file to search for free
> pages, we can keep track of those on every Checkpoint. In order to do that we
> need to be sure that db.data and db.free are in sync. To achieve that we can
> have a attribute in the db.free page that is referenced by the db.data.
> So during the checkpoint we have:
> 1 - Save db.free and give a freePageUniqueId
> 2 - Save this freePageUniqueId in the db.data (metadata)
> In a crash, we can see if the db.data has the same freePageUniqueId as the
> db.free. If this is the case we can safely use the free page information
> contained in the db.free
> Now, the only way to read the whole index file again is IF the crash happens
> btw step 1 and 2 (what is very unlikely).
> The drawback of this implementation is that we will have to save db.free
> during the checkpoint, what can possibly increase the checkpoint time.
> Is also important to note that we CAN (and should) have stale data in db.free
> as it is referencing stale db.data:
> Imagine the timeline:
> T0 -> P1, P2 and P3 are free.
> T1 -> Checkpoint
> T2 -> P1 got occupied.
> T3 -> Crash
> In the current scenario after the Pagefile#load the P1 will be free and then
> the replay will mark P1 as occupied or will occupied another page (now that
> the recovery of free pages is done on shutdown)
> This change only make
[jira] [Commented] (AMQ-7080) Keep track of free pages - Update db.free file during checkpoints
[
https://issues.apache.org/jira/browse/AMQ-7080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760809#comment-16760809
]
Gary Tully commented on AMQ-7080:
-
I am only offering thoughts, and thoughts are relatively cheap! I think what
you have looks like a good solution for your use case.
sequenceset index, which is a bad name for a sequenceSet that is persisted to
the page file. That is what I am thinking.
It may be tricky to implement, but when it spans many pages, it should be
possible to restrict the updates to the pages that have changed.
To avoid fragmentation of the sequenceSet pages, maybe it have have a
preallocated block of the first 10 pages or something like that.
It means that typically there will be one additional page write (4k) in any
update that allocated/frees a page.
I guess with a network mounted file, the changed bytes, or bytes written are
the significant thing, even if the local files are updated in blocks.
It may not give you what you need in terms of bandwidth usage.
To do a bitSet on the pageFile and only update the changed bytes, would require
a modified page type, probably a step too far.
If there are subsequent issues with the additional file sync, having another
paged/indexed structure may be the answer.
> Keep track of free pages - Update db.free file during checkpoints
> -
>
> Key: AMQ-7080
> URL: https://issues.apache.org/jira/browse/AMQ-7080
> Project: ActiveMQ
> Issue Type: Improvement
> Components: KahaDB
>Affects Versions: 5.15.6
>Reporter: Alan Protasio
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0
>
> Attachments: AMQ-7080-freeList-update.diff
>
>
> In a event of an unclean shutdown, Activemq loses the information about the
> free pages in the index. In order to recover this information, ActiveMQ read
> the whole index during shutdown searching for free pages and then save the
> db.free file. This operation can take a long time, making the failover
> slower. (during the shutdown, activemq will still hold the lock).
> From http://activemq.apache.org/shared-file-system-master-slave.html
> {quote}"If you have a SAN or shared file system it can be used to provide
> high availability such that if a broker is killed, another broker can take
> over immediately."
> {quote}
> Is important to note if the shutdown takes more than ACTIVEMQ_KILL_MAXSECONDS
> seconds, any following shutdown will be unclean. This broker will stay in
> this state unless the index is deleted (this state means that every failover
> will take more then ACTIVEMQ_KILL_MAXSECONDS, so, if you increase this time
> to 5 minutes, you fail over can take more than 5 minutes).
>
> In order to prevent ActiveMQ reading the whole index file to search for free
> pages, we can keep track of those on every Checkpoint. In order to do that we
> need to be sure that db.data and db.free are in sync. To achieve that we can
> have a attribute in the db.free page that is referenced by the db.data.
> So during the checkpoint we have:
> 1 - Save db.free and give a freePageUniqueId
> 2 - Save this freePageUniqueId in the db.data (metadata)
> In a crash, we can see if the db.data has the same freePageUniqueId as the
> db.free. If this is the case we can safely use the free page information
> contained in the db.free
> Now, the only way to read the whole index file again is IF the crash happens
> btw step 1 and 2 (what is very unlikely).
> The drawback of this implementation is that we will have to save db.free
> during the checkpoint, what can possibly increase the checkpoint time.
> Is also important to note that we CAN (and should) have stale data in db.free
> as it is referencing stale db.data:
> Imagine the timeline:
> T0 -> P1, P2 and P3 are free.
> T1 -> Checkpoint
> T2 -> P1 got occupied.
> T3 -> Crash
> In the current scenario after the Pagefile#load the P1 will be free and then
> the replay will mark P1 as occupied or will occupied another page (now that
> the recovery of free pages is done on shutdown)
> This change only make sure that db.data and db.free are in sync and showing
> the reality in T1 (checkpoint), If they are in sync we can trust the db.free.
> This is a really fast draft of what i'm suggesting... If you guys agree, i
> can create the proper patch after:
> [https://github.com/alanprot/activemq/commit/18036ef7214ef0eaa25c8650f40644dd8b4632a5]
>
> This is related to https://issues.apache.org/jira/browse/AMQ-6590
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (AMQ-7080) Keep track of free pages - Update db.free file during checkpoints
[
https://issues.apache.org/jira/browse/AMQ-7080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760790#comment-16760790
]
Alan Protasio edited comment on AMQ-7080 at 2/5/19 1:20 PM:
I see... I did this way to keep it simple with the minimum performance impact.
What is your suggestion? I see some possibilities:
* create a listindex.
* update the map bit at the end of the pages (end of the index file)
The first solution we will write way more bytes to keep track of the same
information. And also, we will have to read all those bytes during startup.
The second solution, everything that we allocate a new page we will have to
write the whole map again.
The last option that I can think of is create a sequenceset index. This can be
a little better than the first but not a lot in a fragmented pagefile.
Do you have any other ideias [~gtully]?
was (Author: alanprot):
I see... I did this way to keep it simple with the minimum performance impact.
What is your suggestion? I see some possibilities:
* create a listindex.
* update the map bit at the end of the pages (end of the index file)
The first solution we will write way more bytes to keep track of the same
information. And also, we will have to read all those bytes during startup.
The second solution, everything that we allocate a new page we will have to
write the whole map again.
The last option that I can think of is create a sequenceset index. This can be
a little better than the first but not a lot in a fragmented pagefile.
Do you have any other ideias @gtully?
> Keep track of free pages - Update db.free file during checkpoints
> -
>
> Key: AMQ-7080
> URL: https://issues.apache.org/jira/browse/AMQ-7080
> Project: ActiveMQ
> Issue Type: Improvement
> Components: KahaDB
>Affects Versions: 5.15.6
>Reporter: Alan Protasio
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0
>
> Attachments: AMQ-7080-freeList-update.diff
>
>
> In a event of an unclean shutdown, Activemq loses the information about the
> free pages in the index. In order to recover this information, ActiveMQ read
> the whole index during shutdown searching for free pages and then save the
> db.free file. This operation can take a long time, making the failover
> slower. (during the shutdown, activemq will still hold the lock).
> From http://activemq.apache.org/shared-file-system-master-slave.html
> {quote}"If you have a SAN or shared file system it can be used to provide
> high availability such that if a broker is killed, another broker can take
> over immediately."
> {quote}
> Is important to note if the shutdown takes more than ACTIVEMQ_KILL_MAXSECONDS
> seconds, any following shutdown will be unclean. This broker will stay in
> this state unless the index is deleted (this state means that every failover
> will take more then ACTIVEMQ_KILL_MAXSECONDS, so, if you increase this time
> to 5 minutes, you fail over can take more than 5 minutes).
>
> In order to prevent ActiveMQ reading the whole index file to search for free
> pages, we can keep track of those on every Checkpoint. In order to do that we
> need to be sure that db.data and db.free are in sync. To achieve that we can
> have a attribute in the db.free page that is referenced by the db.data.
> So during the checkpoint we have:
> 1 - Save db.free and give a freePageUniqueId
> 2 - Save this freePageUniqueId in the db.data (metadata)
> In a crash, we can see if the db.data has the same freePageUniqueId as the
> db.free. If this is the case we can safely use the free page information
> contained in the db.free
> Now, the only way to read the whole index file again is IF the crash happens
> btw step 1 and 2 (what is very unlikely).
> The drawback of this implementation is that we will have to save db.free
> during the checkpoint, what can possibly increase the checkpoint time.
> Is also important to note that we CAN (and should) have stale data in db.free
> as it is referencing stale db.data:
> Imagine the timeline:
> T0 -> P1, P2 and P3 are free.
> T1 -> Checkpoint
> T2 -> P1 got occupied.
> T3 -> Crash
> In the current scenario after the Pagefile#load the P1 will be free and then
> the replay will mark P1 as occupied or will occupied another page (now that
> the recovery of free pages is done on shutdown)
> This change only make sure that db.data and db.free are in sync and showing
> the reality in T1 (checkpoint), If they are in sync we can trust the db.free.
> This is a really fast draft of what i'm suggesting... If you guys agree, i
> can create the proper patch after:
> [https://github.com/alanprot/activemq/commit/18036ef7214ef0eaa25c8650f40644dd8b4632a5]
>
> This is related to
[jira] [Comment Edited] (AMQ-7080) Keep track of free pages - Update db.free file during checkpoints
[
https://issues.apache.org/jira/browse/AMQ-7080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760790#comment-16760790
]
Alan Protasio edited comment on AMQ-7080 at 2/5/19 1:21 PM:
I see... I did this way to keep it simple with the minimum performance impact.
What is your suggestion? I see some possibilities:
* create a listindex.
* update the map bit at the end of the pages (end of the index file)
The first solution we will write way more bytes to keep track of the same
information. And also, we will have to read all those bytes during startup.
The second solution, everything that we allocate a new page we will have to
write the whole map again.
The last option that I can think of is create a sequenceset index. This can be
a little better than the first but not a lot in a fragmented pagefile.
Do you have any other idea [~gtully]?
was (Author: alanprot):
I see... I did this way to keep it simple with the minimum performance impact.
What is your suggestion? I see some possibilities:
* create a listindex.
* update the map bit at the end of the pages (end of the index file)
The first solution we will write way more bytes to keep track of the same
information. And also, we will have to read all those bytes during startup.
The second solution, everything that we allocate a new page we will have to
write the whole map again.
The last option that I can think of is create a sequenceset index. This can be
a little better than the first but not a lot in a fragmented pagefile.
Do you have any other ideias [~gtully]?
> Keep track of free pages - Update db.free file during checkpoints
> -
>
> Key: AMQ-7080
> URL: https://issues.apache.org/jira/browse/AMQ-7080
> Project: ActiveMQ
> Issue Type: Improvement
> Components: KahaDB
>Affects Versions: 5.15.6
>Reporter: Alan Protasio
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0
>
> Attachments: AMQ-7080-freeList-update.diff
>
>
> In a event of an unclean shutdown, Activemq loses the information about the
> free pages in the index. In order to recover this information, ActiveMQ read
> the whole index during shutdown searching for free pages and then save the
> db.free file. This operation can take a long time, making the failover
> slower. (during the shutdown, activemq will still hold the lock).
> From http://activemq.apache.org/shared-file-system-master-slave.html
> {quote}"If you have a SAN or shared file system it can be used to provide
> high availability such that if a broker is killed, another broker can take
> over immediately."
> {quote}
> Is important to note if the shutdown takes more than ACTIVEMQ_KILL_MAXSECONDS
> seconds, any following shutdown will be unclean. This broker will stay in
> this state unless the index is deleted (this state means that every failover
> will take more then ACTIVEMQ_KILL_MAXSECONDS, so, if you increase this time
> to 5 minutes, you fail over can take more than 5 minutes).
>
> In order to prevent ActiveMQ reading the whole index file to search for free
> pages, we can keep track of those on every Checkpoint. In order to do that we
> need to be sure that db.data and db.free are in sync. To achieve that we can
> have a attribute in the db.free page that is referenced by the db.data.
> So during the checkpoint we have:
> 1 - Save db.free and give a freePageUniqueId
> 2 - Save this freePageUniqueId in the db.data (metadata)
> In a crash, we can see if the db.data has the same freePageUniqueId as the
> db.free. If this is the case we can safely use the free page information
> contained in the db.free
> Now, the only way to read the whole index file again is IF the crash happens
> btw step 1 and 2 (what is very unlikely).
> The drawback of this implementation is that we will have to save db.free
> during the checkpoint, what can possibly increase the checkpoint time.
> Is also important to note that we CAN (and should) have stale data in db.free
> as it is referencing stale db.data:
> Imagine the timeline:
> T0 -> P1, P2 and P3 are free.
> T1 -> Checkpoint
> T2 -> P1 got occupied.
> T3 -> Crash
> In the current scenario after the Pagefile#load the P1 will be free and then
> the replay will mark P1 as occupied or will occupied another page (now that
> the recovery of free pages is done on shutdown)
> This change only make sure that db.data and db.free are in sync and showing
> the reality in T1 (checkpoint), If they are in sync we can trust the db.free.
> This is a really fast draft of what i'm suggesting... If you guys agree, i
> can create the proper patch after:
> [https://github.com/alanprot/activemq/commit/18036ef7214ef0eaa25c8650f40644dd8b4632a5]
>
> This is related to
[jira] [Commented] (AMQ-7080) Keep track of free pages - Update db.free file during checkpoints
[
https://issues.apache.org/jira/browse/AMQ-7080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760790#comment-16760790
]
Alan Protasio commented on AMQ-7080:
I see... I did this way to keep it simple with the minimum performance impact.
What is your suggestion? I see some possibilities:
* create a listindex.
* update the map bit at the end of the pages (end of the index file)
The first solution we will write way more bytes to keep track of the same
information. And also, we will have to read all those bytes during startup.
The second solution, everything that we allocate a new page we will have to
write the whole map again.
The last option that I can think of is create a sequenceset index. This can be
a little better than the first but not a lot in a fragmented pagefile.
Do you have any other ideias @gtully?
> Keep track of free pages - Update db.free file during checkpoints
> -
>
> Key: AMQ-7080
> URL: https://issues.apache.org/jira/browse/AMQ-7080
> Project: ActiveMQ
> Issue Type: Improvement
> Components: KahaDB
>Affects Versions: 5.15.6
>Reporter: Alan Protasio
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0
>
> Attachments: AMQ-7080-freeList-update.diff
>
>
> In a event of an unclean shutdown, Activemq loses the information about the
> free pages in the index. In order to recover this information, ActiveMQ read
> the whole index during shutdown searching for free pages and then save the
> db.free file. This operation can take a long time, making the failover
> slower. (during the shutdown, activemq will still hold the lock).
> From http://activemq.apache.org/shared-file-system-master-slave.html
> {quote}"If you have a SAN or shared file system it can be used to provide
> high availability such that if a broker is killed, another broker can take
> over immediately."
> {quote}
> Is important to note if the shutdown takes more than ACTIVEMQ_KILL_MAXSECONDS
> seconds, any following shutdown will be unclean. This broker will stay in
> this state unless the index is deleted (this state means that every failover
> will take more then ACTIVEMQ_KILL_MAXSECONDS, so, if you increase this time
> to 5 minutes, you fail over can take more than 5 minutes).
>
> In order to prevent ActiveMQ reading the whole index file to search for free
> pages, we can keep track of those on every Checkpoint. In order to do that we
> need to be sure that db.data and db.free are in sync. To achieve that we can
> have a attribute in the db.free page that is referenced by the db.data.
> So during the checkpoint we have:
> 1 - Save db.free and give a freePageUniqueId
> 2 - Save this freePageUniqueId in the db.data (metadata)
> In a crash, we can see if the db.data has the same freePageUniqueId as the
> db.free. If this is the case we can safely use the free page information
> contained in the db.free
> Now, the only way to read the whole index file again is IF the crash happens
> btw step 1 and 2 (what is very unlikely).
> The drawback of this implementation is that we will have to save db.free
> during the checkpoint, what can possibly increase the checkpoint time.
> Is also important to note that we CAN (and should) have stale data in db.free
> as it is referencing stale db.data:
> Imagine the timeline:
> T0 -> P1, P2 and P3 are free.
> T1 -> Checkpoint
> T2 -> P1 got occupied.
> T3 -> Crash
> In the current scenario after the Pagefile#load the P1 will be free and then
> the replay will mark P1 as occupied or will occupied another page (now that
> the recovery of free pages is done on shutdown)
> This change only make sure that db.data and db.free are in sync and showing
> the reality in T1 (checkpoint), If they are in sync we can trust the db.free.
> This is a really fast draft of what i'm suggesting... If you guys agree, i
> can create the proper patch after:
> [https://github.com/alanprot/activemq/commit/18036ef7214ef0eaa25c8650f40644dd8b4632a5]
>
> This is related to https://issues.apache.org/jira/browse/AMQ-6590
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (AMQ-7146) Support Spring 5 in OSGi
[ https://issues.apache.org/jira/browse/AMQ-7146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved AMQ-7146. -- Resolution: Fixed Fix Version/s: 5.15.9 > Support Spring 5 in OSGi > > > Key: AMQ-7146 > URL: https://issues.apache.org/jira/browse/AMQ-7146 > Project: ActiveMQ > Issue Type: Task > Components: OSGi/Karaf >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 5.15.9 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7146) Support Spring 5 in OSGi
[ https://issues.apache.org/jira/browse/AMQ-7146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760673#comment-16760673 ] ASF subversion and git services commented on AMQ-7146: -- Commit c628357f91c5f4f71b9106b30a43ea86230c6044 in activemq's branch refs/heads/activemq-5.15.x from Guillaume Nodet [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=c628357 ] AMQ-7146 - Support Spring 5 in OSGi > Support Spring 5 in OSGi > > > Key: AMQ-7146 > URL: https://issues.apache.org/jira/browse/AMQ-7146 > Project: ActiveMQ > Issue Type: Task > Components: OSGi/Karaf >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMQ-7146) Support Spring 5 in OSGi
Guillaume Nodet created AMQ-7146: Summary: Support Spring 5 in OSGi Key: AMQ-7146 URL: https://issues.apache.org/jira/browse/AMQ-7146 Project: ActiveMQ Issue Type: Task Components: OSGi/Karaf Reporter: Guillaume Nodet Assignee: Guillaume Nodet -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2245) Implement Docker images
[ https://issues.apache.org/jira/browse/ARTEMIS-2245?focusedWorklogId=194455=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194455 ] ASF GitHub Bot logged work on ARTEMIS-2245: --- Author: ASF GitHub Bot Created on: 05/Feb/19 10:10 Start Date: 05/Feb/19 10:10 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2536: ARTEMIS-2245 Implement Docker images URL: https://github.com/apache/activemq-artemis/pull/2536#issuecomment-460581318 Let me take some time to think about the best approach here: I see that the current PR is very dev-friendly (given that a compiled distribution IS the base to create a running docker image), but I would prefer something more user-friendly and self contained eg that download or receive from an argument the URL/zip to be used to build the image. That would allow the docker file to be self-contained and somehow indipendent from the compiled code... This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194455) Time Spent: 2h 20m (was: 2h 10m) > Implement Docker images > --- > > Key: ARTEMIS-2245 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2245 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 2.6.4 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 2h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (ARTEMIS-2245) Implement Docker images
[ https://issues.apache.org/jira/browse/ARTEMIS-2245?focusedWorklogId=194456=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-194456 ] ASF GitHub Bot logged work on ARTEMIS-2245: --- Author: ASF GitHub Bot Created on: 05/Feb/19 10:10 Start Date: 05/Feb/19 10:10 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2536: ARTEMIS-2245 Implement Docker images URL: https://github.com/apache/activemq-artemis/pull/2536#issuecomment-460581318 Let me take some time to think about the best approach here: I see that the current PR is very dev-friendly (given that a compiled distribution IS what is used to create a running docker image), but I would prefer something more user-friendly and self contained eg that download or receive from an argument the URL/zip to be used to build the image. That would allow the docker file to be self-contained and somehow indipendent from the compiled code... This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 194456) Time Spent: 2.5h (was: 2h 20m) > Implement Docker images > --- > > Key: ARTEMIS-2245 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2245 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 2.6.4 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 2.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7080) Keep track of free pages - Update db.free file during checkpoints
[
https://issues.apache.org/jira/browse/AMQ-7080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760646#comment-16760646
]
Gary Tully commented on AMQ-7080:
-
I don't think it needs a feature flag.
The thought that keeps coming back is that the sequenceSet should be backed by
the pageFile such that free pages are tracked in the same way as active ones,
in a pagefile backed structure. This would ensure that only a single file needs
to be synced. I don't see any upside to having to update two files. But this is
a good step forward for your use case.
> Keep track of free pages - Update db.free file during checkpoints
> -
>
> Key: AMQ-7080
> URL: https://issues.apache.org/jira/browse/AMQ-7080
> Project: ActiveMQ
> Issue Type: Improvement
> Components: KahaDB
>Affects Versions: 5.15.6
>Reporter: Alan Protasio
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0
>
> Attachments: AMQ-7080-freeList-update.diff
>
>
> In a event of an unclean shutdown, Activemq loses the information about the
> free pages in the index. In order to recover this information, ActiveMQ read
> the whole index during shutdown searching for free pages and then save the
> db.free file. This operation can take a long time, making the failover
> slower. (during the shutdown, activemq will still hold the lock).
> From http://activemq.apache.org/shared-file-system-master-slave.html
> {quote}"If you have a SAN or shared file system it can be used to provide
> high availability such that if a broker is killed, another broker can take
> over immediately."
> {quote}
> Is important to note if the shutdown takes more than ACTIVEMQ_KILL_MAXSECONDS
> seconds, any following shutdown will be unclean. This broker will stay in
> this state unless the index is deleted (this state means that every failover
> will take more then ACTIVEMQ_KILL_MAXSECONDS, so, if you increase this time
> to 5 minutes, you fail over can take more than 5 minutes).
>
> In order to prevent ActiveMQ reading the whole index file to search for free
> pages, we can keep track of those on every Checkpoint. In order to do that we
> need to be sure that db.data and db.free are in sync. To achieve that we can
> have a attribute in the db.free page that is referenced by the db.data.
> So during the checkpoint we have:
> 1 - Save db.free and give a freePageUniqueId
> 2 - Save this freePageUniqueId in the db.data (metadata)
> In a crash, we can see if the db.data has the same freePageUniqueId as the
> db.free. If this is the case we can safely use the free page information
> contained in the db.free
> Now, the only way to read the whole index file again is IF the crash happens
> btw step 1 and 2 (what is very unlikely).
> The drawback of this implementation is that we will have to save db.free
> during the checkpoint, what can possibly increase the checkpoint time.
> Is also important to note that we CAN (and should) have stale data in db.free
> as it is referencing stale db.data:
> Imagine the timeline:
> T0 -> P1, P2 and P3 are free.
> T1 -> Checkpoint
> T2 -> P1 got occupied.
> T3 -> Crash
> In the current scenario after the Pagefile#load the P1 will be free and then
> the replay will mark P1 as occupied or will occupied another page (now that
> the recovery of free pages is done on shutdown)
> This change only make sure that db.data and db.free are in sync and showing
> the reality in T1 (checkpoint), If they are in sync we can trust the db.free.
> This is a really fast draft of what i'm suggesting... If you guys agree, i
> can create the proper patch after:
> [https://github.com/alanprot/activemq/commit/18036ef7214ef0eaa25c8650f40644dd8b4632a5]
>
> This is related to https://issues.apache.org/jira/browse/AMQ-6590
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
