[jira] [Created] (AMQ-9410) Support non-persistent broker configuration with a lease-database-locker
Martin Lichtin created AMQ-9410:
---
Summary: Support non-persistent broker configuration with a
lease-database-locker
Key: AMQ-9410
URL: https://issues.apache.org/jira/browse/AMQ-9410
Project: ActiveMQ
Issue Type: Improvement
Components: Broker
Reporter: Martin Lichtin
Currently it's not possible to configure a broker without persistence, i.e.
{noformat}
{noformat}
and at the same time configure a lease-database-locker to select a Master
broker.
{noformat}
{noformat}
Ideally it should be possible to configure this outside of
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4519) Why can a client connect and see two different session IDs on the console?
[ https://issues.apache.org/jira/browse/ARTEMIS-4519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gongping.zhu reopened ARTEMIS-4519: --- A third-party mqtt client successfully connects to ActiveMQ Artemis. The server generates two sessions, one for regular client operations and the other for internal management operations. Based on your conclusion, I tracked and reviewed the source code and found that the session names used for internal management start with management::, but none of them I saw in the web management console, And there are no sessions starting with management:: on the backend log, what's going on? Can anyone help answer this? > Why can a client connect and see two different session IDs on the console? > -- > > Key: ARTEMIS-4519 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4519 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: MQTT >Affects Versions: 2.31.2 >Reporter: gongping.zhu >Priority: Major > Attachments: image-2023-11-30-11-00-08-171.png > > > Why can a client connect and see two different session IDs on the console? > After a successful client connection, it will call before Create Session > twice, with the same connId but different sessions? > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4519) Why can a client connect and see two different session IDs on the console?
[ https://issues.apache.org/jira/browse/ARTEMIS-4519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17791852#comment-17791852 ] gongping.zhu commented on ARTEMIS-4519: --- thx a lot > Why can a client connect and see two different session IDs on the console? > -- > > Key: ARTEMIS-4519 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4519 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: MQTT >Affects Versions: 2.31.2 >Reporter: gongping.zhu >Priority: Major > Attachments: image-2023-11-30-11-00-08-171.png > > > Why can a client connect and see two different session IDs on the console? > After a successful client connection, it will call before Create Session > twice, with the same connId but different sessions? > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4516) Support reloading connectors
[ https://issues.apache.org/jira/browse/ARTEMIS-4516?focusedWorklogId=893287=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-893287 ] ASF GitHub Bot logged work on ARTEMIS-4516: --- Author: ASF GitHub Bot Created on: 30/Nov/23 22:07 Start Date: 30/Nov/23 22:07 Worklog Time Spent: 10m Work Description: jbertram opened a new pull request, #4698: URL: https://github.com/apache/activemq-artemis/pull/4698 (no comment) Issue Time Tracking --- Worklog Id: (was: 893287) Remaining Estimate: 0h Time Spent: 10m > Support reloading connectors > > > Key: ARTEMIS-4516 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4516 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Sascha Dirbach >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > ARTEMIS-3685 allows reloading/creation of bridges on config reload. If > however a bridge is created, which references a new connector, it will not be > started as the connectors are not reloaded/created. > It would be good to support reloading of connectors. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4520) JMSContext.acknowledge() doesn't work if last message received is null
[
https://issues.apache.org/jira/browse/ARTEMIS-4520?focusedWorklogId=893253=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-893253
]
ASF GitHub Bot logged work on ARTEMIS-4520:
---
Author: ASF GitHub Bot
Created on: 30/Nov/23 20:04
Start Date: 30/Nov/23 20:04
Worklog Time Spent: 10m
Work Description: jbertram commented on PR #4696:
URL:
https://github.com/apache/activemq-artemis/pull/4696#issuecomment-1834464848
Test-suite looks good. There were a few unrelated failures that all
succeeded locally when retried.
Issue Time Tracking
---
Worklog Id: (was: 893253)
Time Spent: 0.5h (was: 20m)
> JMSContext.acknowledge() doesn't work if last message received is null
> --
>
> Key: ARTEMIS-4520
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4520
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I've stumbled into an issue with client acknowledge mode when using the JMS
> API. Here's an example:
> {code:java}
> try (var factory = new ActiveMQConnectionFactory(" try (var ctx = factory.createContext("", "",
> JMSContext.CLIENT_ACKNOWLEDGE)) {
> var destination = ctx.createQueue("");
> try (var consumer = ctx.createConsumer(destination)) {
> var message1 = consumer.receive(10); // suppose this
> call returns real message
> var message2 = consumer.receive(10); // suppose this
> call times out, so NULL is returned
> ctx.acknowledge(); // I'm expecting that message1 gets
> acknowledged here, but it's not happening
> /*
> Do something here...
> */
> }
> }
> }{code}
> The reason for ack not working is that the implementation of
> {{JMSConsumer.receive}} stores the latest returned value in
> {{org.apache.activemq.artemis.jms.client.ActiveMQJMSContext}} for future
> usage in its {{acknowledge}} implementation. This happens regardless if the
> value is {{null}} or not. So in case the latest call to receive a message
> returns {{null}} then calling {{JMSContext.acknowledge()}} does nothing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4521) Deleting divert using management API doesn't remove binding from journal
[
https://issues.apache.org/jira/browse/ARTEMIS-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-4521:
Fix Version/s: 2.32.0
> Deleting divert using management API doesn't remove binding from journal
>
>
> Key: ARTEMIS-4521
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4521
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.31.2
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.32.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After a JMX {{createDivert}} followed by a JMX {{destroyDivert}} followed by
> a broker restart the divert is visible again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4521) Deleting divert using management API doesn't remove binding from journal
[
https://issues.apache.org/jira/browse/ARTEMIS-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-4521:
Affects Version/s: 2.31.2
> Deleting divert using management API doesn't remove binding from journal
>
>
> Key: ARTEMIS-4521
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4521
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.31.2
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After a JMX {{createDivert}} followed by a JMX {{destroyDivert}} followed by
> a broker restart the divert is visible again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4521) Deleting divert using management API doesn't remove binding from journal
[
https://issues.apache.org/jira/browse/ARTEMIS-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-4521:
External issue URL:
https://lists.apache.org/thread/xjpjc8vor59d70x5ryrv7q1zk8l02p1b
Description: After a JMX {{createDivert}} followed by a JMX
{{destroyDivert}} followed by a broker restart the divert is visible again.
> Deleting divert using management API doesn't remove binding from journal
>
>
> Key: ARTEMIS-4521
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4521
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After a JMX {{createDivert}} followed by a JMX {{destroyDivert}} followed by
> a broker restart the divert is visible again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4521) Deleting divert using management API doesn't remove binding from journal
[ https://issues.apache.org/jira/browse/ARTEMIS-4521?focusedWorklogId=893242=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-893242 ] ASF GitHub Bot logged work on ARTEMIS-4521: --- Author: ASF GitHub Bot Created on: 30/Nov/23 19:13 Start Date: 30/Nov/23 19:13 Worklog Time Spent: 10m Work Description: jbertram opened a new pull request, #4697: URL: https://github.com/apache/activemq-artemis/pull/4697 (no comment) Issue Time Tracking --- Worklog Id: (was: 893242) Remaining Estimate: 0h Time Spent: 10m > Deleting divert using management API doesn't remove binding from journal > > > Key: ARTEMIS-4521 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4521 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4521) Deleting divert using management API doesn't remove binding from journal
Justin Bertram created ARTEMIS-4521: --- Summary: Deleting divert using management API doesn't remove binding from journal Key: ARTEMIS-4521 URL: https://issues.apache.org/jira/browse/ARTEMIS-4521 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Justin Bertram Assignee: Justin Bertram -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4520) JMSContext.acknowledge() doesn't work if last message received is null
[
https://issues.apache.org/jira/browse/ARTEMIS-4520?focusedWorklogId=893236=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-893236
]
ASF GitHub Bot logged work on ARTEMIS-4520:
---
Author: ASF GitHub Bot
Created on: 30/Nov/23 18:10
Start Date: 30/Nov/23 18:10
Worklog Time Spent: 10m
Work Description: tabish121 commented on PR #4696:
URL:
https://github.com/apache/activemq-artemis/pull/4696#issuecomment-1834302139
This looks good assuming all the current tests still pass
Issue Time Tracking
---
Worklog Id: (was: 893236)
Time Spent: 20m (was: 10m)
> JMSContext.acknowledge() doesn't work if last message received is null
> --
>
> Key: ARTEMIS-4520
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4520
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I've stumbled into an issue with client acknowledge mode when using the JMS
> API. Here's an example:
> {code:java}
> try (var factory = new ActiveMQConnectionFactory(" try (var ctx = factory.createContext("", "",
> JMSContext.CLIENT_ACKNOWLEDGE)) {
> var destination = ctx.createQueue("");
> try (var consumer = ctx.createConsumer(destination)) {
> var message1 = consumer.receive(10); // suppose this
> call returns real message
> var message2 = consumer.receive(10); // suppose this
> call times out, so NULL is returned
> ctx.acknowledge(); // I'm expecting that message1 gets
> acknowledged here, but it's not happening
> /*
> Do something here...
> */
> }
> }
> }{code}
> The reason for ack not working is that the implementation of
> {{JMSConsumer.receive}} stores the latest returned value in
> {{org.apache.activemq.artemis.jms.client.ActiveMQJMSContext}} for future
> usage in its {{acknowledge}} implementation. This happens regardless if the
> value is {{null}} or not. So in case the latest call to receive a message
> returns {{null}} then calling {{JMSContext.acknowledge()}} does nothing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4520) JMSContext.acknowledge() doesn't work if last message received is null
[
https://issues.apache.org/jira/browse/ARTEMIS-4520?focusedWorklogId=893233=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-893233
]
ASF GitHub Bot logged work on ARTEMIS-4520:
---
Author: ASF GitHub Bot
Created on: 30/Nov/23 17:47
Start Date: 30/Nov/23 17:47
Worklog Time Spent: 10m
Work Description: jbertram opened a new pull request, #4696:
URL: https://github.com/apache/activemq-artemis/pull/4696
(no comment)
Issue Time Tracking
---
Worklog Id: (was: 893233)
Remaining Estimate: 0h
Time Spent: 10m
> JMSContext.acknowledge() doesn't work if last message received is null
> --
>
> Key: ARTEMIS-4520
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4520
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I've stumbled into an issue with client acknowledge mode when using the JMS
> API. Here's an example:
> {code:java}
> try (var factory = new ActiveMQConnectionFactory(" try (var ctx = factory.createContext("", "",
> JMSContext.CLIENT_ACKNOWLEDGE)) {
> var destination = ctx.createQueue("");
> try (var consumer = ctx.createConsumer(destination)) {
> var message1 = consumer.receive(10); // suppose this
> call returns real message
> var message2 = consumer.receive(10); // suppose this
> call times out, so NULL is returned
> ctx.acknowledge(); // I'm expecting that message1 gets
> acknowledged here, but it's not happening
> /*
> Do something here...
> */
> }
> }
> }{code}
> The reason for ack not working is that the implementation of
> {{JMSConsumer.receive}} stores the latest returned value in
> {{org.apache.activemq.artemis.jms.client.ActiveMQJMSContext}} for future
> usage in its {{acknowledge}} implementation. This happens regardless if the
> value is {{null}} or not. So in case the latest call to receive a message
> returns {{null}} then calling {{JMSContext.acknowledge()}} does nothing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4520) JMSContext.acknowledge() doesn't work if last message received is null
[
https://issues.apache.org/jira/browse/ARTEMIS-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-4520:
Description:
I've stumbled into an issue with client acknowledge mode when using the JMS
API. Here's an example:
{code:java}
try (var factory = new ActiveMQConnectionFactory("", "",
JMSContext.CLIENT_ACKNOWLEDGE)) {
var destination = ctx.createQueue("");
try (var consumer = ctx.createConsumer(destination)) {
var message1 = consumer.receive(10); // suppose
this call returns real message
var message2 = consumer.receive(10); // suppose
this call times out, so NULL is returned
ctx.acknowledge(); // I'm expecting that message1 gets
acknowledged here, but it's not happening
/*
Do something here
*/
}
}
}{code}
The reason for ack not working is that the implementation of
{{JMSConsumer.receive}} stores the latest returned value in
{{org.apache.activemq.artemis.jms.client.ActiveMQJMSContext}} for future usage
in its {{acknowledge}} implementation. This happens regardless if the value is
{{null}} or not. So in case the latest call to receive a message returns
{{null}} then calling {{JMSContext.acknowledge()}} does nothing.
> JMSContext.acknowledge() doesn't work if last message received is null
> --
>
> Key: ARTEMIS-4520
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4520
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>
> I've stumbled into an issue with client acknowledge mode when using the JMS
> API. Here's an example:
> {code:java}
> try (var factory = new ActiveMQConnectionFactory(" try (var ctx = factory.createContext("", "",
> JMSContext.CLIENT_ACKNOWLEDGE)) {
> var destination = ctx.createQueue("");
> try (var consumer = ctx.createConsumer(destination)) {
> var message1 = consumer.receive(10); // suppose
> this call returns real message
> var message2 = consumer.receive(10); // suppose
> this call times out, so NULL is returned
> ctx.acknowledge(); // I'm expecting that message1 gets
> acknowledged here, but it's not happening
> /*
> Do something here
> */
> }
> }
> }{code}
> The reason for ack not working is that the implementation of
> {{JMSConsumer.receive}} stores the latest returned value in
> {{org.apache.activemq.artemis.jms.client.ActiveMQJMSContext}} for future
> usage in its {{acknowledge}} implementation. This happens regardless if the
> value is {{null}} or not. So in case the latest call to receive a message
> returns {{null}} then calling {{JMSContext.acknowledge()}} does nothing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4520) JMSContext.acknowledge() doesn't work if last message received is null
[
https://issues.apache.org/jira/browse/ARTEMIS-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-4520:
Description:
I've stumbled into an issue with client acknowledge mode when using the JMS
API. Here's an example:
{code:java}
try (var factory = new ActiveMQConnectionFactory("", "",
JMSContext.CLIENT_ACKNOWLEDGE)) {
var destination = ctx.createQueue("");
try (var consumer = ctx.createConsumer(destination)) {
var message1 = consumer.receive(10); // suppose this
call returns real message
var message2 = consumer.receive(10); // suppose this
call times out, so NULL is returned
ctx.acknowledge(); // I'm expecting that message1 gets
acknowledged here, but it's not happening
/*
Do something here...
*/
}
}
}{code}
The reason for ack not working is that the implementation of
{{JMSConsumer.receive}} stores the latest returned value in
{{org.apache.activemq.artemis.jms.client.ActiveMQJMSContext}} for future usage
in its {{acknowledge}} implementation. This happens regardless if the value is
{{null}} or not. So in case the latest call to receive a message returns
{{null}} then calling {{JMSContext.acknowledge()}} does nothing.
was:
I've stumbled into an issue with client acknowledge mode when using the JMS
API. Here's an example:
{code:java}
try (var factory = new ActiveMQConnectionFactory("", "",
JMSContext.CLIENT_ACKNOWLEDGE)) {
var destination = ctx.createQueue("");
try (var consumer = ctx.createConsumer(destination)) {
var message1 = consumer.receive(10); // suppose
this call returns real message
var message2 = consumer.receive(10); // suppose
this call times out, so NULL is returned
ctx.acknowledge(); // I'm expecting that message1 gets
acknowledged here, but it's not happening
/*
Do something here
*/
}
}
}{code}
The reason for ack not working is that the implementation of
{{JMSConsumer.receive}} stores the latest returned value in
{{org.apache.activemq.artemis.jms.client.ActiveMQJMSContext}} for future usage
in its {{acknowledge}} implementation. This happens regardless if the value is
{{null}} or not. So in case the latest call to receive a message returns
{{null}} then calling {{JMSContext.acknowledge()}} does nothing.
> JMSContext.acknowledge() doesn't work if last message received is null
> --
>
> Key: ARTEMIS-4520
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4520
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>
> I've stumbled into an issue with client acknowledge mode when using the JMS
> API. Here's an example:
> {code:java}
> try (var factory = new ActiveMQConnectionFactory(" try (var ctx = factory.createContext("", "",
> JMSContext.CLIENT_ACKNOWLEDGE)) {
> var destination = ctx.createQueue("");
> try (var consumer = ctx.createConsumer(destination)) {
> var message1 = consumer.receive(10); // suppose this
> call returns real message
> var message2 = consumer.receive(10); // suppose this
> call times out, so NULL is returned
> ctx.acknowledge(); // I'm expecting that message1 gets
> acknowledged here, but it's not happening
> /*
> Do something here...
> */
> }
> }
> }{code}
> The reason for ack not working is that the implementation of
> {{JMSConsumer.receive}} stores the latest returned value in
> {{org.apache.activemq.artemis.jms.client.ActiveMQJMSContext}} for future
> usage in its {{acknowledge}} implementation. This happens regardless if the
> value is {{null}} or not. So in case the latest call to receive a message
> returns {{null}} then calling {{JMSContext.acknowledge()}} does nothing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4520) JMSContext.acknowledge() doesn't work if last message received is null
[ https://issues.apache.org/jira/browse/ARTEMIS-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-4520: External issue URL: https://lists.apache.org/thread/xtlb38rmh6o7t84k9mponl1jhpdyonfo > JMSContext.acknowledge() doesn't work if last message received is null > -- > > Key: ARTEMIS-4520 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4520 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4520) JMSContext.acknowledge() doesn't work if last message received is null
Justin Bertram created ARTEMIS-4520: --- Summary: JMSContext.acknowledge() doesn't work if last message received is null Key: ARTEMIS-4520 URL: https://issues.apache.org/jira/browse/ARTEMIS-4520 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Justin Bertram Assignee: Justin Bertram -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4519) Why can a client connect and see two different session IDs on the console?
[ https://issues.apache.org/jira/browse/ARTEMIS-4519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram closed ARTEMIS-4519. --- Resolution: Information Provided In the future please direct questions like this to the [ActiveMQ users mailing list|https://activemq.apache.org/contact]. > Why can a client connect and see two different session IDs on the console? > -- > > Key: ARTEMIS-4519 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4519 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: MQTT >Affects Versions: 2.31.2 >Reporter: gongping.zhu >Priority: Major > Attachments: image-2023-11-30-11-00-08-171.png > > > Why can a client connect and see two different session IDs on the console? > After a successful client connection, it will call before Create Session > twice, with the same connId but different sessions? > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4519) Why can a client connect and see two different session IDs on the console?
[ https://issues.apache.org/jira/browse/ARTEMIS-4519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17791675#comment-17791675 ] Justin Bertram commented on ARTEMIS-4519: - When an MQTT connection is made to the broker there are two core sessions created internally - one used for normal client operations and one used for internal management operations. > Why can a client connect and see two different session IDs on the console? > -- > > Key: ARTEMIS-4519 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4519 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: MQTT >Affects Versions: 2.31.2 >Reporter: gongping.zhu >Priority: Major > Attachments: image-2023-11-30-11-00-08-171.png > > > Why can a client connect and see two different session IDs on the console? > After a successful client connection, it will call before Create Session > twice, with the same connId but different sessions? > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (ARTEMIS-3932) replace addAddressSettings with JSON param
[ https://issues.apache.org/jira/browse/ARTEMIS-3932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic reassigned ARTEMIS-3932: Assignee: Clebert Suconic (was: Justin Bertram) > replace addAddressSettings with JSON param > -- > > Key: ARTEMIS-3932 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3932 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Andy Taylor >Assignee: Clebert Suconic >Priority: Major > Time Spent: 1h 40m > Remaining Estimate: 0h > > Similar to what we did with createQueue deprecate the addAddressSettings in > ServerControl and add a json version -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-3932) replace addAddressSettings with JSON param
[ https://issues.apache.org/jira/browse/ARTEMIS-3932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3932. Resolution: Fixed > replace addAddressSettings with JSON param > -- > > Key: ARTEMIS-3932 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3932 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.31.2 >Reporter: Andy Taylor >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.32.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Similar to what we did with createQueue deprecate the addAddressSettings in > ServerControl and add a json version -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-3932) replace addAddressSettings with JSON param
[ https://issues.apache.org/jira/browse/ARTEMIS-3932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic updated ARTEMIS-3932: - Fix Version/s: 2.32.0 Affects Version/s: 2.31.2 > replace addAddressSettings with JSON param > -- > > Key: ARTEMIS-3932 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3932 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.31.2 >Reporter: Andy Taylor >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.32.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Similar to what we did with createQueue deprecate the addAddressSettings in > ServerControl and add a json version -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4519) Why can a client connect and see two different session IDs on the console?
[ https://issues.apache.org/jira/browse/ARTEMIS-4519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17791417#comment-17791417 ] Justin Bertram edited comment on ARTEMIS-4519 at 11/30/23 2:58 PM: --- when i nomally use ./artemis create /var/www/html/brokers/node3 to create instance;and then use ./artemis run; after zhe broker started,i use zhe third mqtt client to connect zhe broker, and login zhe web admin console,you can see this one connect has two different session !image-2023-11-30-11-00-08-171.png|height=400! was (Author: JIRAUSER293605): when i nomally use ./artemis create /var/www/html/brokers/node3 to create instance;and then use ./artemis run; after zhe broker started,i use zhe third mqtt client to connect zhe broker, and login zhe web admin console,you can see this one connect has two different session !image-2023-11-30-11-00-08-171.png! > Why can a client connect and see two different session IDs on the console? > -- > > Key: ARTEMIS-4519 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4519 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: MQTT >Affects Versions: 2.31.2 >Reporter: gongping.zhu >Priority: Major > Attachments: image-2023-11-30-11-00-08-171.png > > > Why can a client connect and see two different session IDs on the console? > After a successful client connection, it will call before Create Session > twice, with the same connId but different sessions? > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4476) Connection Failure Race Conditions in AMQP and Core
[
https://issues.apache.org/jira/browse/ARTEMIS-4476?focusedWorklogId=893144=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-893144
]
ASF GitHub Bot logged work on ARTEMIS-4476:
---
Author: ASF GitHub Bot
Created on: 30/Nov/23 11:24
Start Date: 30/Nov/23 11:24
Worklog Time Spent: 10m
Work Description: gtully commented on code in PR #4694:
URL: https://github.com/apache/activemq-artemis/pull/4694#discussion_r1410534274
##
artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/OpenWireConnection.java:
##
@@ -761,7 +761,11 @@ public void fail(ActiveMQException me, String message) {
final ThresholdActor localVisibleActor = openWireActor;
if (localVisibleActor != null) {
- localVisibleActor.shutdown(() -> doFail(me, message));
+ localVisibleActor.requestShutdown();
+ }
+
+ if (executor != null) {
+ executor.execute(() -> doFail(me, message));
Review Comment:
I don't follow, the point is to terminate processing of commands and execute
the doFail as the last/next task. The only call to fail should be from the
netty socket handler that sees a socket error, remote close etc. It is the
transport initiating a close on a socket error.
Issue Time Tracking
---
Worklog Id: (was: 893144)
Time Spent: 5h 20m (was: 5h 10m)
> Connection Failure Race Conditions in AMQP and Core
> ---
>
> Key: ARTEMIS-4476
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4476
> Project: ActiveMQ Artemis
> Issue Type: Task
>Reporter: Clebert Suconic
>Assignee: Clebert Suconic
>Priority: Major
> Time Spent: 5h 20m
> Remaining Estimate: 0h
>
> Failure Detection has a possibility to a race condition with the processing
> of the client packets (or frames in the case of AMQP).
> This is because Netty detects the failure and removes the connection objects
> while the packets are still processing things.
> I was not able to reproduce this particular issue, but I have seen a case
> from a memory dump where the consumer was created while the connection was
> already dropped, leaving the consumer isolated without any communication with
> clients.
> That particular case I could see a possibility because of these races.
> I am adding tests to exercise connection failure in stress and I was able to
> reproduce other issues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
