[jira] [Commented] (ACTIVEMQ6-4) Rename packages to ActiveMQ
[ https://issues.apache.org/jira/browse/ACTIVEMQ6-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14214440#comment-14214440 ] Andy Taylor commented on ACTIVEMQ6-4: - Im busy renaming all the distribution files and scripts etc. i will also do all the config names Rename packages to ActiveMQ --- Key: ACTIVEMQ6-4 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-4 Project: Apache ActiveMQ 6 Issue Type: Improvement Reporter: Martyn Taylor Assignee: clebert suconic Fix For: 6.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACTIVEMQ6-4) Rename packages to ActiveMQ
[ https://issues.apache.org/jira/browse/ACTIVEMQ6-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14214492#comment-14214492 ] Andy Taylor commented on ACTIVEMQ6-4: - I'm also going to rename the schemas and change the urn's etc and rename all the configs, rather than hornetq-configuration use activemq.xml, thoughts? Clebert, what do you think about removing this autogen of the defaults class from the schema, its broken anyway with the weay we use ha-policy, i can just add it and rename it. Rename packages to ActiveMQ --- Key: ACTIVEMQ6-4 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-4 Project: Apache ActiveMQ 6 Issue Type: Improvement Reporter: Martyn Taylor Assignee: clebert suconic Fix For: 6.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACTIVEMQ6-4) Rename packages to ActiveMQ
[ https://issues.apache.org/jira/browse/ACTIVEMQ6-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14214688#comment-14214688 ] clebert suconic commented on ACTIVEMQ6-4: - +1 about the autogen on the defaults... Rename packages to ActiveMQ --- Key: ACTIVEMQ6-4 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-4 Project: Apache ActiveMQ 6 Issue Type: Improvement Reporter: Martyn Taylor Assignee: clebert suconic Fix For: 6.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACTIVEMQ6-4) Rename packages to ActiveMQ
[ https://issues.apache.org/jira/browse/ACTIVEMQ6-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14214695#comment-14214695 ] clebert suconic commented on ACTIVEMQ6-4: - I just pushed a commit with renaming the packages to activemq: https://github.com/apache/activemq-6/pull/9 I had to make two commits otherwise the history would be lost (remove / adding new files). Rename packages to ActiveMQ --- Key: ACTIVEMQ6-4 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-4 Project: Apache ActiveMQ 6 Issue Type: Improvement Reporter: Martyn Taylor Assignee: clebert suconic Fix For: 6.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: PR Process on github.com/activemq6 repo
updated the infra ticket to request the hooks - https://issues.apache.org/jira/browse/INFRA-8485?focusedCommentId=14214758page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14214758 On 13 November 2014 12:14, Daniel Kulp dk...@apache.org wrote: It looks like when Hiram asked for the activemq-6 GIT repo to be created, he didn’t specifically ask for all the github integration hooks to be installed. The pull requests should have been sending email to this list. It should be commenting on the JIRA’s automatically. I don’t think the log message thing to close the issues will work either. Hiram: can you file another request with infra to have them enable the complete set of github integration hooks for the activemq-6 repo with notices and such going to dev@activemq.apache.org? Dan On Nov 12, 2014, at 11:21 AM, Clebert Suconic clebert.suco...@gmail.com wrote: I would like us to use the pull request approach on github.com/apache/activemq-6. To me that's a no brainer... PR commits is the best approach... simpler to handle, review.. and you could even get tests working to validate the changes are consistent and accurate with the testsuite. It really improves collaboration with anyone interested in contribute code. However, We have a two issues to get sorted to make that work: I - PR builds We will need a bot user that would have push authorization on the mirror: https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin II - Authorization for committers to close PRs. We will merge PRs manually but we still need a way to close PRs when we reject issues. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[jira] [Commented] (ACTIVEMQ6-14) Replace naming server with ActiveMQ client JNDI
[ https://issues.apache.org/jira/browse/ACTIVEMQ6-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14214797#comment-14214797 ] Martyn Taylor commented on ACTIVEMQ6-14: As part of this task please ensure that the appropriate deps are removed from the poms i.e: groupIdorg.jboss.naming/groupId artifactIdjnpserver/artifactId Replace naming server with ActiveMQ client JNDI --- Key: ACTIVEMQ6-14 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-14 Project: Apache ActiveMQ 6 Issue Type: Improvement Reporter: Martyn Taylor Fix For: 6.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACTIVEMQ6-6) Extract any JBoss SPI code replace with generic
[ https://issues.apache.org/jira/browse/ACTIVEMQ6-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14214808#comment-14214808 ] Martyn Taylor commented on ACTIVEMQ6-6: --- According to the pom.xml there are one or two cases where the SPIs are being used outside of the RA: I've pasted excerpt below. This task should encompass removing these SPIs in addition to removing those used in the RA. !--this specifically for the JMS Bridge-- dependency groupIdorg.jboss/groupId artifactIdjboss-transaction-spi/artifactId version7.0.0.Final/version exclusions exclusion groupIdorg.jboss.logging/groupId artifactIdjboss-logging-spi/artifactId /exclusion /exclusions /dependency Extract any JBoss SPI code replace with generic --- Key: ACTIVEMQ6-6 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-6 Project: Apache ActiveMQ 6 Issue Type: Improvement Reporter: Martyn Taylor Fix For: 6.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5440) KahaDB error at startup Looking for key N but not found in fileMap
Jesse Fugitt created AMQ-5440:
-
Summary: KahaDB error at startup Looking for key N but not found
in fileMap
Key: AMQ-5440
URL: https://issues.apache.org/jira/browse/AMQ-5440
Project: ActiveMQ
Issue Type: Bug
Components: Message Store
Affects Versions: 5.10.0
Reporter: Jesse Fugitt
Priority: Critical
After being shutdown uncleanly, KahaDB can hit a startup error at times that
causes the broker to fail to start up and potentially causes messages to be
re-assigned that are not marked as redelivered.
The log message at startup is:
2014-11-17 11:10:36,826 | ERROR | Looking for key 275 but not found in fileMap:
{305=db-305.log number = 305 , length = 8217, 304=db-304.log number = 304 ,
length = 8217, 307=db-307.log number = 307 , length = 8217, 306=db-306.log
number = 306 , length = 8217, 309=db-309.log number = 309 , length = 8217,
308=db-308.log number = 308 , length = 8217, 311=db-311.log number = 311 ,
length = 8217, 310=db-310.log number = 310 , length = 8217, 313=db-313.log
number = 313 , length = 8217, 312=db-312.log number = 312 , length = 8217,
314=db-314.log number = 314 , length = 317, 303=db-303.log number = 303 ,
length = 8433} | org.apache.activemq.store.kahadb.disk.journal.Journal | main
and the stack trace is:
Starting TestApp...
INFO | KahaDB is version 5
ERROR | Looking for key 275 but not found in fileMap: {305=db-305.log number =
305 , length = 8217, 304=db-304.log number = 304 , length = 8217,
307=db-307.log number = 307 , length = 8217, 306=db-306.log number = 306 ,
length = 8217, 309=db-309.log number = 309 , length = 8217, 308=db-308.log
number = 308 , length = 8217, 311=db-311.log number = 311 , length = 8217,
310=db-310.log number = 310 , length = 8217, 313=db-313.log number = 313 ,
length = 8217, 312=db-312.log number = 312 , length = 8217, 314=db-314.log
number = 314 , length = 317, 303=db-303.log number = 303 , length = 8433}
Exception in thread main java.io.IOException: Could not locate data file
KahaDB\db-275.log
at
org.apache.activemq.store.kahadb.disk.journal.Journal.getDataFile(Journal.java:353)
at
org.apache.activemq.store.kahadb.disk.journal.Journal.read(Journal.java:600)
at
org.apache.activemq.store.kahadb.MessageDatabase.load(MessageDatabase.java:1014)
at
org.apache.activemq.store.kahadb.MessageDatabase.recoverProducerAudit(MessageDatabase.java:687)
at
org.apache.activemq.store.kahadb.MessageDatabase.recover(MessageDatabase.java:595)
at
org.apache.activemq.store.kahadb.MessageDatabase.open(MessageDatabase.java:400)
at
org.apache.activemq.store.kahadb.MessageDatabase.load(MessageDatabase.java:418)
at
org.apache.activemq.store.kahadb.MessageDatabase.doStart(MessageDatabase.java:262)
at
org.apache.activemq.store.kahadb.KahaDBStore.doStart(KahaDBStore.java:194)
at org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55)
at
org.apache.activemq.store.kahadb.KahaDBPersistenceAdapter.doStart(KahaDBPersistenceAdapter.java:215)
at org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55)
at kahadbtest.TestApp.run(TestApp.java:29)
at kahadbtest.TestApp.main(TestApp.java:21)
This was fairly hard to reproduce without unclean shutdown but the attached log
and broken KahaDB folder should help debug the problem. Also, I will attach
the small test app that exercises the KahaDB APIs that I was using to cause the
invalid state (I normally start and stop the app a few times until the problem
appears at startup at which point it will no longer start).
Some initial debugging looks like it might be related to the way that message
acks are stored via the metadata serialization and how that interacts with the
GC timer but I didn't see anything obvious.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5440) KahaDB error at startup Looking for key N but not found in fileMap
[
https://issues.apache.org/jira/browse/AMQ-5440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Fugitt updated AMQ-5440:
--
Attachment: KahaDB.zip
kahadbtest.log
Broker KahaDB folder that causes startup error and TRACE level log showing the
GC records that caused it.
KahaDB error at startup Looking for key N but not found in fileMap
Key: AMQ-5440
URL: https://issues.apache.org/jira/browse/AMQ-5440
Project: ActiveMQ
Issue Type: Bug
Components: Message Store
Affects Versions: 5.10.0
Reporter: Jesse Fugitt
Priority: Critical
Attachments: KahaDB.zip, kahadbtest.log
After being shutdown uncleanly, KahaDB can hit a startup error at times that
causes the broker to fail to start up and potentially causes messages to be
re-assigned that are not marked as redelivered.
The log message at startup is:
2014-11-17 11:10:36,826 | ERROR | Looking for key 275 but not found in
fileMap: {305=db-305.log number = 305 , length = 8217, 304=db-304.log number
= 304 , length = 8217, 307=db-307.log number = 307 , length = 8217,
306=db-306.log number = 306 , length = 8217, 309=db-309.log number = 309 ,
length = 8217, 308=db-308.log number = 308 , length = 8217, 311=db-311.log
number = 311 , length = 8217, 310=db-310.log number = 310 , length = 8217,
313=db-313.log number = 313 , length = 8217, 312=db-312.log number = 312 ,
length = 8217, 314=db-314.log number = 314 , length = 317, 303=db-303.log
number = 303 , length = 8433} |
org.apache.activemq.store.kahadb.disk.journal.Journal | main
and the stack trace is:
Starting TestApp...
INFO | KahaDB is version 5
ERROR | Looking for key 275 but not found in fileMap: {305=db-305.log number
= 305 , length = 8217, 304=db-304.log number = 304 , length = 8217,
307=db-307.log number = 307 , length = 8217, 306=db-306.log number = 306 ,
length = 8217, 309=db-309.log number = 309 , length = 8217, 308=db-308.log
number = 308 , length = 8217, 311=db-311.log number = 311 , length = 8217,
310=db-310.log number = 310 , length = 8217, 313=db-313.log number = 313 ,
length = 8217, 312=db-312.log number = 312 , length = 8217, 314=db-314.log
number = 314 , length = 317, 303=db-303.log number = 303 , length = 8433}
Exception in thread main java.io.IOException: Could not locate data file
KahaDB\db-275.log
at
org.apache.activemq.store.kahadb.disk.journal.Journal.getDataFile(Journal.java:353)
at
org.apache.activemq.store.kahadb.disk.journal.Journal.read(Journal.java:600)
at
org.apache.activemq.store.kahadb.MessageDatabase.load(MessageDatabase.java:1014)
at
org.apache.activemq.store.kahadb.MessageDatabase.recoverProducerAudit(MessageDatabase.java:687)
at
org.apache.activemq.store.kahadb.MessageDatabase.recover(MessageDatabase.java:595)
at
org.apache.activemq.store.kahadb.MessageDatabase.open(MessageDatabase.java:400)
at
org.apache.activemq.store.kahadb.MessageDatabase.load(MessageDatabase.java:418)
at
org.apache.activemq.store.kahadb.MessageDatabase.doStart(MessageDatabase.java:262)
at
org.apache.activemq.store.kahadb.KahaDBStore.doStart(KahaDBStore.java:194)
at org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55)
at
org.apache.activemq.store.kahadb.KahaDBPersistenceAdapter.doStart(KahaDBPersistenceAdapter.java:215)
at org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55)
at kahadbtest.TestApp.run(TestApp.java:29)
at kahadbtest.TestApp.main(TestApp.java:21)
This was fairly hard to reproduce without unclean shutdown but the attached
log and broken KahaDB folder should help debug the problem. Also, I will
attach the small test app that exercises the KahaDB APIs that I was using to
cause the invalid state (I normally start and stop the app a few times until
the problem appears at startup at which point it will no longer start).
Some initial debugging looks like it might be related to the way that message
acks are stored via the metadata serialization and how that interacts with
the GC timer but I didn't see anything obvious.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5440) KahaDB error at startup Looking for key N but not found in fileMap
[
https://issues.apache.org/jira/browse/AMQ-5440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Fugitt updated AMQ-5440:
--
Attachment: TestApp.java
Test app used to hit KahaDB error by causing many add/update/remove APIs while
db-log files are being deleted.
KahaDB error at startup Looking for key N but not found in fileMap
Key: AMQ-5440
URL: https://issues.apache.org/jira/browse/AMQ-5440
Project: ActiveMQ
Issue Type: Bug
Components: Message Store
Affects Versions: 5.10.0
Reporter: Jesse Fugitt
Priority: Critical
Attachments: KahaDB.zip, TestApp.java, kahadbtest.log
After being shutdown uncleanly, KahaDB can hit a startup error at times that
causes the broker to fail to start up and potentially causes messages to be
re-assigned that are not marked as redelivered.
The log message at startup is:
2014-11-17 11:10:36,826 | ERROR | Looking for key 275 but not found in
fileMap: {305=db-305.log number = 305 , length = 8217, 304=db-304.log number
= 304 , length = 8217, 307=db-307.log number = 307 , length = 8217,
306=db-306.log number = 306 , length = 8217, 309=db-309.log number = 309 ,
length = 8217, 308=db-308.log number = 308 , length = 8217, 311=db-311.log
number = 311 , length = 8217, 310=db-310.log number = 310 , length = 8217,
313=db-313.log number = 313 , length = 8217, 312=db-312.log number = 312 ,
length = 8217, 314=db-314.log number = 314 , length = 317, 303=db-303.log
number = 303 , length = 8433} |
org.apache.activemq.store.kahadb.disk.journal.Journal | main
and the stack trace is:
Starting TestApp...
INFO | KahaDB is version 5
ERROR | Looking for key 275 but not found in fileMap: {305=db-305.log number
= 305 , length = 8217, 304=db-304.log number = 304 , length = 8217,
307=db-307.log number = 307 , length = 8217, 306=db-306.log number = 306 ,
length = 8217, 309=db-309.log number = 309 , length = 8217, 308=db-308.log
number = 308 , length = 8217, 311=db-311.log number = 311 , length = 8217,
310=db-310.log number = 310 , length = 8217, 313=db-313.log number = 313 ,
length = 8217, 312=db-312.log number = 312 , length = 8217, 314=db-314.log
number = 314 , length = 317, 303=db-303.log number = 303 , length = 8433}
Exception in thread main java.io.IOException: Could not locate data file
KahaDB\db-275.log
at
org.apache.activemq.store.kahadb.disk.journal.Journal.getDataFile(Journal.java:353)
at
org.apache.activemq.store.kahadb.disk.journal.Journal.read(Journal.java:600)
at
org.apache.activemq.store.kahadb.MessageDatabase.load(MessageDatabase.java:1014)
at
org.apache.activemq.store.kahadb.MessageDatabase.recoverProducerAudit(MessageDatabase.java:687)
at
org.apache.activemq.store.kahadb.MessageDatabase.recover(MessageDatabase.java:595)
at
org.apache.activemq.store.kahadb.MessageDatabase.open(MessageDatabase.java:400)
at
org.apache.activemq.store.kahadb.MessageDatabase.load(MessageDatabase.java:418)
at
org.apache.activemq.store.kahadb.MessageDatabase.doStart(MessageDatabase.java:262)
at
org.apache.activemq.store.kahadb.KahaDBStore.doStart(KahaDBStore.java:194)
at org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55)
at
org.apache.activemq.store.kahadb.KahaDBPersistenceAdapter.doStart(KahaDBPersistenceAdapter.java:215)
at org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55)
at kahadbtest.TestApp.run(TestApp.java:29)
at kahadbtest.TestApp.main(TestApp.java:21)
This was fairly hard to reproduce without unclean shutdown but the attached
log and broken KahaDB folder should help debug the problem. Also, I will
attach the small test app that exercises the KahaDB APIs that I was using to
cause the invalid state (I normally start and stop the app a few times until
the problem appears at startup at which point it will no longer start).
Some initial debugging looks like it might be related to the way that message
acks are stored via the metadata serialization and how that interacts with
the GC timer but I didn't see anything obvious.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMQ-5441) PersistanceAdapter returns all Durable Subscriptions - this does not scale at all when durable subscribers are used
Curt Jutzi created AMQ-5441: --- Summary: PersistanceAdapter returns all Durable Subscriptions - this does not scale at all when durable subscribers are used Key: AMQ-5441 URL: https://issues.apache.org/jira/browse/AMQ-5441 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.11.0 Reporter: Curt Jutzi In the PersistenceAdapter for the broker, you'll see the call getDestinations() which is used (At least in MQTT) on each connect to see if the connecting client has any subscriptions. The issue is that getDesitinations() returns all durable subscriptions. We have an environment which has status / state which are retained, as well, each client supports 10 durable subscriptions. With 10 K client connections this implies a dip into the DB which will return 80 bytes for each DESTINATION in the data base * 10K or 8 Meg on each connect. This needs to be filtered in the DB query since you are not looking for other clientids. All PersistenceAdaptors implemented have this issue. I have modified the all the DB adaptors to support a new method called getDestinations(String client_id). I have also modified the JDBC query to support a query which is specific to a given client-id and does not need to loop through all (thousands of ) connections filtering the client_id in the code.. (see PersistenceAdapterSupport.listSubscriptions()).. I've also attached a JUnit test which demos the issue using derbyDb.. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5441) PersistanceAdapter returns all Durable Subscriptions - this does not scale at all when durable subscribers are used
[ https://issues.apache.org/jira/browse/AMQ-5441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Curt Jutzi updated AMQ-5441: Attachment: Junit_PersistanceAdapterIssue_IntelCjutzi.java apache-activemq_activemq-jdbc-store_Statements.patch apache-activemq_activemq-jdbc-store_JDBCAdapter.patch apache-activemq_activemq-jdbc-store_DefaultJDBCAdapter.patch apache-activemq_activemq-broker_PersistenceAdapter.patch apache-activemq_activemq-broker_PersistenceAdapterSupport.patch apache-activemq_activemq-store_KahaDBPersistenceAdapter.patch includes patches and JUnit test.. I did not include LevelDB patch PersistanceAdapter returns all Durable Subscriptions - this does not scale at all when durable subscribers are used Key: AMQ-5441 URL: https://issues.apache.org/jira/browse/AMQ-5441 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.11.0 Reporter: Curt Jutzi Attachments: Junit_PersistanceAdapterIssue_IntelCjutzi.java, apache-activemq_activemq-broker_PersistenceAdapter.patch, apache-activemq_activemq-broker_PersistenceAdapterSupport.patch, apache-activemq_activemq-jdbc-store_DefaultJDBCAdapter.patch, apache-activemq_activemq-jdbc-store_JDBCAdapter.patch, apache-activemq_activemq-jdbc-store_Statements.patch, apache-activemq_activemq-store_KahaDBPersistenceAdapter.patch Original Estimate: 48h Remaining Estimate: 48h In the PersistenceAdapter for the broker, you'll see the call getDestinations() which is used (At least in MQTT) on each connect to see if the connecting client has any subscriptions. The issue is that getDesitinations() returns all durable subscriptions. We have an environment which has status / state which are retained, as well, each client supports 10 durable subscriptions. With 10 K client connections this implies a dip into the DB which will return 80 bytes for each DESTINATION in the data base * 10K or 8 Meg on each connect. This needs to be filtered in the DB query since you are not looking for other clientids. All PersistenceAdaptors implemented have this issue. I have modified the all the DB adaptors to support a new method called getDestinations(String client_id). I have also modified the JDBC query to support a query which is specific to a given client-id and does not need to loop through all (thousands of ) connections filtering the client_id in the code.. (see PersistenceAdapterSupport.listSubscriptions()).. I've also attached a JUnit test which demos the issue using derbyDb.. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5442) NullPointerException in SimpleDiscoveryEvent on Shutdown
John Arnesen created AMQ-5442:
-
Summary: NullPointerException in SimpleDiscoveryEvent on Shutdown
Key: AMQ-5442
URL: https://issues.apache.org/jira/browse/AMQ-5442
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.10.0
Reporter: John Arnesen
If startup of a broker fails when using SimpleDiscoveryAgent, then you will
encounter a NullPointerException on shutdown because the TaskRunnerFactory
instance is created during startup and there is no check to ensure it was
created before attempting the shutdown:
{quote}
org.apache.activemq.network.DiscoveryNetworkConnector Could not stop service:
DiscoveryNetworkConnector:NC:BrokerService[...]. Reason:
java.lang.NullPointerException
at
org.apache.activemq.transport.discovery.simple.SimpleDiscoveryAgent.stop(SimpleDiscoveryAgent.java:96)
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5441) PersistanceAdapter returns all Durable Subscriptions - this does not scale at all when durable subscribers are used
[ https://issues.apache.org/jira/browse/AMQ-5441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Curt Jutzi updated AMQ-5441: Attachment: apache-activemq_activemq-broker_Memory.patch PersistanceAdapter returns all Durable Subscriptions - this does not scale at all when durable subscribers are used Key: AMQ-5441 URL: https://issues.apache.org/jira/browse/AMQ-5441 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.11.0 Reporter: Curt Jutzi Attachments: Junit_PersistanceAdapterIssue_IntelCjutzi.java, apache-activemq_activemq-broker_Memory.patch, apache-activemq_activemq-broker_PersistenceAdapter.patch, apache-activemq_activemq-broker_PersistenceAdapterSupport.patch, apache-activemq_activemq-jdbc-store_DefaultJDBCAdapter.patch, apache-activemq_activemq-jdbc-store_JDBCAdapter.patch, apache-activemq_activemq-jdbc-store_Statements.patch, apache-activemq_activemq-store_KahaDBPersistenceAdapter.patch Original Estimate: 48h Remaining Estimate: 48h In the PersistenceAdapter for the broker, you'll see the call getDestinations() which is used (At least in MQTT) on each connect to see if the connecting client has any subscriptions. The issue is that getDesitinations() returns all durable subscriptions. We have an environment which has status / state which are retained, as well, each client supports 10 durable subscriptions. With 10 K client connections this implies a dip into the DB which will return 80 bytes for each DESTINATION in the data base * 10K or 8 Meg on each connect. This needs to be filtered in the DB query since you are not looking for other clientids. All PersistenceAdaptors implemented have this issue. I have modified the all the DB adaptors to support a new method called getDestinations(String client_id). I have also modified the JDBC query to support a query which is specific to a given client-id and does not need to loop through all (thousands of ) connections filtering the client_id in the code.. (see PersistenceAdapterSupport.listSubscriptions()).. I've also attached a JUnit test which demos the issue using derbyDb.. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ACTIVEMQ6-36) Disallow use of SSLv3 to protect against POODLE
Justin Bertram created ACTIVEMQ6-36: --- Summary: Disallow use of SSLv3 to protect against POODLE Key: ACTIVEMQ6-36 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-36 Project: Apache ActiveMQ 6 Issue Type: Bug Reporter: Justin Bertram Assignee: Justin Bertram Fix For: 6.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ACTIVEMQ6-37) NoSuchMethodError during init
Justin Bertram created ACTIVEMQ6-37: --- Summary: NoSuchMethodError during init Key: ACTIVEMQ6-37 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-37 Project: Apache ActiveMQ 6 Issue Type: Bug Reporter: Justin Bertram Assignee: Justin Bertram Fix For: 6.0.0 When compiled by JDK 8 targeting Java 6 and then run on JDK 6 or 7 the ConcurrentHashMap#keyset() method can fail because the return types changed in Java 8. Using ConcurrentMap interface to resolve the issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ACTIVEMQ6-38) Overzealous logging for missing queue
Justin Bertram created ACTIVEMQ6-38: --- Summary: Overzealous logging for missing queue Key: ACTIVEMQ6-38 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-38 Project: Apache ActiveMQ 6 Issue Type: Bug Affects Versions: 6.0.0 Reporter: Justin Bertram Assignee: Justin Bertram -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (ACTIVEMQ6-36) Disallow use of SSLv3 to protect against POODLE
[ https://issues.apache.org/jira/browse/ACTIVEMQ6-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram closed ACTIVEMQ6-36. --- Resolution: Fixed https://github.com/apache/activemq-6/commit/36d86ffb00f6f152ed6daf7cf16f6f1556573ba7 Disallow use of SSLv3 to protect against POODLE --- Key: ACTIVEMQ6-36 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-36 Project: Apache ActiveMQ 6 Issue Type: Bug Reporter: Justin Bertram Assignee: Justin Bertram Fix For: 6.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (ACTIVEMQ6-37) NoSuchMethodError during init
[ https://issues.apache.org/jira/browse/ACTIVEMQ6-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram closed ACTIVEMQ6-37. --- Resolution: Fixed https://github.com/apache/activemq-6/commit/8fcf81f5f7a59478a67d9a042c9456bffef58ca6 NoSuchMethodError during init - Key: ACTIVEMQ6-37 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-37 Project: Apache ActiveMQ 6 Issue Type: Bug Reporter: Justin Bertram Assignee: Justin Bertram Fix For: 6.0.0 When compiled by JDK 8 targeting Java 6 and then run on JDK 6 or 7 the ConcurrentHashMap#keyset() method can fail because the return types changed in Java 8. Using ConcurrentMap interface to resolve the issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ACTIVEMQ6-38) Overzealous logging for missing queue
[ https://issues.apache.org/jira/browse/ACTIVEMQ6-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ACTIVEMQ6-38: Affects Version/s: (was: 6.0.0) Fix Version/s: 6.0.0 Overzealous logging for missing queue - Key: ACTIVEMQ6-38 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-38 Project: Apache ActiveMQ 6 Issue Type: Bug Reporter: Justin Bertram Assignee: Justin Bertram Fix For: 6.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (ACTIVEMQ6-38) Overzealous logging for missing queue
[ https://issues.apache.org/jira/browse/ACTIVEMQ6-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram closed ACTIVEMQ6-38. --- Resolution: Fixed https://github.com/apache/activemq-6/commit/2d9125a7c61999ed2aaa7c14d0fd3fe2b9a5d19d Overzealous logging for missing queue - Key: ACTIVEMQ6-38 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-38 Project: Apache ActiveMQ 6 Issue Type: Bug Reporter: Justin Bertram Assignee: Justin Bertram Fix For: 6.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ACTIVEMQ6-9) Fix Documentation to remove any non ActiveMQ references / branding
[ https://issues.apache.org/jira/browse/ACTIVEMQ6-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reassigned ACTIVEMQ6-9: -- Assignee: Justin Bertram Fix Documentation to remove any non ActiveMQ references / branding -- Key: ACTIVEMQ6-9 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-9 Project: Apache ActiveMQ 6 Issue Type: Improvement Reporter: Martyn Taylor Assignee: Justin Bertram Fix For: 6.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
