[jira] [Commented] (ARTEMIS-2906) Add lastAckTimestamp to message counter
[ https://issues.apache.org/jira/browse/ARTEMIS-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202392#comment-17202392 ] ASF subversion and git services commented on ARTEMIS-2906: -- Commit 702f3c453be04722a3903415b4d5360cdf8da11e in activemq-artemis's branch refs/heads/master from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=702f3c4 ] ARTEMIS-2906 Fixing test on lastAckTimestamp > Add lastAckTimestamp to message counter > --- > > Key: ARTEMIS-2906 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2906 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2918) JDBC Shared Store should restart broker on lost connection
[ https://issues.apache.org/jira/browse/ARTEMIS-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Nigro updated ARTEMIS-2918: - Summary: JDBC Shared Store should restart broker on lost connection (was: ARTEMIS-2823 JDBC Shared Store should restart broker on lost connection ) > JDBC Shared Store should restart broker on lost connection > --- > > Key: ARTEMIS-2918 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2918 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.15.0 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > > Currently the JDBC journal already provide a periodic lock evaluation both > for live and backup using HA shared store, but the default strategy on > failures is to suicide the broker: a different strategy could be to unify the > behavior seen for the file-based version > (https://issues.apache.org/jira/browse/ARTEMIS-2421) and making use of the > recent changes on https://issues.apache.org/jira/browse/ARTEMIS-2823 using > connection pooling to be more resilient to network glitchs too. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2918) ARTEMIS-2823 JDBC Shared Store should restart broker on lost connection
[ https://issues.apache.org/jira/browse/ARTEMIS-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Nigro updated ARTEMIS-2918: - Summary: ARTEMIS-2823 JDBC Shared Store should restart broker on lost connection (was: ARTEMIS-2823 JDBC Shared Store should try restart broker on lost connection ) > ARTEMIS-2823 JDBC Shared Store should restart broker on lost connection > > > Key: ARTEMIS-2918 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2918 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.15.0 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > > Currently the JDBC journal already provide a periodic lock evaluation both > for live and backup using HA shared store, but the default strategy on > failures is to suicide the broker: a different strategy could be to unify the > behavior seen for the file-based version > (https://issues.apache.org/jira/browse/ARTEMIS-2421) and making use of the > recent changes on https://issues.apache.org/jira/browse/ARTEMIS-2823 using > connection pooling to be more resilient to network glitchs too. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2918) ARTEMIS-2823 JDBC Shared Store should try restart broker on lost connection
[ https://issues.apache.org/jira/browse/ARTEMIS-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Nigro updated ARTEMIS-2918: - Description: Currently the JDBC journal already provide a periodic lock evaluation both for live and backup using HA shared store, but the default strategy on failures is to suicide the broker: a different strategy could be to unify the behavior seen for the file-based version (https://issues.apache.org/jira/browse/ARTEMIS-2421) and making use of the recent changes on https://issues.apache.org/jira/browse/ARTEMIS-2823 using connection pooling to be more resilient to network glitchs too. (was: Currently the JDBC journal already provide a periodic lock evaluation both for live and backup using HA shared store, but the default strategy on failures is to suicide the broker: a different strategy could be to unify the behavior seen for the file-based version (https://issues.apache.org/jira/browse/ARTEMIS-2421) and making use of the recent changes on https://issues.apache.org/jira/browse/ARTEMIS-2823 using connection pooling to be more resilient to network gliches too.) > ARTEMIS-2823 JDBC Shared Store should try restart broker on lost connection > > > Key: ARTEMIS-2918 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2918 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.15.0 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > > Currently the JDBC journal already provide a periodic lock evaluation both > for live and backup using HA shared store, but the default strategy on > failures is to suicide the broker: a different strategy could be to unify the > behavior seen for the file-based version > (https://issues.apache.org/jira/browse/ARTEMIS-2421) and making use of the > recent changes on https://issues.apache.org/jira/browse/ARTEMIS-2823 using > connection pooling to be more resilient to network glitchs too. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2918) ARTEMIS-2823 JDBC Shared Store should try restart broker on lost connection
Francesco Nigro created ARTEMIS-2918: Summary: ARTEMIS-2823 JDBC Shared Store should try restart broker on lost connection Key: ARTEMIS-2918 URL: https://issues.apache.org/jira/browse/ARTEMIS-2918 Project: ActiveMQ Artemis Issue Type: Improvement Components: Broker Affects Versions: 2.15.0 Reporter: Francesco Nigro Assignee: Francesco Nigro Currently the JDBC journal already provide a periodic lock evaluation both for live and backup using HA shared store, but the default strategy on failures is to suicide the broker: a different strategy could be to unify the behavior seen for the file-based version (https://issues.apache.org/jira/browse/ARTEMIS-2421) and making use of the recent changes on https://issues.apache.org/jira/browse/ARTEMIS-2823 using connection pooling to be more resilient to network gliches too. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2823) Improve JDBC connection management
[ https://issues.apache.org/jira/browse/ARTEMIS-2823?focusedWorklogId=491282&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-491282 ] ASF GitHub Bot logged work on ARTEMIS-2823: --- Author: ASF GitHub Bot Created on: 25/Sep/20 15:30 Start Date: 25/Sep/20 15:30 Worklog Time Spent: 10m Work Description: franz1981 commented on a change in pull request #3204: URL: https://github.com/apache/activemq-artemis/pull/3204#discussion_r495066022 ## File path: artemis-server/src/main/java/org/apache/activemq/artemis/core/paging/impl/PagingStoreFactoryDatabase.java ## @@ -106,8 +105,8 @@ public PagingStoreFactoryDatabase(final DatabaseStorageConfiguration dbConf, final ScheduledExecutorService scheduledExecutor, Review comment: I see that `JDBCSequentialFile directoryList` and `JDBCSequentialFileFactoryDriver dbDriver` are not used as data members: can be removed This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 491282) Time Spent: 12h 50m (was: 12h 40m) > Improve JDBC connection management > -- > > Key: ARTEMIS-2823 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2823 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Mikko >Priority: Major > Time Spent: 12h 50m > Remaining Estimate: 0h > > I have a case where the whole clustering reliability and HA must rely on HA > capabilities of clustered database, and running on top of application server > is not an option. > The current JDBC store implementation is rather bare bones on the connection > management side. JDBC driver is used directly with no management layer. At > startup, the broker just opens couple of direct connections to database and > expects them to be available forever. This is something that cannot be > expected in HA production environment. So, similarly to the discussion linked > below, in our case we lose the db connection after one hour, and all the > brokers need to be restared to get new connections: > [http://activemq.2283324.n4.nabble.com/Artemis-does-not-reconnect-to-MySQL-after-connection-timeout-td4751956.html] > > This is something that could be resolved by simply using JDBC4 isValid > checks, but proper connection handling and pooling through datasource would > be preferrable. > I have implemented a solution for this by using DBCP2 datasource. Our test > cluster has been successfully running this forked version since the release > of Artemis 2.13.0. I will prepare of pull request if this is seen to be > something that can be useful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2823) Improve JDBC connection management
[ https://issues.apache.org/jira/browse/ARTEMIS-2823?focusedWorklogId=491280&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-491280 ] ASF GitHub Bot logged work on ARTEMIS-2823: --- Author: ASF GitHub Bot Created on: 25/Sep/20 15:30 Start Date: 25/Sep/20 15:30 Worklog Time Spent: 10m Work Description: franz1981 commented on a change in pull request #3204: URL: https://github.com/apache/activemq-artemis/pull/3204#discussion_r495066022 ## File path: artemis-server/src/main/java/org/apache/activemq/artemis/core/paging/impl/PagingStoreFactoryDatabase.java ## @@ -106,8 +105,8 @@ public PagingStoreFactoryDatabase(final DatabaseStorageConfiguration dbConf, final ScheduledExecutorService scheduledExecutor, Review comment: I see that `JDBCSequentialFile directoryList` and `JDBCSequentialFileFactoryDriver dbDriver` are not used as members: can be removed This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 491280) Time Spent: 12h 40m (was: 12.5h) > Improve JDBC connection management > -- > > Key: ARTEMIS-2823 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2823 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Mikko >Priority: Major > Time Spent: 12h 40m > Remaining Estimate: 0h > > I have a case where the whole clustering reliability and HA must rely on HA > capabilities of clustered database, and running on top of application server > is not an option. > The current JDBC store implementation is rather bare bones on the connection > management side. JDBC driver is used directly with no management layer. At > startup, the broker just opens couple of direct connections to database and > expects them to be available forever. This is something that cannot be > expected in HA production environment. So, similarly to the discussion linked > below, in our case we lose the db connection after one hour, and all the > brokers need to be restared to get new connections: > [http://activemq.2283324.n4.nabble.com/Artemis-does-not-reconnect-to-MySQL-after-connection-timeout-td4751956.html] > > This is something that could be resolved by simply using JDBC4 isValid > checks, but proper connection handling and pooling through datasource would > be preferrable. > I have implemented a solution for this by using DBCP2 datasource. Our test > cluster has been successfully running this forked version since the release > of Artemis 2.13.0. I will prepare of pull request if this is seen to be > something that can be useful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2823) Improve JDBC connection management
[ https://issues.apache.org/jira/browse/ARTEMIS-2823?focusedWorklogId=491279&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-491279 ] ASF GitHub Bot logged work on ARTEMIS-2823: --- Author: ASF GitHub Bot Created on: 25/Sep/20 15:29 Start Date: 25/Sep/20 15:29 Worklog Time Spent: 10m Work Description: franz1981 commented on a change in pull request #3204: URL: https://github.com/apache/activemq-artemis/pull/3204#discussion_r495066022 ## File path: artemis-server/src/main/java/org/apache/activemq/artemis/core/paging/impl/PagingStoreFactoryDatabase.java ## @@ -106,8 +105,8 @@ public PagingStoreFactoryDatabase(final DatabaseStorageConfiguration dbConf, final ScheduledExecutorService scheduledExecutor, Review comment: I see that `JDBCSequentialFile directoryList` and `JDBCSequentialFileFactoryDriver dbDriver` This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 491279) Time Spent: 12.5h (was: 12h 20m) > Improve JDBC connection management > -- > > Key: ARTEMIS-2823 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2823 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Mikko >Priority: Major > Time Spent: 12.5h > Remaining Estimate: 0h > > I have a case where the whole clustering reliability and HA must rely on HA > capabilities of clustered database, and running on top of application server > is not an option. > The current JDBC store implementation is rather bare bones on the connection > management side. JDBC driver is used directly with no management layer. At > startup, the broker just opens couple of direct connections to database and > expects them to be available forever. This is something that cannot be > expected in HA production environment. So, similarly to the discussion linked > below, in our case we lose the db connection after one hour, and all the > brokers need to be restared to get new connections: > [http://activemq.2283324.n4.nabble.com/Artemis-does-not-reconnect-to-MySQL-after-connection-timeout-td4751956.html] > > This is something that could be resolved by simply using JDBC4 isValid > checks, but proper connection handling and pooling through datasource would > be preferrable. > I have implemented a solution for this by using DBCP2 datasource. Our test > cluster has been successfully running this forked version since the release > of Artemis 2.13.0. I will prepare of pull request if this is seen to be > something that can be useful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2823) Improve JDBC connection management
[
https://issues.apache.org/jira/browse/ARTEMIS-2823?focusedWorklogId=491258&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-491258
]
ASF GitHub Bot logged work on ARTEMIS-2823:
---
Author: ASF GitHub Bot
Created on: 25/Sep/20 14:58
Start Date: 25/Sep/20 14:58
Worklog Time Spent: 10m
Work Description: ehsavoie commented on a change in pull request #3204:
URL: https://github.com/apache/activemq-artemis/pull/3204#discussion_r495046446
##
File path:
artemis-jdbc-store/src/main/java/org/apache/activemq/artemis/jdbc/store/sql/PropertySQLProvider.java
##
@@ -362,8 +363,12 @@ public Factory(SQLDialect dialect) {
}
}
- public Factory(DataSource dataSource) {
Review comment:
Can't we keep this method and call this(new JDBCConnectionProvider(ds));
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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: 491258)
Time Spent: 12h 20m (was: 12h 10m)
> Improve JDBC connection management
> --
>
> Key: ARTEMIS-2823
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2823
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker
>Reporter: Mikko
>Priority: Major
> Time Spent: 12h 20m
> Remaining Estimate: 0h
>
> I have a case where the whole clustering reliability and HA must rely on HA
> capabilities of clustered database, and running on top of application server
> is not an option.
> The current JDBC store implementation is rather bare bones on the connection
> management side. JDBC driver is used directly with no management layer. At
> startup, the broker just opens couple of direct connections to database and
> expects them to be available forever. This is something that cannot be
> expected in HA production environment. So, similarly to the discussion linked
> below, in our case we lose the db connection after one hour, and all the
> brokers need to be restared to get new connections:
> [http://activemq.2283324.n4.nabble.com/Artemis-does-not-reconnect-to-MySQL-after-connection-timeout-td4751956.html]
>
> This is something that could be resolved by simply using JDBC4 isValid
> checks, but proper connection handling and pooling through datasource would
> be preferrable.
> I have implemented a solution for this by using DBCP2 datasource. Our test
> cluster has been successfully running this forked version since the release
> of Artemis 2.13.0. I will prepare of pull request if this is seen to be
> something that can be useful.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (AMQ-8032) RuntimeConfigurationPlugin doesn't work with JDK11+
[
https://issues.apache.org/jira/browse/AMQ-8032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202198#comment-17202198
]
Kevin Goerlitz commented on AMQ-8032:
-
Ran into the same issue. Does the workaround work?
> RuntimeConfigurationPlugin doesn't work with JDK11+
> ---
>
> Key: AMQ-8032
> URL: https://issues.apache.org/jira/browse/AMQ-8032
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, Plugin
>Affects Versions: 5.16.0
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.1
>
>
> If the broker configuration contains runtimeConfigurationPlugin like this:
> {code:java}
>
> ...
>
>
>
> ...
> {code}
> the broker doesn't start due to:
> {code:java}
> Caused by: java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
> at
> org.apache.activemq.plugin.RuntimeConfigurationPlugin.installPlugin(RuntimeConfigurationPlugin.java:38)
> at
> org.apache.activemq.broker.BrokerService.addInterceptors(BrokerService.java:2505)
> at
> org.apache.activemq.broker.BrokerService.createBroker(BrokerService.java:2365)
> at
> org.apache.activemq.broker.BrokerService.getBroker(BrokerService.java:1053)
> at
> org.apache.activemq.broker.BrokerService.getAdminConnectionContext(BrokerService.java:2636)
> at
> org.apache.activemq.broker.BrokerService.startVirtualConsumerDestinations(BrokerService.java:2797)
> at
> org.apache.activemq.broker.BrokerService.startDestinations(BrokerService.java:2627)
> at
> org.apache.activemq.broker.BrokerService.doStartBroker(BrokerService.java:747)
> at
> org.apache.activemq.broker.BrokerService.startBroker(BrokerService.java:741)
> at
> org.apache.activemq.broker.BrokerService.start(BrokerService.java:644)
> at
> org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:73)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1748)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1685)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1615)
> ... 27 more
> Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXBException
> at
> java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:471)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:588)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 45 more {code}
> The problem is in the JAXB version in use. A simple workaround is to add JAXB
> (API and Core) in activemq/lib (I'm testing the fix).
> So, it could be just a question of documentation to add JAXB jar in ActiveMQ
> in order to use runtimeConfigurationPlugin.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Deleted] (ARTEMIS-2917) LIGATEMPO : Situs Judi Slot Terbaik dan Terpercaya No 1
[ https://issues.apache.org/jira/browse/ARTEMIS-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram deleted ARTEMIS-2917: > LIGATEMPO : Situs Judi Slot Terbaik dan Terpercaya No 1 > --- > > Key: ARTEMIS-2917 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2917 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: situsdaftarslot >Priority: Major > > LIGATEMPO merupakan situs judi slot terbaik dan terpercaya no 1 yang > menyediakan beragam jenis permainan taruhan. LIGATEMPO juga dikenal sebagai > situs judi online terlengkap yang menyediakan berbagai jenis permainan > taruhan seperti Slot Online, Sportsbook (taruhan bola), Live Casino Online & > Idn Poker. Bagi anda yang senang memainkan slot game online terbaru maka > LIGATEMPO merupakan pilihan yang tepat, karena LIGATEMPO menyediakan ribuan > slot game terpercaya yang biasa anda jumpai di provider terkemuka di dunia. > Bagi anda yang baru memainkan permainan slot, maka anda diwajibkan mendaftar > untuk mendapatkan id permainan bermain. > Klik di sini untuk daftar slot terbaru: ( > [https://situsdaftarslot.net/daftar-slot-online-terbaru|https://situsdaftarslot.net/daftar-slot-online-terbaru/] > ) > Klik di sini: ( [http://139.162.34.71/register] ) > klik di sini: ( [https://form.jotform.com/201795107536457] ) > Di situs judi slot terpercaya LIGATEMPO anda bisa memainkan berbagai > permainan slot yang di sediakan oleh provider terkemuka seperti: Microgaming, > Pragmatic, Realtime Gaming, Habanero, Spadegaming, Isoftbet, Joker123, > Gameplay, Simpleplay, Top Trend Gaming (TTG), Play'nGo, Playtech & CQ9. Situs > agen slot online terbaru juga mendapatkan dukungan dari bank lokal terbesar > di Indonesia seperti BCA, BNI, BRI & Mandiri. Sehingga proses transaksi > setoran dan penarikan di situs slot online terbaik LIGATEMPO sangatlah aman & > cepat, begitu anda tidak perlu takut ketika melakukan transaksi. > Agen slot online terpercaya LIGATEMPO juga menyediakan layanan deposit > melalui Transfer Pulsa, Dana, Gopay & Ovo. Dengan begitu Anda tetap bisa > bermain dan melakukan deposit di agen slot baru LIGATEMPO ketika bank > mengalami gangguan atau offline. Agen judi slot terpercaya LIGATEMPO maka > anda dapat menikmati bonus yang ditawarkan sebagai berikut: > * > Bonus Selamat Datang 20% > * > Bonus Slot Game Rollingan 1% > * > Bonus Rollingan Poker Hingga 0,5% > * > Cashback Sabung Ayam 5% > * > Cashback Sportsbook 5% > * > Cashback Kasino Langsung 5% > Untuk cara [daftar slot terbaru|https://situsdaftarslot.net/] di LIGATEMPO > sangatlah mudah, anda hanya perlu mengis form daftar slot terpercaya pada > link di atas dengan data yang benar & valid. Atau anda bisa juga daftar slot > online terbaik melaui layanan live chat yang tersedia dibawah. Apabila daftar > slot online terbaru Anda berhasil maka Anda akan menerima username dan > password login Anda. Oleh karena sebaiknya anda mengecek line, whatsapp, > wechat, sms dan gmail anda. > Jika butuh bantuan atau pertanyaan silah klik link berikut: ( > [https://tawk.to/chat/5eba38f28ee2956d73a04219/default] ) > > Baca juga : > [http://www.alumni.piksi.ac.id/community/profile/daftar-agen-judi-live-casino-terbaik-terpercaya/] > [http://www.bkkedu.in.th/community/profile/daftar-agen-joker123-terbaik-dan-terpercaya/] > [http://tamalemetro.gov.gh/community/profile/daftar-agen-joker123-terbaik-dan-terpercaya-2020/] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2917) LIGATEMPO : Situs Judi Slot Terbaik dan Terpercaya No 1
situsdaftarslot created ARTEMIS-2917: Summary: LIGATEMPO : Situs Judi Slot Terbaik dan Terpercaya No 1 Key: ARTEMIS-2917 URL: https://issues.apache.org/jira/browse/ARTEMIS-2917 Project: ActiveMQ Artemis Issue Type: Bug Reporter: situsdaftarslot LIGATEMPO merupakan situs judi slot terbaik dan terpercaya no 1 yang menyediakan beragam jenis permainan taruhan. LIGATEMPO juga dikenal sebagai situs judi online terlengkap yang menyediakan berbagai jenis permainan taruhan seperti Slot Online, Sportsbook (taruhan bola), Live Casino Online & Idn Poker. Bagi anda yang senang memainkan slot game online terbaru maka LIGATEMPO merupakan pilihan yang tepat, karena LIGATEMPO menyediakan ribuan slot game terpercaya yang biasa anda jumpai di provider terkemuka di dunia. Bagi anda yang baru memainkan permainan slot, maka anda diwajibkan mendaftar untuk mendapatkan id permainan bermain. Klik di sini untuk daftar slot terbaru: ( [https://situsdaftarslot.net/daftar-slot-online-terbaru|https://situsdaftarslot.net/daftar-slot-online-terbaru/] ) Klik di sini: ( [http://139.162.34.71/register] ) klik di sini: ( [https://form.jotform.com/201795107536457] ) Di situs judi slot terpercaya LIGATEMPO anda bisa memainkan berbagai permainan slot yang di sediakan oleh provider terkemuka seperti: Microgaming, Pragmatic, Realtime Gaming, Habanero, Spadegaming, Isoftbet, Joker123, Gameplay, Simpleplay, Top Trend Gaming (TTG), Play'nGo, Playtech & CQ9. Situs agen slot online terbaru juga mendapatkan dukungan dari bank lokal terbesar di Indonesia seperti BCA, BNI, BRI & Mandiri. Sehingga proses transaksi setoran dan penarikan di situs slot online terbaik LIGATEMPO sangatlah aman & cepat, begitu anda tidak perlu takut ketika melakukan transaksi. Agen slot online terpercaya LIGATEMPO juga menyediakan layanan deposit melalui Transfer Pulsa, Dana, Gopay & Ovo. Dengan begitu Anda tetap bisa bermain dan melakukan deposit di agen slot baru LIGATEMPO ketika bank mengalami gangguan atau offline. Agen judi slot terpercaya LIGATEMPO maka anda dapat menikmati bonus yang ditawarkan sebagai berikut: * Bonus Selamat Datang 20% * Bonus Slot Game Rollingan 1% * Bonus Rollingan Poker Hingga 0,5% * Cashback Sabung Ayam 5% * Cashback Sportsbook 5% * Cashback Kasino Langsung 5% Untuk cara [daftar slot terbaru|https://situsdaftarslot.net/] di LIGATEMPO sangatlah mudah, anda hanya perlu mengis form daftar slot terpercaya pada link di atas dengan data yang benar & valid. Atau anda bisa juga daftar slot online terbaik melaui layanan live chat yang tersedia dibawah. Apabila daftar slot online terbaru Anda berhasil maka Anda akan menerima username dan password login Anda. Oleh karena sebaiknya anda mengecek line, whatsapp, wechat, sms dan gmail anda. Jika butuh bantuan atau pertanyaan silah klik link berikut: ( [https://tawk.to/chat/5eba38f28ee2956d73a04219/default] ) Baca juga : [http://www.alumni.piksi.ac.id/community/profile/daftar-agen-judi-live-casino-terbaik-terpercaya/] [http://www.bkkedu.in.th/community/profile/daftar-agen-joker123-terbaik-dan-terpercaya/] [http://tamalemetro.gov.gh/community/profile/daftar-agen-joker123-terbaik-dan-terpercaya-2020/] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2908) Persist Divert Configuration in Bindings journal
[ https://issues.apache.org/jira/browse/ARTEMIS-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202190#comment-17202190 ] ASF subversion and git services commented on ARTEMIS-2908: -- Commit c77bf50db46de774ba877e1b4fa71a82932070c6 in activemq-artemis's branch refs/heads/master from Andy Taylor [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=c77bf50 ] ARTEMIS-2908 - Persist Divert Configuration in Bindings journal https://issues.apache.org/jira/browse/ARTEMIS-2908 > Persist Divert Configuration in Bindings journal > > > Key: ARTEMIS-2908 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2908 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Andy Taylor >Assignee: Andy Taylor >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2908) Persist Divert Configuration in Bindings journal
[ https://issues.apache.org/jira/browse/ARTEMIS-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202191#comment-17202191 ] ASF subversion and git services commented on ARTEMIS-2908: -- Commit c77bf50db46de774ba877e1b4fa71a82932070c6 in activemq-artemis's branch refs/heads/master from Andy Taylor [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=c77bf50 ] ARTEMIS-2908 - Persist Divert Configuration in Bindings journal https://issues.apache.org/jira/browse/ARTEMIS-2908 > Persist Divert Configuration in Bindings journal > > > Key: ARTEMIS-2908 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2908 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Andy Taylor >Assignee: Andy Taylor >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2908) Persist Divert Configuration in Bindings journal
[ https://issues.apache.org/jira/browse/ARTEMIS-2908?focusedWorklogId=491233&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-491233 ] ASF GitHub Bot logged work on ARTEMIS-2908: --- Author: ASF GitHub Bot Created on: 25/Sep/20 14:04 Start Date: 25/Sep/20 14:04 Worklog Time Spent: 10m Work Description: asfgit closed pull request #3278: URL: https://github.com/apache/activemq-artemis/pull/3278 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 491233) Time Spent: 1h 40m (was: 1.5h) > Persist Divert Configuration in Bindings journal > > > Key: ARTEMIS-2908 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2908 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Andy Taylor >Assignee: Andy Taylor >Priority: Major > Time Spent: 1h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2823) Improve JDBC connection management
[ https://issues.apache.org/jira/browse/ARTEMIS-2823?focusedWorklogId=491232&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-491232 ] ASF GitHub Bot logged work on ARTEMIS-2823: --- Author: ASF GitHub Bot Created on: 25/Sep/20 14:02 Start Date: 25/Sep/20 14:02 Worklog Time Spent: 10m Work Description: franz1981 commented on pull request #3204: URL: https://github.com/apache/activemq-artemis/pull/3204#issuecomment-698946855 And that makes sense indeed, it won't get changed unless none will request a new one...I know dbcp can do it on a separate thread too that save latency outliers on start up but I prefer this default behaviour. I am more concern about the starvation of lease lock connection due to others; I am sure this need some attention before merging this pr... This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 491232) Time Spent: 12h 10m (was: 12h) > Improve JDBC connection management > -- > > Key: ARTEMIS-2823 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2823 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Mikko >Priority: Major > Time Spent: 12h 10m > Remaining Estimate: 0h > > I have a case where the whole clustering reliability and HA must rely on HA > capabilities of clustered database, and running on top of application server > is not an option. > The current JDBC store implementation is rather bare bones on the connection > management side. JDBC driver is used directly with no management layer. At > startup, the broker just opens couple of direct connections to database and > expects them to be available forever. This is something that cannot be > expected in HA production environment. So, similarly to the discussion linked > below, in our case we lose the db connection after one hour, and all the > brokers need to be restared to get new connections: > [http://activemq.2283324.n4.nabble.com/Artemis-does-not-reconnect-to-MySQL-after-connection-timeout-td4751956.html] > > This is something that could be resolved by simply using JDBC4 isValid > checks, but proper connection handling and pooling through datasource would > be preferrable. > I have implemented a solution for this by using DBCP2 datasource. Our test > cluster has been successfully running this forked version since the release > of Artemis 2.13.0. I will prepare of pull request if this is seen to be > something that can be useful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2823) Improve JDBC connection management
[ https://issues.apache.org/jira/browse/ARTEMIS-2823?focusedWorklogId=491231&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-491231 ] ASF GitHub Bot logged work on ARTEMIS-2823: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:58 Start Date: 25/Sep/20 13:58 Worklog Time Spent: 10m Work Description: uomik commented on pull request #3204: URL: https://github.com/apache/activemq-artemis/pull/3204#issuecomment-698944941 > I don't know what can be the third one... This might be that invalid connection. At least this happened with the other application I once fought with this db server (gradually filling the pool with invalid connections). That was using jdbc3 driver, though. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 491231) Time Spent: 12h (was: 11h 50m) > Improve JDBC connection management > -- > > Key: ARTEMIS-2823 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2823 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Mikko >Priority: Major > Time Spent: 12h > Remaining Estimate: 0h > > I have a case where the whole clustering reliability and HA must rely on HA > capabilities of clustered database, and running on top of application server > is not an option. > The current JDBC store implementation is rather bare bones on the connection > management side. JDBC driver is used directly with no management layer. At > startup, the broker just opens couple of direct connections to database and > expects them to be available forever. This is something that cannot be > expected in HA production environment. So, similarly to the discussion linked > below, in our case we lose the db connection after one hour, and all the > brokers need to be restared to get new connections: > [http://activemq.2283324.n4.nabble.com/Artemis-does-not-reconnect-to-MySQL-after-connection-timeout-td4751956.html] > > This is something that could be resolved by simply using JDBC4 isValid > checks, but proper connection handling and pooling through datasource would > be preferrable. > I have implemented a solution for this by using DBCP2 datasource. Our test > cluster has been successfully running this forked version since the release > of Artemis 2.13.0. I will prepare of pull request if this is seen to be > something that can be useful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2823) Improve JDBC connection management
[ https://issues.apache.org/jira/browse/ARTEMIS-2823?focusedWorklogId=491229&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-491229 ] ASF GitHub Bot logged work on ARTEMIS-2823: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:57 Start Date: 25/Sep/20 13:57 Worklog Time Spent: 10m Work Description: franz1981 edited a comment on pull request #3204: URL: https://github.com/apache/activemq-artemis/pull/3204#issuecomment-698938979 > Based on earlier tests I suspected that JDBC4 driver with isValid checks would be enough to cope with this And it is unless paging or large msg happen, because can be called on different threads without limits: the point is that only lease lock and node manager are alive (the former to renew/check lock, the latter to read the slave) with an idle broker ie 2 connections. I don't know what can be the third one... This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 491229) Time Spent: 11h 50m (was: 11h 40m) > Improve JDBC connection management > -- > > Key: ARTEMIS-2823 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2823 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Mikko >Priority: Major > Time Spent: 11h 50m > Remaining Estimate: 0h > > I have a case where the whole clustering reliability and HA must rely on HA > capabilities of clustered database, and running on top of application server > is not an option. > The current JDBC store implementation is rather bare bones on the connection > management side. JDBC driver is used directly with no management layer. At > startup, the broker just opens couple of direct connections to database and > expects them to be available forever. This is something that cannot be > expected in HA production environment. So, similarly to the discussion linked > below, in our case we lose the db connection after one hour, and all the > brokers need to be restared to get new connections: > [http://activemq.2283324.n4.nabble.com/Artemis-does-not-reconnect-to-MySQL-after-connection-timeout-td4751956.html] > > This is something that could be resolved by simply using JDBC4 isValid > checks, but proper connection handling and pooling through datasource would > be preferrable. > I have implemented a solution for this by using DBCP2 datasource. Our test > cluster has been successfully running this forked version since the release > of Artemis 2.13.0. I will prepare of pull request if this is seen to be > something that can be useful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2823) Improve JDBC connection management
[ https://issues.apache.org/jira/browse/ARTEMIS-2823?focusedWorklogId=491224&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-491224 ] ASF GitHub Bot logged work on ARTEMIS-2823: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:53 Start Date: 25/Sep/20 13:53 Worklog Time Spent: 10m Work Description: franz1981 commented on pull request #3204: URL: https://github.com/apache/activemq-artemis/pull/3204#issuecomment-698938979 > Based on earlier tests I suspected that JDBC4 driver with isValid checks would be enough to cope with this And it is, the point is that only lease lock and node manager are alive with an idle broker ie 2 connections I don't know what can be the third one... This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 491224) Time Spent: 11h 40m (was: 11.5h) > Improve JDBC connection management > -- > > Key: ARTEMIS-2823 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2823 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Mikko >Priority: Major > Time Spent: 11h 40m > Remaining Estimate: 0h > > I have a case where the whole clustering reliability and HA must rely on HA > capabilities of clustered database, and running on top of application server > is not an option. > The current JDBC store implementation is rather bare bones on the connection > management side. JDBC driver is used directly with no management layer. At > startup, the broker just opens couple of direct connections to database and > expects them to be available forever. This is something that cannot be > expected in HA production environment. So, similarly to the discussion linked > below, in our case we lose the db connection after one hour, and all the > brokers need to be restared to get new connections: > [http://activemq.2283324.n4.nabble.com/Artemis-does-not-reconnect-to-MySQL-after-connection-timeout-td4751956.html] > > This is something that could be resolved by simply using JDBC4 isValid > checks, but proper connection handling and pooling through datasource would > be preferrable. > I have implemented a solution for this by using DBCP2 datasource. Our test > cluster has been successfully running this forked version since the release > of Artemis 2.13.0. I will prepare of pull request if this is seen to be > something that can be useful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2823) Improve JDBC connection management
[ https://issues.apache.org/jira/browse/ARTEMIS-2823?focusedWorklogId=491221&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-491221 ] ASF GitHub Bot logged work on ARTEMIS-2823: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:53 Start Date: 25/Sep/20 13:53 Worklog Time Spent: 10m Work Description: uomik edited a comment on pull request #3204: URL: https://github.com/apache/activemq-artemis/pull/3204#issuecomment-698937509 One thing thats a little strange is that the pool had only three active db connections at the time the error occurred (DBCP2 default max is 8, that should be enough in most cases). Another peculiar thing was that I noticed that this happened at exactly the same time on two of the four masters in the cluster. This may actually be the same issue we've had with other applications with this particular database server: the server randomly closes some of the connections after one hour, being active or not. Based on earlier tests I suspected that JDBC4 driver with isValid checks would be enough to cope with this. I will first check whether the same pool configuration we use elsewhere resolves the issue. If the problem persists will experiment with the other options This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 491221) Time Spent: 11h 20m (was: 11h 10m) > Improve JDBC connection management > -- > > Key: ARTEMIS-2823 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2823 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Mikko >Priority: Major > Time Spent: 11h 20m > Remaining Estimate: 0h > > I have a case where the whole clustering reliability and HA must rely on HA > capabilities of clustered database, and running on top of application server > is not an option. > The current JDBC store implementation is rather bare bones on the connection > management side. JDBC driver is used directly with no management layer. At > startup, the broker just opens couple of direct connections to database and > expects them to be available forever. This is something that cannot be > expected in HA production environment. So, similarly to the discussion linked > below, in our case we lose the db connection after one hour, and all the > brokers need to be restared to get new connections: > [http://activemq.2283324.n4.nabble.com/Artemis-does-not-reconnect-to-MySQL-after-connection-timeout-td4751956.html] > > This is something that could be resolved by simply using JDBC4 isValid > checks, but proper connection handling and pooling through datasource would > be preferrable. > I have implemented a solution for this by using DBCP2 datasource. Our test > cluster has been successfully running this forked version since the release > of Artemis 2.13.0. I will prepare of pull request if this is seen to be > something that can be useful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2823) Improve JDBC connection management
[ https://issues.apache.org/jira/browse/ARTEMIS-2823?focusedWorklogId=491222&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-491222 ] ASF GitHub Bot logged work on ARTEMIS-2823: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:53 Start Date: 25/Sep/20 13:53 Worklog Time Spent: 10m Work Description: franz1981 edited a comment on pull request #3204: URL: https://github.com/apache/activemq-artemis/pull/3204#issuecomment-698938979 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 491222) Time Spent: 11.5h (was: 11h 20m) > Improve JDBC connection management > -- > > Key: ARTEMIS-2823 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2823 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Mikko >Priority: Major > Time Spent: 11.5h > Remaining Estimate: 0h > > I have a case where the whole clustering reliability and HA must rely on HA > capabilities of clustered database, and running on top of application server > is not an option. > The current JDBC store implementation is rather bare bones on the connection > management side. JDBC driver is used directly with no management layer. At > startup, the broker just opens couple of direct connections to database and > expects them to be available forever. This is something that cannot be > expected in HA production environment. So, similarly to the discussion linked > below, in our case we lose the db connection after one hour, and all the > brokers need to be restared to get new connections: > [http://activemq.2283324.n4.nabble.com/Artemis-does-not-reconnect-to-MySQL-after-connection-timeout-td4751956.html] > > This is something that could be resolved by simply using JDBC4 isValid > checks, but proper connection handling and pooling through datasource would > be preferrable. > I have implemented a solution for this by using DBCP2 datasource. Our test > cluster has been successfully running this forked version since the release > of Artemis 2.13.0. I will prepare of pull request if this is seen to be > something that can be useful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2908) Persist Divert Configuration in Bindings journal
[ https://issues.apache.org/jira/browse/ARTEMIS-2908?focusedWorklogId=491204&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-491204 ] ASF GitHub Bot logged work on ARTEMIS-2908: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:52 Start Date: 25/Sep/20 13:52 Worklog Time Spent: 10m Work Description: andytaylor commented on a change in pull request #3278: URL: https://github.com/apache/activemq-artemis/pull/3278#discussion_r494864910 ## File path: artemis-core-client/src/main/java/org/apache/activemq/artemis/utils/BufferHelper.java ## @@ -16,8 +16,10 @@ */ package org.apache.activemq.artemis.utils; +import io.netty.buffer.ByteBufUtil; import org.apache.activemq.artemis.api.core.ActiveMQBuffer; Review comment: fixed This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 491204) Time Spent: 1.5h (was: 1h 20m) > Persist Divert Configuration in Bindings journal > > > Key: ARTEMIS-2908 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2908 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Andy Taylor >Assignee: Andy Taylor >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2823) Improve JDBC connection management
[ https://issues.apache.org/jira/browse/ARTEMIS-2823?focusedWorklogId=491156&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-491156 ] ASF GitHub Bot logged work on ARTEMIS-2823: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:47 Start Date: 25/Sep/20 13:47 Worklog Time Spent: 10m Work Description: uomik commented on pull request #3204: URL: https://github.com/apache/activemq-artemis/pull/3204#issuecomment-698902202 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 491156) Time Spent: 11h 10m (was: 11h) > Improve JDBC connection management > -- > > Key: ARTEMIS-2823 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2823 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Mikko >Priority: Major > Time Spent: 11h 10m > Remaining Estimate: 0h > > I have a case where the whole clustering reliability and HA must rely on HA > capabilities of clustered database, and running on top of application server > is not an option. > The current JDBC store implementation is rather bare bones on the connection > management side. JDBC driver is used directly with no management layer. At > startup, the broker just opens couple of direct connections to database and > expects them to be available forever. This is something that cannot be > expected in HA production environment. So, similarly to the discussion linked > below, in our case we lose the db connection after one hour, and all the > brokers need to be restared to get new connections: > [http://activemq.2283324.n4.nabble.com/Artemis-does-not-reconnect-to-MySQL-after-connection-timeout-td4751956.html] > > This is something that could be resolved by simply using JDBC4 isValid > checks, but proper connection handling and pooling through datasource would > be preferrable. > I have implemented a solution for this by using DBCP2 datasource. Our test > cluster has been successfully running this forked version since the release > of Artemis 2.13.0. I will prepare of pull request if this is seen to be > something that can be useful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2823) Improve JDBC connection management
[ https://issues.apache.org/jira/browse/ARTEMIS-2823?focusedWorklogId=491149&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-491149 ] ASF GitHub Bot logged work on ARTEMIS-2823: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:47 Start Date: 25/Sep/20 13:47 Worklog Time Spent: 10m Work Description: uomik edited a comment on pull request #3204: URL: https://github.com/apache/activemq-artemis/pull/3204#issuecomment-698902202 @franz1981 > I've just one concern looking at the default pool configuration: the number of available JDBC connections in the pool and the behaviour when there are none available. > > I see that paging + large messsages can use an unbounded number of connections (it really depends by the amount of concurrent threads that perform page/large msg streaming operations), the 2 journals requires 1 connections each (binding + message journal) and the node manager requires 2 (the lease lock + the node manager shared state) connections. > That means that without paging or large messages a minimum of 2 + 2 = 4 database connections. > The problem I see is paging and large messages: if the are too many some of the other operations will hang, awaiting an available connection, that means that probably we need to add the critical analyzer there or just let users knows they can configure pool appropriately. Getting back to this. We've lately opened our test cluster for "external" clients, this has increased load and amount of transactions quite a lot. As a result we've quite frequently seen an event where master restarts due to issues with live locks. We are still using default settings for the pool and I'm suspecting that this may actually be a result of DB connection starvation. I will experiment with pool settings next week and will hopefully find something to overcome this issue. ``` 2020-09-25 11:53:10,958 WARN [org.apache.activemq.artemis.core.server] AMQ222010: Critical IO Error, shutting down the server. file=NULL, message=Critical error while on live renew: java.lang.IllegalStateException: live lock can't be renewed at org.apache.activemq.artemis.core.server.impl.jdbc.ActiveMQScheduledLeaseLock.run(ActiveMQScheduledLeaseLock.java:92) [artemis-server-2.13.0.jar:2.13.0] at org.apache.activemq.artemis.core.server.ActiveMQScheduledComponent$2.run(ActiveMQScheduledComponent.java:306) [artemis-commons-2.13.0.jar:2.13.0] at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) [artemis-commons-2.13.0.jar:2.13.0] at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) [artemis-commons-2.13.0.jar:2.13.0] at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65) [artemis-commons-2.13.0.jar:2.13.0] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_221] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_221] at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) [artemis-commons-2.13.0.jar:2.13.0] 2020-09-25 11:53:10,981 ERROR [org.apache.activemq.artemis.core.server.impl.jdbc.ActiveMQScheduledLeaseLock] live lock renew tooks 39255 ms, while is supposed to take <4000 ms ``` This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 491149) Time Spent: 11h (was: 10h 50m) > Improve JDBC connection management > -- > > Key: ARTEMIS-2823 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2823 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Mikko >Priority: Major > Time Spent: 11h > Remaining Estimate: 0h > > I have a case where the whole clustering reliability and HA must rely on HA > capabilities of clustered database, and running on top of application server > is not an option. > The current JDBC store implementation is rather bare bones on the connection > management side. JDBC driver is used directly with no management layer. At > startup, the broker just opens couple of direct connections to database and > expects them to be available forever. This is something that cannot be > expected in HA production environment. So, similarly to the discussion linked > below, in our case we los
[jira] [Work logged] (ARTEMIS-2915) Duplicate temp queues using OpenWire
[
https://issues.apache.org/jira/browse/ARTEMIS-2915?focusedWorklogId=491044&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-491044
]
ASF GitHub Bot logged work on ARTEMIS-2915:
---
Author: ASF GitHub Bot
Created on: 25/Sep/20 13:37
Start Date: 25/Sep/20 13:37
Worklog Time Spent: 10m
Work Description: jbertram opened a new pull request #3276:
URL: https://github.com/apache/activemq-artemis/pull/3276
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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: 491044)
Time Spent: 40m (was: 0.5h)
> Duplicate temp queues using OpenWire
>
>
> Key: ARTEMIS-2915
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2915
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When using OpenWire and creating/closing multiple different producers on the
> same temporary queue the broker will store (i.e. duplicate) the same
> temporary queue in its internal data structures. This was originally
> discovered using the [ActiveMQ Camel
> component|https://camel.apache.org/components/latest/activemq-component.html]
> with an {{InOut}} exchange pattern.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2768) Negative AddressSize in JMX
[ https://issues.apache.org/jira/browse/ARTEMIS-2768?focusedWorklogId=491130&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-491130 ] ASF GitHub Bot logged work on ARTEMIS-2768: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:45 Start Date: 25/Sep/20 13:45 Worklog Time Spent: 10m Work Description: asfgit closed pull request #3277: URL: https://github.com/apache/activemq-artemis/pull/3277 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 491130) Time Spent: 2h 20m (was: 2h 10m) > Negative AddressSize in JMX > --- > > Key: ARTEMIS-2768 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2768 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.11.0, 2.12.0, 2.14.0 >Reporter: Tarek Hammoud >Assignee: Gary Tully >Priority: Major > Fix For: 2.16.0 > > Attachments: TestWildCard.java > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Hello, > I see negative address size in JMX. This happens when there are two > consumers. One listening on the full topic name. The other listening on the > wild card topic. I can easily reproduce with this. [^TestWildCard.java] > ^Broker shows:^ > ^2020-05-17 09:24:34,826 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-152.^ > ^2020-05-17 09:24:34,827 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-88.^ > ^2020-05-17 09:24:34,828 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-944.^ > ^2020-05-17 09:24:34,828 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-1,800.^ > ^2020-05-17 09:24:34,829 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-1,736.^ > ^2020-05-17 09:24:34,829 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-2,592.^ > ^2020-05-17 09:24:34,829 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-3,448.^ > ^2020-05-17 09:24:34,830 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-4,304.^ > ^2020-05-17 09:24:34,830 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-5,160.^ > ^2020-05-17 09:24:34,830 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-5,096.^ > ^2020-05-17 09:24:34,831 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-5,952.^ > ^2020-05-17 09:24:34,831 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-6,016.^ > ^2020-05-17 09:24:34,832 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-6,080.^ > ^2020-05-17 09:24:34,832 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-6,016.^ > ^2020-05-17 09:24:34,832 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-6,872.^ > ^2020-05-17 09:24:34,832 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-7,728.^ > ^2020-05-17 09:24:34,833 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-8,584.^ > ^2020-05-17 09:24:34,833 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-8,520.^ > ^2020-05-17 09:24:34,833 WARN [or
[jira] [Work logged] (ARTEMIS-2908) Persist Divert Configuration in Bindings journal
[ https://issues.apache.org/jira/browse/ARTEMIS-2908?focusedWorklogId=491119&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-491119 ] ASF GitHub Bot logged work on ARTEMIS-2908: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:44 Start Date: 25/Sep/20 13:44 Worklog Time Spent: 10m Work Description: brusdev commented on a change in pull request #3278: URL: https://github.com/apache/activemq-artemis/pull/3278#discussion_r494774165 ## File path: artemis-core-client/src/main/java/org/apache/activemq/artemis/utils/BufferHelper.java ## @@ -16,8 +16,10 @@ */ package org.apache.activemq.artemis.utils; +import io.netty.buffer.ByteBufUtil; import org.apache.activemq.artemis.api.core.ActiveMQBuffer; Review comment: This import doesn't look used. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 491119) Time Spent: 1h 20m (was: 1h 10m) > Persist Divert Configuration in Bindings journal > > > Key: ARTEMIS-2908 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2908 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Andy Taylor >Assignee: Andy Taylor >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2914) MariaDB SQL isn't correctly recognized
[ https://issues.apache.org/jira/browse/ARTEMIS-2914?focusedWorklogId=491115&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-491115 ] ASF GitHub Bot logged work on ARTEMIS-2914: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:43 Start Date: 25/Sep/20 13:43 Worklog Time Spent: 10m Work Description: asfgit closed pull request #3275: URL: https://github.com/apache/activemq-artemis/pull/3275 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 491115) Time Spent: 40m (was: 0.5h) > MariaDB SQL isn't correctly recognized > -- > > Key: ARTEMIS-2914 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2914 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.15.0 >Reporter: Francesco Nigro >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > MariaDB could be treated as a MySQL replacement in term of SQL used so we > need to add it as a MySQLish drivers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2888) MQTT spec violation when subscribed to wildcard topic
[ https://issues.apache.org/jira/browse/ARTEMIS-2888?focusedWorklogId=491073&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-491073 ] ASF GitHub Bot logged work on ARTEMIS-2888: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:40 Start Date: 25/Sep/20 13:40 Worklog Time Spent: 10m Work Description: gtully commented on pull request #3265: URL: https://github.com/apache/activemq-artemis/pull/3265#issuecomment-698205974 @jbertram thanks, that is a nice test. pulled it in and proves the point that this new page-store-name setting is needed even if paging does not kick in because the dispatch is always through cursors. updated the doc to reflect that. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 491073) Time Spent: 1h 50m (was: 1h 40m) > MQTT spec violation when subscribed to wildcard topic > - > > Key: ARTEMIS-2888 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2888 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: MQTT >Affects Versions: 2.14.0 > Environment: *Message Producer:* > MQTTnet Client > published Message to > 0e5ed50e-ccea-4a42-8c3e-db0e2780222b/from-smart-acquisition-device/machine-state/event/off > > *Message Consumer:* > MQTT Paho Java Client, also tested with HiveMQ Java Client. > Subscribed to +/from-smart-acquisition-device/machine-state/event/off >Reporter: Florian Meister >Assignee: Gary Tully >Priority: Major > Fix For: 2.16.0 > > Attachments: image-2020-08-27-12-37-01-479.png > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Sometimes the topic name of published messages contains the topic filter > instead of the topic name. > This is neither correct nor allowed in the MQTT 3.1.1 specification: > [http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718106] > > Below a screenshot of an example MQTT Packet sent from the Artemis Broker > !image-2020-08-27-12-37-01-479.png! > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2838) Migrate Console to use Hawtio 2
[ https://issues.apache.org/jira/browse/ARTEMIS-2838?focusedWorklogId=491085&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-491085 ] ASF GitHub Bot logged work on ARTEMIS-2838: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:41 Start Date: 25/Sep/20 13:41 Worklog Time Spent: 10m Work Description: andytaylor commented on pull request #3257: URL: https://github.com/apache/activemq-artemis/pull/3257#issuecomment-698192837 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 491085) Time Spent: 5h 10m (was: 5h) > Migrate Console to use Hawtio 2 > --- > > Key: ARTEMIS-2838 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2838 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Andy Taylor >Assignee: Andy Taylor >Priority: Major > Fix For: 2.16.0 > > Time Spent: 5h 10m > Remaining Estimate: 0h > > The main concern here is upgrading HawtIO as version 1 is no longer > maintained and we need to reduce the chance of CVE's going forward. > > I've basically re written the console JavaScript using the new API's making > them as much as possible the same as the original. There are a few minor > changes but nothing that would warrant a loss is functionality. This also > has a new look and feel. Ive aslo improved some features, these include: > > # A new landing page that shows some basic broker state, uptime, cluster > status, address memory used. > # A HawtIO security mbean, this means that hawtIO will check at call time > whether or not the attribute or operation can be called, so rather than see > an error in the attributes stab when access isnt authorised it is handled > gracefully. This is also used to control whether a tab is available, so if a > user does not have access to the createqueue jmx method then the create queue > tab will not be available. > # Added a help button to most of the tabs > # A search facility for mbeans in the JMX tree -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2912) Server start exception before activation can cause a zombie broker
[
https://issues.apache.org/jira/browse/ARTEMIS-2912?focusedWorklogId=491081&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-491081
]
ASF GitHub Bot logged work on ARTEMIS-2912:
---
Author: ASF GitHub Bot
Created on: 25/Sep/20 13:40
Start Date: 25/Sep/20 13:40
Worklog Time Spent: 10m
Work Description: franz1981 commented on a change in pull request #3274:
URL: https://github.com/apache/activemq-artemis/pull/3274#discussion_r494149668
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java
##
@@ -1075,17 +1089,24 @@ void stop(boolean failoverOnServerShutdown, final
boolean criticalIOError, boole
state = SERVER_STATE.STOPPING;
if (criticalIOError) {
-// notifications trigger disk IO so we don't want to send any on a
critical IO error
-managementService.enableNotifications(false);
+final ManagementService managementService = this.managementService;
Review comment:
It's thanks to Java Language Specification: the local
`managementService` cannot change once read
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java
##
@@ -1075,17 +1089,24 @@ void stop(boolean failoverOnServerShutdown, final
boolean criticalIOError, boole
state = SERVER_STATE.STOPPING;
if (criticalIOError) {
-// notifications trigger disk IO so we don't want to send any on a
critical IO error
-managementService.enableNotifications(false);
+final ManagementService managementService = this.managementService;
Review comment:
It's thanks to Java Language Specification: the local
`managementService` cannot change once read
Not sure if that answer your question
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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: 491081)
Time Spent: 2h 20m (was: 2h 10m)
> Server start exception before activation can cause a zombie broker
> --
>
> Key: ARTEMIS-2912
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2912
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Reporter: Francesco Nigro
>Priority: Major
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Run::execute:
> # start a broker
> # add several external components while starting them right after
> If the broker is getting started and, right before activating, throw an
> exception (eg on NodeManager::start), its process won't be stopped because
> the ActivationFailureListener won't get triggered.
> if the broker is getting started and, right before activating it, it throws
> an exception AND raise an I/O critical error (eg JdbcNodeManager:.start), a
> separate Thread would race to stop the broker external components while they
> are being added (and started): if some of these components are added AFTER
> the stop has completed or are started after being stopped, they would prevent
> the process to stop.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2908) Persist Divert Configuration in Bindings journal
[ https://issues.apache.org/jira/browse/ARTEMIS-2908?focusedWorklogId=491084&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-491084 ] ASF GitHub Bot logged work on ARTEMIS-2908: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:40 Start Date: 25/Sep/20 13:40 Worklog Time Spent: 10m Work Description: andytaylor opened a new pull request #3278: URL: https://github.com/apache/activemq-artemis/pull/3278 https://issues.apache.org/jira/browse/ARTEMIS-2908 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 491084) Time Spent: 1h 10m (was: 1h) > Persist Divert Configuration in Bindings journal > > > Key: ARTEMIS-2908 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2908 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Andy Taylor >Assignee: Andy Taylor >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2914) MariaDB SQL isn't correctly recognized
[ https://issues.apache.org/jira/browse/ARTEMIS-2914?focusedWorklogId=491057&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-491057 ] ASF GitHub Bot logged work on ARTEMIS-2914: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:38 Start Date: 25/Sep/20 13:38 Worklog Time Spent: 10m Work Description: franz1981 opened a new pull request #3275: URL: https://github.com/apache/activemq-artemis/pull/3275 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 491057) Time Spent: 0.5h (was: 20m) > MariaDB SQL isn't correctly recognized > -- > > Key: ARTEMIS-2914 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2914 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.15.0 >Reporter: Francesco Nigro >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > MariaDB could be treated as a MySQL replacement in term of SQL used so we > need to add it as a MySQLish drivers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2912) Server start exception before activation can cause a zombie broker
[ https://issues.apache.org/jira/browse/ARTEMIS-2912?focusedWorklogId=491018&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-491018 ] ASF GitHub Bot logged work on ARTEMIS-2912: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:35 Start Date: 25/Sep/20 13:35 Worklog Time Spent: 10m Work Description: franz1981 opened a new pull request #3274: URL: https://github.com/apache/activemq-artemis/pull/3274 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 491018) Time Spent: 2h 10m (was: 2h) > Server start exception before activation can cause a zombie broker > -- > > Key: ARTEMIS-2912 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2912 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Reporter: Francesco Nigro >Priority: Major > Time Spent: 2h 10m > Remaining Estimate: 0h > > Run::execute: > # start a broker > # add several external components while starting them right after > If the broker is getting started and, right before activating, throw an > exception (eg on NodeManager::start), its process won't be stopped because > the ActivationFailureListener won't get triggered. > if the broker is getting started and, right before activating it, it throws > an exception AND raise an I/O critical error (eg JdbcNodeManager:.start), a > separate Thread would race to stop the broker external components while they > are being added (and started): if some of these components are added AFTER > the stop has completed or are started after being stopped, they would prevent > the process to stop. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2768) Negative AddressSize in JMX
[ https://issues.apache.org/jira/browse/ARTEMIS-2768?focusedWorklogId=491017&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-491017 ] ASF GitHub Bot logged work on ARTEMIS-2768: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:35 Start Date: 25/Sep/20 13:35 Worklog Time Spent: 10m Work Description: gtully commented on pull request #3277: URL: https://github.com/apache/activemq-artemis/pull/3277#issuecomment-698456000 @clebertsuconic is there a better place for this check? It seems as if addressInfo should know about wildcards but that logic is currently in addressImpl and the address manager. hmm, maybe it also needs to be conditional on wildcard routing being enabled, maybe folks run with it disabled for a tiny perf lift This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 491017) Time Spent: 2h 10m (was: 2h) > Negative AddressSize in JMX > --- > > Key: ARTEMIS-2768 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2768 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.11.0, 2.12.0, 2.14.0 >Reporter: Tarek Hammoud >Assignee: Gary Tully >Priority: Major > Fix For: 2.16.0 > > Attachments: TestWildCard.java > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Hello, > I see negative address size in JMX. This happens when there are two > consumers. One listening on the full topic name. The other listening on the > wild card topic. I can easily reproduce with this. [^TestWildCard.java] > ^Broker shows:^ > ^2020-05-17 09:24:34,826 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-152.^ > ^2020-05-17 09:24:34,827 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-88.^ > ^2020-05-17 09:24:34,828 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-944.^ > ^2020-05-17 09:24:34,828 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-1,800.^ > ^2020-05-17 09:24:34,829 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-1,736.^ > ^2020-05-17 09:24:34,829 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-2,592.^ > ^2020-05-17 09:24:34,829 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-3,448.^ > ^2020-05-17 09:24:34,830 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-4,304.^ > ^2020-05-17 09:24:34,830 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-5,160.^ > ^2020-05-17 09:24:34,830 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-5,096.^ > ^2020-05-17 09:24:34,831 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-5,952.^ > ^2020-05-17 09:24:34,831 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-6,016.^ > ^2020-05-17 09:24:34,832 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-6,080.^ > ^2020-05-17 09:24:34,832 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-6,016.^ > ^2020-05-17 09:24:34,832 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-6,872.^ > ^2020-05-17 09:24:34,832 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-7,728.^ > ^2020-05-17 09:24:34,833 WARN [org.apache.ac
[jira] [Work logged] (ARTEMIS-2859) Strange Address Sizes on clustered topics.
[ https://issues.apache.org/jira/browse/ARTEMIS-2859?focusedWorklogId=490996&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-490996 ] ASF GitHub Bot logged work on ARTEMIS-2859: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:33 Start Date: 25/Sep/20 13:33 Worklog Time Spent: 10m Work Description: gtully commented on pull request #3238: URL: https://github.com/apache/activemq-artemis/pull/3238#issuecomment-698229716 this test is included with the fix in #3265 nice test :-), much appreciated. Thanks! This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 490996) Time Spent: 1h (was: 50m) > Strange Address Sizes on clustered topics. > -- > > Key: ARTEMIS-2859 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2859 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.12.0, 2.14.0 > Environment: uname -a > Linux tarek02 4.4.0-78-generic #99-Ubuntu SMP Thu Apr 27 15:29:09 UTC 2017 > x86_64 x86_64 x86_64 GNU/Linux > java version "1.8.0_251" > Java(TM) SE Runtime Environment (build 1.8.0_251-b08) > Java HotSpot(TM) 64-Bit Server VM (build 25.251-b08, mixed mode) >Reporter: Tarek Hammoud >Assignee: Gary Tully >Priority: Major > Fix For: 2.16.0 > > Attachments: TestClusteredTopic.java, broker.xml, > image-2020-08-03-14-05-54-676.png, image-2020-08-03-14-05-54-720.png, > screenshot.png > > Time Spent: 1h > Remaining Estimate: 0h > > !screenshot.png! Hello, > We are seeing some strange AddressSizes in JMX for simple clustered topics. > The problem was observed on 2.12.0 in production but can also be reproduced > on 2.14.0. I set up a 3-node cluster (Sample broker.xml) attached. The test > program creates multiple clustered topic consumers. A publisher sends a > message every few seconds. The JMX console shows a strange address size on > one of the nodes. Easy to reproduce with the attached test program. Seems to > be fine with queues. > Thank you for help in advance.[^TestClusteredTopic.java][^broker.xml] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2908) Persist Divert Configuration in Bindings journal
[
https://issues.apache.org/jira/browse/ARTEMIS-2908?focusedWorklogId=490989&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-490989
]
ASF GitHub Bot logged work on ARTEMIS-2908:
---
Author: ASF GitHub Bot
Created on: 25/Sep/20 13:32
Start Date: 25/Sep/20 13:32
Worklog Time Spent: 10m
Work Description: franz1981 commented on a change in pull request #3278:
URL: https://github.com/apache/activemq-artemis/pull/3278#discussion_r494780961
##
File path:
artemis-core-client/src/main/java/org/apache/activemq/artemis/utils/BufferHelper.java
##
@@ -155,5 +157,38 @@ public static Double readNullableDouble(ActiveMQBuffer
buffer) {
}
}
+ public static int sizeOfNullableString(String s) {
+ if (s == null) {
+ return DataConstants.SIZE_BOOLEAN;
+ }
+ return DataConstants.SIZE_BOOLEAN + sizeOfString(s);
+ }
+
+ public static int sizeOfeString(String s) {
Review comment:
This one doesn't look correct
##
File path:
artemis-core-client/src/main/java/org/apache/activemq/artemis/utils/BufferHelper.java
##
@@ -155,5 +157,38 @@ public static Double readNullableDouble(ActiveMQBuffer
buffer) {
}
}
+ public static int sizeOfNullableString(String s) {
+ if (s == null) {
+ return DataConstants.SIZE_BOOLEAN;
+ }
+ return DataConstants.SIZE_BOOLEAN + sizeOfString(s);
+ }
+
+ public static int sizeOfeString(String s) {
Review comment:
This one doesn't look used (nor correct)
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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: 490989)
Time Spent: 1h (was: 50m)
> Persist Divert Configuration in Bindings journal
>
>
> Key: ARTEMIS-2908
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2908
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2823) Improve JDBC connection management
[ https://issues.apache.org/jira/browse/ARTEMIS-2823?focusedWorklogId=490950&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-490950 ] ASF GitHub Bot logged work on ARTEMIS-2823: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:28 Start Date: 25/Sep/20 13:28 Worklog Time Spent: 10m Work Description: franz1981 commented on pull request #3204: URL: https://github.com/apache/activemq-artemis/pull/3204#issuecomment-698379438 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 490950) Time Spent: 10h 50m (was: 10h 40m) > Improve JDBC connection management > -- > > Key: ARTEMIS-2823 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2823 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Mikko >Priority: Major > Time Spent: 10h 50m > Remaining Estimate: 0h > > I have a case where the whole clustering reliability and HA must rely on HA > capabilities of clustered database, and running on top of application server > is not an option. > The current JDBC store implementation is rather bare bones on the connection > management side. JDBC driver is used directly with no management layer. At > startup, the broker just opens couple of direct connections to database and > expects them to be available forever. This is something that cannot be > expected in HA production environment. So, similarly to the discussion linked > below, in our case we lose the db connection after one hour, and all the > brokers need to be restared to get new connections: > [http://activemq.2283324.n4.nabble.com/Artemis-does-not-reconnect-to-MySQL-after-connection-timeout-td4751956.html] > > This is something that could be resolved by simply using JDBC4 isValid > checks, but proper connection handling and pooling through datasource would > be preferrable. > I have implemented a solution for this by using DBCP2 datasource. Our test > cluster has been successfully running this forked version since the release > of Artemis 2.13.0. I will prepare of pull request if this is seen to be > something that can be useful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2823) Improve JDBC connection management
[ https://issues.apache.org/jira/browse/ARTEMIS-2823?focusedWorklogId=490937&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-490937 ] ASF GitHub Bot logged work on ARTEMIS-2823: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:27 Start Date: 25/Sep/20 13:27 Worklog Time Spent: 10m Work Description: franz1981 edited a comment on pull request #3204: URL: https://github.com/apache/activemq-artemis/pull/3204#issuecomment-698418106 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 490937) Time Spent: 10h 40m (was: 10.5h) > Improve JDBC connection management > -- > > Key: ARTEMIS-2823 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2823 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Mikko >Priority: Major > Time Spent: 10h 40m > Remaining Estimate: 0h > > I have a case where the whole clustering reliability and HA must rely on HA > capabilities of clustered database, and running on top of application server > is not an option. > The current JDBC store implementation is rather bare bones on the connection > management side. JDBC driver is used directly with no management layer. At > startup, the broker just opens couple of direct connections to database and > expects them to be available forever. This is something that cannot be > expected in HA production environment. So, similarly to the discussion linked > below, in our case we lose the db connection after one hour, and all the > brokers need to be restared to get new connections: > [http://activemq.2283324.n4.nabble.com/Artemis-does-not-reconnect-to-MySQL-after-connection-timeout-td4751956.html] > > This is something that could be resolved by simply using JDBC4 isValid > checks, but proper connection handling and pooling through datasource would > be preferrable. > I have implemented a solution for this by using DBCP2 datasource. Our test > cluster has been successfully running this forked version since the release > of Artemis 2.13.0. I will prepare of pull request if this is seen to be > something that can be useful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2768) Negative AddressSize in JMX
[
https://issues.apache.org/jira/browse/ARTEMIS-2768?focusedWorklogId=490939&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-490939
]
ASF GitHub Bot logged work on ARTEMIS-2768:
---
Author: ASF GitHub Bot
Created on: 25/Sep/20 13:27
Start Date: 25/Sep/20 13:27
Worklog Time Spent: 10m
Work Description: gtully commented on a change in pull request #3277:
URL: https://github.com/apache/activemq-artemis/pull/3277#discussion_r494465252
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java
##
@@ -3512,7 +3513,14 @@ public Queue createQueue(final QueueConfiguration
queueConfiguration, boolean ig
}
}
- QueueConfigurationUtils.applyDynamicQueueDefaults(queueConfiguration,
addressSettingsRepository.getMatch(getRuntimeTempQueueNamespace(queueConfiguration.isTemporary())
+ queueConfiguration.getAddress().toString()));
+ final AddressSettings addressSettings =
addressSettingsRepository.getMatch(getRuntimeTempQueueNamespace(queueConfiguration.isTemporary())
+ queueConfiguration.getAddress().toString());
+ QueueConfigurationUtils.applyDynamicQueueDefaults(queueConfiguration,
addressSettings);
+
+ if (ActiveMQServerLogger.LOGGER.isEnabled(Logger.Level.WARN)) {
+ if (new AddressImpl(queueConfiguration.getAddress(),
configuration.getWildcardConfiguration()).containsWildCard() &&
addressSettings.getPageStoreName() == null) {
Review comment:
I share that concern, i did not find a way to get the AddressImpl back
from the binding created by the wildcard address manager. It needs some surgery
to access.
The addressImpl has a reference to the wildcard config, I guess I could
duplicate that logic in place of the new ..
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java
##
@@ -3512,7 +3513,14 @@ public Queue createQueue(final QueueConfiguration
queueConfiguration, boolean ig
}
}
- QueueConfigurationUtils.applyDynamicQueueDefaults(queueConfiguration,
addressSettingsRepository.getMatch(getRuntimeTempQueueNamespace(queueConfiguration.isTemporary())
+ queueConfiguration.getAddress().toString()));
+ final AddressSettings addressSettings =
addressSettingsRepository.getMatch(getRuntimeTempQueueNamespace(queueConfiguration.isTemporary())
+ queueConfiguration.getAddress().toString());
+ QueueConfigurationUtils.applyDynamicQueueDefaults(queueConfiguration,
addressSettings);
+
+ if (ActiveMQServerLogger.LOGGER.isEnabled(Logger.Level.WARN)) {
+ if (new AddressImpl(queueConfiguration.getAddress(),
configuration.getWildcardConfiguration()).containsWildCard() &&
addressSettings.getPageStoreName() == null) {
Review comment:
Thank you, that is a nice improvement 😷
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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: 490939)
Time Spent: 2h (was: 1h 50m)
> Negative AddressSize in JMX
> ---
>
> Key: ARTEMIS-2768
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2768
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.11.0, 2.12.0, 2.14.0
>Reporter: Tarek Hammoud
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.16.0
>
> Attachments: TestWildCard.java
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Hello,
> I see negative address size in JMX. This happens when there are two
> consumers. One listening on the full topic name. The other listening on the
> wild card topic. I can easily reproduce with this. [^TestWildCard.java]
> ^Broker shows:^
> ^2020-05-17 09:24:34,826 WARN [org.apache.activemq.artemis.core.server]
> AMQ14: Destination global.topic.FooBar has an inconsistent and negative
> address size=-152.^
> ^2020-05-17 09:24:34,827 WARN [org.apache.activemq.artemis.core.server]
> AMQ14: Destination global.topic.FooBar has an inconsistent and negative
> address size=-88.^
> ^2020-05-17 09:24:34,828 WARN [org.apache.activemq.artemis.core.server]
> AMQ14: Destination global.topic.FooBar has an inconsistent and negative
> address size=-944.^
> ^2020-05-17 09:24:34,828 WARN [org.apache.activemq.artemis.core.server]
> AMQ14: Destination global.topic.FooBar has an inconsistent and negative
> address size=-1,800.^
> ^2020-05-17 09:24:34,829 WARN [org.apache.activemq.artemis.core.server]
[jira] [Work logged] (ARTEMIS-2906) Add lastAckTimestamp to message counter
[ https://issues.apache.org/jira/browse/ARTEMIS-2906?focusedWorklogId=490928&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-490928 ] ASF GitHub Bot logged work on ARTEMIS-2906: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:26 Start Date: 25/Sep/20 13:26 Worklog Time Spent: 10m Work Description: asfgit closed pull request #3267: URL: https://github.com/apache/activemq-artemis/pull/3267 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 490928) Time Spent: 0.5h (was: 20m) > Add lastAckTimestamp to message counter > --- > > Key: ARTEMIS-2906 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2906 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2768) Negative AddressSize in JMX
[
https://issues.apache.org/jira/browse/ARTEMIS-2768?focusedWorklogId=490931&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-490931
]
ASF GitHub Bot logged work on ARTEMIS-2768:
---
Author: ASF GitHub Bot
Created on: 25/Sep/20 13:26
Start Date: 25/Sep/20 13:26
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on a change in pull request
#3277:
URL: https://github.com/apache/activemq-artemis/pull/3277#discussion_r494462075
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java
##
@@ -3512,7 +3513,14 @@ public Queue createQueue(final QueueConfiguration
queueConfiguration, boolean ig
}
}
- QueueConfigurationUtils.applyDynamicQueueDefaults(queueConfiguration,
addressSettingsRepository.getMatch(getRuntimeTempQueueNamespace(queueConfiguration.isTemporary())
+ queueConfiguration.getAddress().toString()));
+ final AddressSettings addressSettings =
addressSettingsRepository.getMatch(getRuntimeTempQueueNamespace(queueConfiguration.isTemporary())
+ queueConfiguration.getAddress().toString());
+ QueueConfigurationUtils.applyDynamicQueueDefaults(queueConfiguration,
addressSettings);
+
+ if (ActiveMQServerLogger.LOGGER.isEnabled(Logger.Level.WARN)) {
Review comment:
I don't think you need to check for warn enabled... it shouldn't be a
big burden anyways.
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java
##
@@ -3512,7 +3513,14 @@ public Queue createQueue(final QueueConfiguration
queueConfiguration, boolean ig
}
}
- QueueConfigurationUtils.applyDynamicQueueDefaults(queueConfiguration,
addressSettingsRepository.getMatch(getRuntimeTempQueueNamespace(queueConfiguration.isTemporary())
+ queueConfiguration.getAddress().toString()));
+ final AddressSettings addressSettings =
addressSettingsRepository.getMatch(getRuntimeTempQueueNamespace(queueConfiguration.isTemporary())
+ queueConfiguration.getAddress().toString());
+ QueueConfigurationUtils.applyDynamicQueueDefaults(queueConfiguration,
addressSettings);
+
+ if (ActiveMQServerLogger.LOGGER.isEnabled(Logger.Level.WARN)) {
+ if (new AddressImpl(queueConfiguration.getAddress(),
configuration.getWildcardConfiguration()).containsWildCard() &&
addressSettings.getPageStoreName() == null) {
Review comment:
isn't there a better way instead of new AddressImpl() ?
that's the only concern I have.
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java
##
@@ -3512,7 +3513,14 @@ public Queue createQueue(final QueueConfiguration
queueConfiguration, boolean ig
}
}
- QueueConfigurationUtils.applyDynamicQueueDefaults(queueConfiguration,
addressSettingsRepository.getMatch(getRuntimeTempQueueNamespace(queueConfiguration.isTemporary())
+ queueConfiguration.getAddress().toString()));
+ final AddressSettings addressSettings =
addressSettingsRepository.getMatch(getRuntimeTempQueueNamespace(queueConfiguration.isTemporary())
+ queueConfiguration.getAddress().toString());
+ QueueConfigurationUtils.applyDynamicQueueDefaults(queueConfiguration,
addressSettings);
+
+ if (ActiveMQServerLogger.LOGGER.isEnabled(Logger.Level.WARN)) {
+ if (new AddressImpl(queueConfiguration.getAddress(),
configuration.getWildcardConfiguration()).containsWildCard() &&
addressSettings.getPageStoreName() == null) {
Review comment:
@gtully I've sent a Pull Request towards your personal fork:
https://github.com/gtully/activemq-artemis/pull/1
if you can squash it with your commit. I was looking through the code it
was easier to just write the change instead of explaining it.
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java
##
@@ -3512,7 +3513,14 @@ public Queue createQueue(final QueueConfiguration
queueConfiguration, boolean ig
}
}
- QueueConfigurationUtils.applyDynamicQueueDefaults(queueConfiguration,
addressSettingsRepository.getMatch(getRuntimeTempQueueNamespace(queueConfiguration.isTemporary())
+ queueConfiguration.getAddress().toString()));
+ final AddressSettings addressSettings =
addressSettingsRepository.getMatch(getRuntimeTempQueueNamespace(queueConfiguration.isTemporary())
+ queueConfiguration.getAddress().toString());
+ QueueConfigurationUtils.applyDynamicQueueDefaults(queueConfiguration,
addressSettings);
+
+ if (ActiveMQServerLogger.LOGGER.isEnabled(Logger.Level.WARN)) {
+ if (new AddressImpl(queueConfiguration.getAddress(),
configuration.getWildcardConfiguration()).containsWildCard() &&
addressSettings.ge
[jira] [Work logged] (ARTEMIS-2912) Server start exception before activation can cause a zombie broker
[
https://issues.apache.org/jira/browse/ARTEMIS-2912?focusedWorklogId=490906&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-490906
]
ASF GitHub Bot logged work on ARTEMIS-2912:
---
Author: ASF GitHub Bot
Created on: 25/Sep/20 13:25
Start Date: 25/Sep/20 13:25
Worklog Time Spent: 10m
Work Description: brusdev commented on a change in pull request #3274:
URL: https://github.com/apache/activemq-artemis/pull/3274#discussion_r494139697
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java
##
@@ -1075,17 +1089,24 @@ void stop(boolean failoverOnServerShutdown, final
boolean criticalIOError, boole
state = SERVER_STATE.STOPPING;
if (criticalIOError) {
-// notifications trigger disk IO so we don't want to send any on a
critical IO error
-managementService.enableNotifications(false);
+final ManagementService managementService = this.managementService;
Review comment:
why do we need this variable? who is setting to null this variable on
stopping?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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: 490906)
Time Spent: 2h (was: 1h 50m)
> Server start exception before activation can cause a zombie broker
> --
>
> Key: ARTEMIS-2912
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2912
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Reporter: Francesco Nigro
>Priority: Major
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Run::execute:
> # start a broker
> # add several external components while starting them right after
> If the broker is getting started and, right before activating, throw an
> exception (eg on NodeManager::start), its process won't be stopped because
> the ActivationFailureListener won't get triggered.
> if the broker is getting started and, right before activating it, it throws
> an exception AND raise an I/O critical error (eg JdbcNodeManager:.start), a
> separate Thread would race to stop the broker external components while they
> are being added (and started): if some of these components are added AFTER
> the stop has completed or are started after being stopped, they would prevent
> the process to stop.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2912) Server start exception before activation can cause a zombie broker
[ https://issues.apache.org/jira/browse/ARTEMIS-2912?focusedWorklogId=490892&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-490892 ] ASF GitHub Bot logged work on ARTEMIS-2912: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:23 Start Date: 25/Sep/20 13:23 Worklog Time Spent: 10m Work Description: asfgit closed pull request #3274: URL: https://github.com/apache/activemq-artemis/pull/3274 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 490892) Time Spent: 1h 50m (was: 1h 40m) > Server start exception before activation can cause a zombie broker > -- > > Key: ARTEMIS-2912 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2912 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Reporter: Francesco Nigro >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > Run::execute: > # start a broker > # add several external components while starting them right after > If the broker is getting started and, right before activating, throw an > exception (eg on NodeManager::start), its process won't be stopped because > the ActivationFailureListener won't get triggered. > if the broker is getting started and, right before activating it, it throws > an exception AND raise an I/O critical error (eg JdbcNodeManager:.start), a > separate Thread would race to stop the broker external components while they > are being added (and started): if some of these components are added AFTER > the stop has completed or are started after being stopped, they would prevent > the process to stop. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2859) Strange Address Sizes on clustered topics.
[ https://issues.apache.org/jira/browse/ARTEMIS-2859?focusedWorklogId=490823&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-490823 ] ASF GitHub Bot logged work on ARTEMIS-2859: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:16 Start Date: 25/Sep/20 13:16 Worklog Time Spent: 10m Work Description: gtully closed pull request #3238: URL: https://github.com/apache/activemq-artemis/pull/3238 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 490823) Time Spent: 50m (was: 40m) > Strange Address Sizes on clustered topics. > -- > > Key: ARTEMIS-2859 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2859 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.12.0, 2.14.0 > Environment: uname -a > Linux tarek02 4.4.0-78-generic #99-Ubuntu SMP Thu Apr 27 15:29:09 UTC 2017 > x86_64 x86_64 x86_64 GNU/Linux > java version "1.8.0_251" > Java(TM) SE Runtime Environment (build 1.8.0_251-b08) > Java HotSpot(TM) 64-Bit Server VM (build 25.251-b08, mixed mode) >Reporter: Tarek Hammoud >Assignee: Gary Tully >Priority: Major > Fix For: 2.16.0 > > Attachments: TestClusteredTopic.java, broker.xml, > image-2020-08-03-14-05-54-676.png, image-2020-08-03-14-05-54-720.png, > screenshot.png > > Time Spent: 50m > Remaining Estimate: 0h > > !screenshot.png! Hello, > We are seeing some strange AddressSizes in JMX for simple clustered topics. > The problem was observed on 2.12.0 in production but can also be reproduced > on 2.14.0. I set up a 3-node cluster (Sample broker.xml) attached. The test > program creates multiple clustered topic consumers. A publisher sends a > message every few seconds. The JMX console shows a strange address size on > one of the nodes. Easy to reproduce with the attached test program. Seems to > be fine with queues. > Thank you for help in advance.[^TestClusteredTopic.java][^broker.xml] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2911) DB2 isn't replacing Blob data
[ https://issues.apache.org/jira/browse/ARTEMIS-2911?focusedWorklogId=490760&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-490760 ] ASF GitHub Bot logged work on ARTEMIS-2911: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:10 Start Date: 25/Sep/20 13:10 Worklog Time Spent: 10m Work Description: asfgit closed pull request #3271: URL: https://github.com/apache/activemq-artemis/pull/3271 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 490760) Time Spent: 50m (was: 40m) > DB2 isn't replacing Blob data > - > > Key: ARTEMIS-2911 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2911 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.0, 2.15.0 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > JDBC sequential file data replacement for IBM DB2 database isn't working due > to some overloading issue introduced by > https://issues.apache.org/jira/browse/ARTEMIS-1813. > Fixing the overloading issue isn't enough to solve this, because DB2 needs > different SQL statements while appending and replacing data on sequential > files. > The less impactfull solution seems to expose a SQL statement that will be > used just on IBM DB2, saving the other DBMS to be tested again. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2838) Migrate Console to use Hawtio 2
[ https://issues.apache.org/jira/browse/ARTEMIS-2838?focusedWorklogId=490765&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-490765 ] ASF GitHub Bot logged work on ARTEMIS-2838: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:10 Start Date: 25/Sep/20 13:10 Worklog Time Spent: 10m Work Description: michaelpearce-gain commented on pull request #3257: URL: https://github.com/apache/activemq-artemis/pull/3257#issuecomment-698314746 i cannot speak for all users, but its used where i am working. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 490765) Time Spent: 5h (was: 4h 50m) > Migrate Console to use Hawtio 2 > --- > > Key: ARTEMIS-2838 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2838 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Andy Taylor >Assignee: Andy Taylor >Priority: Major > Fix For: 2.16.0 > > Time Spent: 5h > Remaining Estimate: 0h > > The main concern here is upgrading HawtIO as version 1 is no longer > maintained and we need to reduce the chance of CVE's going forward. > > I've basically re written the console JavaScript using the new API's making > them as much as possible the same as the original. There are a few minor > changes but nothing that would warrant a loss is functionality. This also > has a new look and feel. Ive aslo improved some features, these include: > > # A new landing page that shows some basic broker state, uptime, cluster > status, address memory used. > # A HawtIO security mbean, this means that hawtIO will check at call time > whether or not the attribute or operation can be called, so rather than see > an error in the attributes stab when access isnt authorised it is handled > gracefully. This is also used to control whether a tab is available, so if a > user does not have access to the createqueue jmx method then the create queue > tab will not be available. > # Added a help button to most of the tabs > # A search facility for mbeans in the JMX tree -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2768) Negative AddressSize in JMX
[ https://issues.apache.org/jira/browse/ARTEMIS-2768?focusedWorklogId=490743&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-490743 ] ASF GitHub Bot logged work on ARTEMIS-2768: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:08 Start Date: 25/Sep/20 13:08 Worklog Time Spent: 10m Work Description: gtully opened a new pull request #3277: URL: https://github.com/apache/activemq-artemis/pull/3277 …atching page-store-name address setting This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 490743) Time Spent: 1h 40m (was: 1.5h) > Negative AddressSize in JMX > --- > > Key: ARTEMIS-2768 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2768 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.11.0, 2.12.0, 2.14.0 >Reporter: Tarek Hammoud >Assignee: Gary Tully >Priority: Major > Fix For: 2.16.0 > > Attachments: TestWildCard.java > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Hello, > I see negative address size in JMX. This happens when there are two > consumers. One listening on the full topic name. The other listening on the > wild card topic. I can easily reproduce with this. [^TestWildCard.java] > ^Broker shows:^ > ^2020-05-17 09:24:34,826 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-152.^ > ^2020-05-17 09:24:34,827 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-88.^ > ^2020-05-17 09:24:34,828 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-944.^ > ^2020-05-17 09:24:34,828 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-1,800.^ > ^2020-05-17 09:24:34,829 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-1,736.^ > ^2020-05-17 09:24:34,829 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-2,592.^ > ^2020-05-17 09:24:34,829 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-3,448.^ > ^2020-05-17 09:24:34,830 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-4,304.^ > ^2020-05-17 09:24:34,830 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-5,160.^ > ^2020-05-17 09:24:34,830 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-5,096.^ > ^2020-05-17 09:24:34,831 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-5,952.^ > ^2020-05-17 09:24:34,831 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-6,016.^ > ^2020-05-17 09:24:34,832 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-6,080.^ > ^2020-05-17 09:24:34,832 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-6,016.^ > ^2020-05-17 09:24:34,832 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-6,872.^ > ^2020-05-17 09:24:34,832 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-7,728.^ > ^2020-05-17 09:24:34,833 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-8,584.^ > ^2020-05-17 09:24:34,833 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=
[jira] [Work logged] (ARTEMIS-2888) MQTT spec violation when subscribed to wildcard topic
[ https://issues.apache.org/jira/browse/ARTEMIS-2888?focusedWorklogId=490744&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-490744 ] ASF GitHub Bot logged work on ARTEMIS-2888: --- Author: ASF GitHub Bot Created on: 25/Sep/20 13:08 Start Date: 25/Sep/20 13:08 Worklog Time Spent: 10m Work Description: gtully merged pull request #3265: URL: https://github.com/apache/activemq-artemis/pull/3265 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 490744) Time Spent: 1h 40m (was: 1.5h) > MQTT spec violation when subscribed to wildcard topic > - > > Key: ARTEMIS-2888 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2888 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: MQTT >Affects Versions: 2.14.0 > Environment: *Message Producer:* > MQTTnet Client > published Message to > 0e5ed50e-ccea-4a42-8c3e-db0e2780222b/from-smart-acquisition-device/machine-state/event/off > > *Message Consumer:* > MQTT Paho Java Client, also tested with HiveMQ Java Client. > Subscribed to +/from-smart-acquisition-device/machine-state/event/off >Reporter: Florian Meister >Assignee: Gary Tully >Priority: Major > Fix For: 2.16.0 > > Attachments: image-2020-08-27-12-37-01-479.png > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Sometimes the topic name of published messages contains the topic filter > instead of the topic name. > This is neither correct nor allowed in the MQTT 3.1.1 specification: > [http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718106] > > Below a screenshot of an example MQTT Packet sent from the Artemis Broker > !image-2020-08-27-12-37-01-479.png! > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2915) Duplicate temp queues using OpenWire
[
https://issues.apache.org/jira/browse/ARTEMIS-2915?focusedWorklogId=490734&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-490734
]
ASF GitHub Bot logged work on ARTEMIS-2915:
---
Author: ASF GitHub Bot
Created on: 25/Sep/20 13:07
Start Date: 25/Sep/20 13:07
Worklog Time Spent: 10m
Work Description: asfgit closed pull request #3276:
URL: https://github.com/apache/activemq-artemis/pull/3276
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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: 490734)
Time Spent: 0.5h (was: 20m)
> Duplicate temp queues using OpenWire
>
>
> Key: ARTEMIS-2915
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2915
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When using OpenWire and creating/closing multiple different producers on the
> same temporary queue the broker will store (i.e. duplicate) the same
> temporary queue in its internal data structures. This was originally
> discovered using the [ActiveMQ Camel
> component|https://camel.apache.org/components/latest/activemq-component.html]
> with an {{InOut}} exchange pattern.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2823) Improve JDBC connection management
[ https://issues.apache.org/jira/browse/ARTEMIS-2823?focusedWorklogId=490703&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-490703 ] ASF GitHub Bot logged work on ARTEMIS-2823: --- Author: ASF GitHub Bot Created on: 25/Sep/20 12:34 Start Date: 25/Sep/20 12:34 Worklog Time Spent: 10m Work Description: uomik edited a comment on pull request #3204: URL: https://github.com/apache/activemq-artemis/pull/3204#issuecomment-698902202 @franz1981 > I've just one concern looking at the default pool configuration: the number of available JDBC connections in the pool and the behaviour when there are none available. > > I see that paging + large messsages can use an unbounded number of connections (it really depends by the amount of concurrent threads that perform page/large msg streaming operations), the 2 journals requires 1 connections each (binding + message journal) and the node manager requires 2 (the lease lock + the node manager shared state) connections. > That means that without paging or large messages a minimum of 2 + 2 = 4 database connections. > The problem I see is paging and large messages: if the are too many some of the other operations will hang, awaiting an available connection, that means that probably we need to add the critical analyzer there or just let users knows they can configure pool appropriately. Getting back to this. We've lately opened our test cluster for "external" clients, this has increased load and amount of transactions quite a lot. As a result we've quite frequently seen an event where master restarts due to issues with live locks. We are still using default settings for the pool and I'm suspecting that this may actually be a result of DB connection starvation. I will experiment with pool settings next week and will hopefully find something to overcome this issue. ``` 2020-09-25 11:53:10,958 WARN [org.apache.activemq.artemis.core.server] AMQ222010: Critical IO Error, shutting down the server. file=NULL, message=Critical error while on live renew: java.lang.IllegalStateException: live lock can't be renewed at org.apache.activemq.artemis.core.server.impl.jdbc.ActiveMQScheduledLeaseLock.run(ActiveMQScheduledLeaseLock.java:92) [artemis-server-2.13.0.jar:2.13.0] at org.apache.activemq.artemis.core.server.ActiveMQScheduledComponent$2.run(ActiveMQScheduledComponent.java:306) [artemis-commons-2.13.0.jar:2.13.0] at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) [artemis-commons-2.13.0.jar:2.13.0] at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) [artemis-commons-2.13.0.jar:2.13.0] at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65) [artemis-commons-2.13.0.jar:2.13.0] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_221] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_221] at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) [artemis-commons-2.13.0.jar:2.13.0] 2020-09-25 11:53:10,981 ERROR [org.apache.activemq.artemis.core.server.impl.jdbc.ActiveMQScheduledLeaseLock] live lock renew tooks 39255 ms, while is supposed to take <4000 ms ``` This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 490703) Time Spent: 10.5h (was: 10h 20m) > Improve JDBC connection management > -- > > Key: ARTEMIS-2823 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2823 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Mikko >Priority: Major > Time Spent: 10.5h > Remaining Estimate: 0h > > I have a case where the whole clustering reliability and HA must rely on HA > capabilities of clustered database, and running on top of application server > is not an option. > The current JDBC store implementation is rather bare bones on the connection > management side. JDBC driver is used directly with no management layer. At > startup, the broker just opens couple of direct connections to database and > expects them to be available forever. This is something that cannot be > expected in HA production environment. So, similarly to the discussion linked > below, in our case we
[jira] [Work logged] (ARTEMIS-2823) Improve JDBC connection management
[ https://issues.apache.org/jira/browse/ARTEMIS-2823?focusedWorklogId=490702&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-490702 ] ASF GitHub Bot logged work on ARTEMIS-2823: --- Author: ASF GitHub Bot Created on: 25/Sep/20 12:33 Start Date: 25/Sep/20 12:33 Worklog Time Spent: 10m Work Description: uomik commented on pull request #3204: URL: https://github.com/apache/activemq-artemis/pull/3204#issuecomment-698902202 @franz1981 > I've just one concern looking at the default pool configuration: the number of available JDBC connections in the pool and the behaviour when there are none available. > > I see that paging + large messsages can use an unbounded number of connections (it really depends by the amount of concurrent threads that perform page/large msg streaming operations), the 2 journals requires 1 connections each (binding + message journal) and the node manager requires 2 (the lease lock + the node manager shared state) connections. > That means that without paging or large messages a minimum of 2 + 2 = 4 database connections. > The problem I see is paging and large messages: if the are too many some of the other operations will hang, awaiting an available connection, that means that probably we need to add the critical analyzer there or just let users knows they can configure pool appropriately. Getting back to this. We've lately opened our test cluster for "external" clients, this has increased load and amount of transactions quite a lot. As a result we've quite frequently seen an event where master restarts due to issues with live locks. We are still using default settings for the pool and I'm suspecting that this may actually be a result of DB connection starvation. I will experiment with pool settings next week and will hopefully find something to overcome this issue. `2020-09-25 11:53:10,958 WARN [org.apache.activemq.artemis.core.server] AMQ222010: Critical IO Error, shutting down the server. file=NULL, message=Critical error while on live renew: java.lang.IllegalStateException: live lock can't be renewed at org.apache.activemq.artemis.core.server.impl.jdbc.ActiveMQScheduledLeaseLock.run(ActiveMQScheduledLeaseLock.java:92) [artemis-server-2.13.0.jar:2.13.0] at org.apache.activemq.artemis.core.server.ActiveMQScheduledComponent$2.run(ActiveMQScheduledComponent.java:306) [artemis-commons-2.13.0.jar:2.13.0] at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) [artemis-commons-2.13.0.jar:2.13.0] at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) [artemis-commons-2.13.0.jar:2.13.0] at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65) [artemis-commons-2.13.0.jar:2.13.0] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_221] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_221] at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) [artemis-commons-2.13.0.jar:2.13.0] 2020-09-25 11:53:10,981 ERROR [org.apache.activemq.artemis.core.server.impl.jdbc.ActiveMQScheduledLeaseLock] live lock renew tooks 39255 ms, while is supposed to take <4000 ms` This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 490702) Time Spent: 10h 20m (was: 10h 10m) > Improve JDBC connection management > -- > > Key: ARTEMIS-2823 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2823 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Mikko >Priority: Major > Time Spent: 10h 20m > Remaining Estimate: 0h > > I have a case where the whole clustering reliability and HA must rely on HA > capabilities of clustered database, and running on top of application server > is not an option. > The current JDBC store implementation is rather bare bones on the connection > management side. JDBC driver is used directly with no management layer. At > startup, the broker just opens couple of direct connections to database and > expects them to be available forever. This is something that cannot be > expected in HA production environment. So, similarly to the discussion linked > below, in our case we lose the db co
[jira] [Work logged] (ARTEMIS-2908) Persist Divert Configuration in Bindings journal
[ https://issues.apache.org/jira/browse/ARTEMIS-2908?focusedWorklogId=490649&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-490649 ] ASF GitHub Bot logged work on ARTEMIS-2908: --- Author: ASF GitHub Bot Created on: 25/Sep/20 09:28 Start Date: 25/Sep/20 09:28 Worklog Time Spent: 10m Work Description: andytaylor commented on a change in pull request #3278: URL: https://github.com/apache/activemq-artemis/pull/3278#discussion_r494864910 ## File path: artemis-core-client/src/main/java/org/apache/activemq/artemis/utils/BufferHelper.java ## @@ -16,8 +16,10 @@ */ package org.apache.activemq.artemis.utils; +import io.netty.buffer.ByteBufUtil; import org.apache.activemq.artemis.api.core.ActiveMQBuffer; Review comment: fixed This is an automated message from the Apache Git Service. To respond to the message, please log on to 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: 490649) Time Spent: 50m (was: 40m) > Persist Divert Configuration in Bindings journal > > > Key: ARTEMIS-2908 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2908 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Andy Taylor >Assignee: Andy Taylor >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
