[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&focusedCommentId=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&page=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&page=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&page=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&page=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&page=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&focusedCommentId=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&focusedCommentId=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&page=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)