[jira] Resolved: (AMQ-1114) ActiveMQ Queue management- How to kill a queue?
[ https://issues.apache.org/activemq/browse/AMQ-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] james strachan resolved AMQ-1114. - Resolution: Fixed Fix Version/s: 4.1.0 See the methods on the Queue MBean such as purge() to delete all messages on a queue http://incubator.apache.org/activemq/maven/activemq-core/apidocs/org/apache/activemq/broker/jmx/QueueViewMBean.html#purge() > ActiveMQ Queue management- How to kill a queue? > --- > > Key: AMQ-1114 > URL: https://issues.apache.org/activemq/browse/AMQ-1114 > Project: ActiveMQ > Issue Type: Bug > Components: Broker, JCA Container >Affects Versions: 4.0.1 > Environment: Windows XP, Jdk 1.5, ActiveMQ4.0.1 >Reporter: Vairavan Chandrasekhar > Fix For: 4.1.0 > > > ActiveMQ: Through 'jconsole' we can view all the java components which ever > is active. So by this way, we can see the particular queue and also we can > able to find how many customers are listening. > But I want to manage the queue, like I want to kill a particular queue. Can > anybody help me how to proceed with? > It's pleasure to explain more if you are not clear. > Thanks in advance > Shekar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-1093) Client deadlock during failover
[ https://issues.apache.org/activemq/browse/AMQ-1093?page=all ] james strachan resolved AMQ-1093. - Fix Version/s: 4.2.0 Resolution: Fixed I've just committed a patch to trunk for this which I think resolves the issue. There's no test case to easily verify its resolved though (its a tad hard to recreate) so I wonder could you try and see if this is now fixed - if not let us know and we can reopen this issue > Client deadlock during failover > --- > > Key: AMQ-1093 > URL: https://issues.apache.org/activemq/browse/AMQ-1093 > Project: ActiveMQ > Issue Type: Bug > Components: Transport >Affects Versions: 4.1.0 > Environment: Linux 2.6, java 1.5.0 >Reporter: Danielius Jurna >Priority: Critical > Fix For: 4.2.0 > > > In 4.1.0 there's deadlock on connection failover. There is the scenario: > 1. Client consumes message using message listener > 2. Conection is lost > 3. Client sends message to another queue from messagle listener and waits > until connection is restored. > 4. Reconnect task blocks on reconnecting. > > This bug is new to 4.1.0. The problem is in ActiveMQMessageConsumre.dispatch > . There is new lock on unconsumedMessages.getMutex() . So the reconnect task > cannot invoke ActiveMQMessageConsumre.clearMessagesInProgress(), because lock > is acquired by message listener, which waits untill message is sent (untill > connection is resumed). Here is stack traces: > > "ActiveMQ Session Task" daemon prio=1 tid=0x002b27774260 nid=0x4778 in > Object.wait() [0x40ef3000..0x40ef4db0] > at java.lang.Object.wait(Native Method) > - waiting on <0x002b0020a7c8> (a > edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar) > at java.lang.Object.wait(Object.java:474) > at > edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar.await(CondVar.java:75) > > - locked <0x002b0020a7c8> (a > edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar) > at > edu.emory.mathcs.backport.java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:318) > > at > org.apache.activemq.transport.FutureResponse.getResult(FutureResponse.java:42) > > at > org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:75) > > at > org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1171) > > at > org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1548) > at > org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:465) > > at > org.apache.activemq.pool.PooledProducer.send(PooledProducer.java:75) > - locked <0x002b173fa480> (a > org.apache.activemq.ActiveMQMessageProducer) > at > org.apache.activemq.pool.PooledProducer.send(PooledProducer.java:60) > at > org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:537) > at > org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:513) > at > org.springframework.jms.core.JmsTemplate$2.doInJms(JmsTemplate.java:479) > at > org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:430) > at > org.springframework.jms.core.JmsTemplate.send(JmsTemplate.java:477) > at > lt.elitnet.dbp.das.impl.storage.HI2StorageImpl.storeHI2Message(HI2StorageImpl.java:57) > > at > lt.elitnet.dbp.das.impl.hi2.HI2PersistanceBase.saveIRIContent(HI2PersistanceBase.java:77) > > at sun.reflect.GeneratedMethodAccessor185.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:318) > > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:203) > > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:162) > > at > org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:107) > > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:185) > > at > org.springframework.orm.hibernate3.HibernateInterceptor.invoke(HibernateInterceptor.java:104) > > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:185) > > at > lt.elitnet.dbp.das.impl.alarming.DataBaseConnectionAlarmsPublisher.invoke(DataBaseConnectionAlarmsPublisher.java:59) > > at > org.springframework.aop.framework.Refle
[jira] Created: (AMQ-1091) add a source distro to the maven2 build
add a source distro to the maven2 build --- Key: AMQ-1091 URL: https://issues.apache.org/activemq/browse/AMQ-1091 Project: ActiveMQ Issue Type: Improvement Reporter: james strachan Fix For: 4.2.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-761) ActiveMQConnectionFactory.setBrokerURL does not set all connection properties corrrectly
[ https://issues.apache.org/activemq/browse/AMQ-761?page=all ]
james strachan resolved AMQ-761.
Fix Version/s: 4.1.0
Resolution: Fixed
> ActiveMQConnectionFactory.setBrokerURL does not set all connection properties
> corrrectly
>
>
> Key: AMQ-761
> URL: https://issues.apache.org/activemq/browse/AMQ-761
> Project: ActiveMQ
> Issue Type: Bug
> Components: JMS client
>Affects Versions: 3.2.2
> Environment: Windows XP, Java 1.4.1
>Reporter: Jim Beattie
> Fix For: 4.1.0
>
> Attachments: UrlSetterTest.java
>
>
> If I set the brokerUrl of ActiveMQConnectionFactory using setBrokerURL(), the
> connection factory does not reparse all of the properties from the URL. As a
> result, when a new connection is created, some of the properties from the URL
> specified during the construction of the connection factory (typically the
> defaults) are used instead. Attached is a unit test to demonstrate the
> problem.
> As a minimum, the following block of code is required in setBrokerURL(). But
> this doesn't really fix it because properties settings from the URL used by
> the constructor may not be reset by this code. A structural change may be in
> order (e.g. just-in-time parsing of the properties).
>if( brokerURL.indexOf("?")>= 0 ) {
> String options = brokerURL.substring(brokerURL.indexOf("?")+1);
> Map properties = URIHelper.parseQuery(options);
> if (!properties.isEmpty()) {
> BeanUtils.populate(this, properties);
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-756) Hangs on creating topic on Windows XP 2002 SP2
[ https://issues.apache.org/activemq/browse/AMQ-756?page=all ] james strachan resolved AMQ-756. Fix Version/s: 4.1.0 Resolution: Cannot Reproduce AFAIK this is now resolved. Let us know and we can reopen if required > Hangs on creating topic on Windows XP 2002 SP2 > -- > > Key: AMQ-756 > URL: https://issues.apache.org/activemq/browse/AMQ-756 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 4.0 M4 > Environment: Windows 2002 XP SP2 >Reporter: shantharam > Fix For: 4.1.0 > > > On windows server when trying to create a Topic Session code just hangs, here > is the Thread Dump, same code works fine Unix and Linux environment > "StackTrace Remote Thread" prio=5 tid=0x0444a1a0 nid=0x15ac runnable > [0..55dfb9c] > > "tcp://dubxww11hr/10.251.116.216:29258" prio=5 tid=0x04454868 nid=0xcf4 > runnable [550f000..550fd8c] > at java.net.SocketInputStream.socketRead0(Native Method) > at java.net.SocketInputStream.read(SocketInputStream.java:129) > at > org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:48) > at > org.apache.activemq.transport.tcp.TcpBufferedInputStream.read(TcpBufferedInputStream.java:55) > at java.io.DataInputStream.readInt(DataInputStream.java:443) > at > org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:180) > at > org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:135) > at java.lang.Thread.run(Thread.java:534) > > "Thread-0" daemon prio=5 tid=0x03733c30 nid=0x508 in Object.wait() > [42df000..42dfd8c] > at java.lang.Object.wait(Native Method) > - waiting on <0x12cb01c8> (a java.util.TaskQueue) > at java.util.TimerThread.mainLoop(Timer.java:429) > - locked <0x12cb01c8> (a java.util.TaskQueue) > at java.util.TimerThread.run(Timer.java:382) > > "Signal Dispatcher" daemon prio=10 tid=0x008ad9f0 nid=0xf8c runnable [0..0] > > "Finalizer" daemon prio=9 tid=0x008aafa0 nid=0x1328 in Object.wait() > [2faf000..2fafd8c] > at java.lang.Object.wait(Native Method) > - waiting on <0x12d6cac0> (a java.lang.ref.ReferenceQueue$Lock) > at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111) > - locked <0x12d6cac0> (a java.lang.ref.ReferenceQueue$Lock) > at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127) > at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) > > "Reference Handler" daemon prio=10 tid=0x008a9c20 nid=0x760 in Object.wait() > [2eaf000..2eafd8c] > at java.lang.Object.wait(Native Method) > - waiting on <0x12d6cb28> (a java.lang.ref.Reference$Lock) > at java.lang.Object.wait(Object.java:429) > at > java.lang.ref.Reference$ReferenceHandler.run(Reference.java:115) > - locked <0x12d6cb28> (a java.lang.ref.Reference$Lock) > > "main" prio=5 tid=0x00037c50 nid=0x1650 in Object.wait() [7e000..7fc3c] > at java.lang.Object.wait(Native Method) > - waiting on <0x101deeb0> (a > edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch) > at java.lang.Object.wait(Object.java:429) > at > edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch.await(CountDownLatch.java:173) > - locked <0x101deeb0> (a > edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch) > at > org.apache.activemq.transport.WireFormatNegotiator.oneway(WireFormatNegotiator.java:61) > at > org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44) > - locked <0x101efb00> (a java.lang.Object) > at > org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:62) > at > org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:67) > at > org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1068) > at > org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1132) > at > org.apache.activemq.ActiveMQConnection.createSession(ActiveMQConnection.java:251) > at > org.apache.activemq.ActiveMQConnection.createTopicSession(ActiveMQConnection.java:845) > at > com.sterlingcommerce.woodstock.event.RemoteEventProcessorImpl.(RemoteEventProcessorImpl.java:103) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstr
[jira] Resolved: (AMQ-728) Active MQ is creating great number of Oracle processes
[ https://issues.apache.org/activemq/browse/AMQ-728?page=all ] james strachan resolved AMQ-728. Fix Version/s: 4.2.0 Resolution: Fixed I think this is now resolved - if it isn't please let us know and we can reopen > Active MQ is creating great number of Oracle processes > -- > > Key: AMQ-728 > URL: https://issues.apache.org/activemq/browse/AMQ-728 > Project: ActiveMQ > Issue Type: Bug > Components: Message Store >Affects Versions: 3.2.1 > Environment: Sun Solaris 8, Oracle 9i2, Java 1.4.2_08 >Reporter: Hans Huber > Fix For: 4.2.0 > > Attachments: OracleAfter.png, OracleBefore.png > > > We migrated from derby to Oracle as message persistence layer. We discoverd > now, that ActiveMQ is creating a lot of Oracle resource intensive processes. > Please see attached diagrams: > OracleBefore.png = Orace processes with derby as persistence layer > OraceAfter.png = Oracle processes with Oracele as persistence layer > Any help is much appreciated. If you need any additional information, pls > don't hesitate to contact me > Best regards, Hans Huber -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-992) MySQL doesn't honor lock in JDBC Master Slave configuration?
[ https://issues.apache.org/activemq/browse/AMQ-992?page=all ] james strachan resolved AMQ-992. Fix Version/s: 4.1.1 4.2.0 Resolution: Fixed > MySQL doesn't honor lock in JDBC Master Slave configuration? > > > Key: AMQ-992 > URL: https://issues.apache.org/activemq/browse/AMQ-992 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 4.1.0 > Environment: RHEL 4 > MySQL 4.x, 5.x > mysql-ab_jdbc_driver >Reporter: Steven Lotito > Fix For: 4.1.1, 4.2.0 > > Attachments: mysql_obtain_lock.txt > > > I have been attempting to get the new 4.1 JDBC Master Slave configuration > working with MySQL. > The log from the first broker to start up states: > 2006-10-18 09:35:08,558 [main ] INFO DefaultDatabaseLocker > - Attempting to acquire the exclusive lock to become the Master broker > 2006-10-18 09:35:08,559 [main ] INFO DefaultDatabaseLocker > - Becoming the master on dataSource: [EMAIL PROTECTED] > The 2nd broker to start up has an identical message and both brokers listen > for connections. > The 2nd broker should be waiting for the lock and NOT accepting connections, > if I understand http://www.activemq.org/site/jdbc-master-slave.html > correctly... > Oracle exhibits the expected behavior: > When running the exact same configuration (except using an Oracle > datasource), the first broker has the same log message as above, while the > 2nd broker halts at the "Attempting to acquire the exclusive lock to become > the Master broker" message until I fail the master. Then it becomes the > master. > Is this a known issue? I was able to replicate it using both MySql 4 and 5 > (trying both the MySQL Connector/J 3.1 and MySQL Connector/J 5.0 drivers) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-1050) browse -QTopic=* does not seem to return anything...
[ https://issues.apache.org/activemq/browse/AMQ-1050?page=all ] james strachan resolved AMQ-1050. - Resolution: Fixed > browse -QTopic=* does not seem to return anything... > > > Key: AMQ-1050 > URL: https://issues.apache.org/activemq/browse/AMQ-1050 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 4.x >Reporter: james strachan > Assigned To: Adrian Co > Fix For: 4.1.1, 4.2.0 > > > I think there's something funny going on in the regex stuff. I tried from the > SimpleConsole typing > query -QTopic=* > and I get nothing. > query > returns tons of stuff though. > I wonder if it might be simpler to have specific arguments for topic and > queues? > query -topic=* > queyr -queue=* > to avoid the complex regex of ObjectName etc? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-1054) XA recover fails for 4.0.1
[ https://issues.apache.org/activemq/browse/AMQ-1054?page=all ] james strachan updated AMQ-1054: Fix Version/s: 4.1.1 updated fix versions > XA recover fails for 4.0.1 > -- > > Key: AMQ-1054 > URL: https://issues.apache.org/activemq/browse/AMQ-1054 > Project: ActiveMQ > Issue Type: Bug > Environment: Java, JDK 1.4, Windows, Atomikos TransactionsEssentials > for the JTA/XA part >Reporter: Guy Pardon > Fix For: 4.2.0, 4.1.1 > > Attachments: pom.xml > > > XAResource.recover seems to fail for 4.x of ActiveMQ: > ERROR IN RECOVERY [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 > 08:43:35,152 > [Lorg.apache.activemq.command.DataStructure; [thread: > SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: > org.apache.activemq.TransactionContext.recover(TransactionContext.java:508) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.datasource.xa.XATransactionalResource.recover(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.datasource.xa.XATransactionalResource.endRecovery(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.icatch.imp.TransactionServiceImp.recover(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: > com.atomikos.datasource.xa.XATransactionalResource.setRecoveryService(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.icatch.system.Configuration.addResource(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.checkSetup(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.createQueueConnection(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.createConnection(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > Also see http://www.atomikos-support.com/forums/viewtopic.php?t=351 (where I > borrowed this stack trace from). We have seen similar things in other > applications that tried to use ActiveMQ. I think this is a class cast error > in ActiveMQ... > With 3.1 there is no problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-1072) "TimeToLive" doesn't work on MessageListener
[ https://issues.apache.org/activemq/browse/AMQ-1072?page=all ] james strachan resolved AMQ-1072. - Fix Version/s: 4.1.0 Resolution: Fixed This has been fixed in 4.1 > "TimeToLive" doesn't work on MessageListener > > > Key: AMQ-1072 > URL: https://issues.apache.org/activemq/browse/AMQ-1072 > Project: ActiveMQ > Issue Type: Bug > Components: JMS client >Affects Versions: 4.0.1 >Reporter: Joseph Leung > Fix For: 4.1.0 > > > When a queue message is consumed using MessageListener throught the > setMessageListener method, > it could recieve the messages even if they are expired. (While using > consumer.receive() will discard them). > Reproduce Steps: > 1. deliver a number of message to a queue with a short expire time. > 2. wait until the message should be expired. > 3. use MessageConsumer.receive() method to receive the messages, > -- You should not receive any messages, and through the monitor console, > you should see some > messages are left and not discarded. > 4. stop the receive() method. > 5. add a MessageListener to the same queue, the messages which found left is > received by the > onMessage() method. > ps. if step3 is skipped, likely you would receive all the expired message. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-1054) XA recover fails for 4.0.1
[ https://issues.apache.org/activemq/browse/AMQ-1054?page=comments#action_37589 ] james strachan commented on AMQ-1054: - Have backported the test case and fix to 4.1 branch too if we release a new bug fix release of 4.1 before 4.2 > XA recover fails for 4.0.1 > -- > > Key: AMQ-1054 > URL: https://issues.apache.org/activemq/browse/AMQ-1054 > Project: ActiveMQ > Issue Type: Bug > Environment: Java, JDK 1.4, Windows, Atomikos TransactionsEssentials > for the JTA/XA part >Reporter: Guy Pardon > Fix For: 4.2.0 > > Attachments: pom.xml > > > XAResource.recover seems to fail for 4.x of ActiveMQ: > ERROR IN RECOVERY [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 > 08:43:35,152 > [Lorg.apache.activemq.command.DataStructure; [thread: > SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: > org.apache.activemq.TransactionContext.recover(TransactionContext.java:508) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.datasource.xa.XATransactionalResource.recover(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.datasource.xa.XATransactionalResource.endRecovery(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.icatch.imp.TransactionServiceImp.recover(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: > com.atomikos.datasource.xa.XATransactionalResource.setRecoveryService(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.icatch.system.Configuration.addResource(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.checkSetup(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.createQueueConnection(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.createConnection(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > Also see http://www.atomikos-support.com/forums/viewtopic.php?t=351 (where I > borrowed this stack trace from). We have seen similar things in other > applications that tried to use ActiveMQ. I think this is a class cast error > in ActiveMQ... > With 3.1 there is no problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-1054) XA recover fails for 4.0.1
[ https://issues.apache.org/activemq/browse/AMQ-1054?page=all ] james strachan resolved AMQ-1054. - Fix Version/s: 4.2.0 Resolution: Fixed Aha! So the reason the test case was working that I checked into trunk and 4.0 branch was due to the fact that the test was using the VM transport - which tends to avoid mashalling to and from a socket, so not causing the bug. Have patched the test case both in trunk and in the 4.0 branch. The one in the 4.0 branch now does indeed fail with the ClassCastException. The one in trunk passes with flying colours. So this issue is now resolved and will go out as part of the 4.2 release. If we cut a 4.1.x bug fix release this fix can be back ported for that too > XA recover fails for 4.0.1 > -- > > Key: AMQ-1054 > URL: https://issues.apache.org/activemq/browse/AMQ-1054 > Project: ActiveMQ > Issue Type: Bug > Environment: Java, JDK 1.4, Windows, Atomikos TransactionsEssentials > for the JTA/XA part >Reporter: Guy Pardon > Fix For: 4.2.0 > > Attachments: pom.xml > > > XAResource.recover seems to fail for 4.x of ActiveMQ: > ERROR IN RECOVERY [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 > 08:43:35,152 > [Lorg.apache.activemq.command.DataStructure; [thread: > SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: > org.apache.activemq.TransactionContext.recover(TransactionContext.java:508) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.datasource.xa.XATransactionalResource.recover(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.datasource.xa.XATransactionalResource.endRecovery(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.icatch.imp.TransactionServiceImp.recover(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: > com.atomikos.datasource.xa.XATransactionalResource.setRecoveryService(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.icatch.system.Configuration.addResource(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.checkSetup(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.createQueueConnection(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.createConnection(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > Also see http://www.atomikos-support.com/forums/viewtopic.php?t=351 (where I > borrowed this stack trace from). We have seen similar things in other > applications that tried to use ActiveMQ. I think this is a class cast error > in ActiveMQ... > With 3.1 there is no problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-1074) support JDBC master slave on MySQL
[ https://issues.apache.org/activemq/browse/AMQ-1074?page=all ] james strachan resolved AMQ-1074. - Resolution: Fixed I think this is now working - if folks find an issue with it we can reopen this issue > support JDBC master slave on MySQL > -- > > Key: AMQ-1074 > URL: https://issues.apache.org/activemq/browse/AMQ-1074 > Project: ActiveMQ > Issue Type: Improvement >Reporter: james strachan > Fix For: 4.2.0 > > > We need to make a few changes to support MySQL's SQL dialect for JDBC Master > Slave... > http://incubator.apache.org/activemq/jdbc-master-slave.html > For details see this thread... > http://www.nabble.com/%28AMQ-992%29-DefaultDatabaseLocker-and-mysql-tf2682498.html#a7482369 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-1054) XA recover fails for 4.0.1
[ https://issues.apache.org/activemq/browse/AMQ-1054?page=comments#action_37584 ] james strachan commented on AMQ-1054: - Hi Shoaib Thanks for the link. FWIW the patch Mary gives is similar to the one you suggested and the one I've applied to trunk to fix this issue. So fingers crossed its fixed. > XA recover fails for 4.0.1 > -- > > Key: AMQ-1054 > URL: https://issues.apache.org/activemq/browse/AMQ-1054 > Project: ActiveMQ > Issue Type: Bug > Environment: Java, JDK 1.4, Windows, Atomikos TransactionsEssentials > for the JTA/XA part >Reporter: Guy Pardon > Attachments: pom.xml > > > XAResource.recover seems to fail for 4.x of ActiveMQ: > ERROR IN RECOVERY [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 > 08:43:35,152 > [Lorg.apache.activemq.command.DataStructure; [thread: > SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: > org.apache.activemq.TransactionContext.recover(TransactionContext.java:508) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.datasource.xa.XATransactionalResource.recover(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.datasource.xa.XATransactionalResource.endRecovery(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.icatch.imp.TransactionServiceImp.recover(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: > com.atomikos.datasource.xa.XATransactionalResource.setRecoveryService(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.icatch.system.Configuration.addResource(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.checkSetup(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.createQueueConnection(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.createConnection(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > Also see http://www.atomikos-support.com/forums/viewtopic.php?t=351 (where I > borrowed this stack trace from). We have seen similar things in other > applications that tried to use ActiveMQ. I think this is a class cast error > in ActiveMQ... > With 3.1 there is no problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1075) support for FileMessage interface to support in-band and out-of-band file transfer
support for FileMessage interface to support in-band and out-of-band file
transfer
--
Key: AMQ-1075
URL: https://issues.apache.org/activemq/browse/AMQ-1075
Project: ActiveMQ
Issue Type: New Feature
Components: Broker
Reporter: james strachan
Fix For: 4.2.0
Some new API like this...
public class ActiveMQSession {
// send a local file or stream over JMS
public FileMessage createLocalFileMessage(InputStream inputStream) {...}
public FileMessage createLocalFileMessage(File file) {..,}
public FileMessage createLocalFileMessage(URL url) {..,}
// send a remote URL over JMS
public FileMessage createRemoteFileMessage(URL url) {...}
}
with FileMessage like this...
public interface FileMessage extends Message {
// access the remote resource
// or for local resources, force creation of temporary file
// so this resource can be parsed multiple times etc
URL getURL();
InputStream getInputStream();
}
For further discussion see
http://www.nabble.com/support-for-FileMessage--tf2641673.html#a7373916
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-1074) support JDBC master slave on MySQL
[ https://issues.apache.org/activemq/browse/AMQ-1074?page=comments#action_37583 ] james strachan commented on AMQ-1074: - Patch applied to trunk - which seems to work for me with MySQL Connector/J 5.0.4. > support JDBC master slave on MySQL > -- > > Key: AMQ-1074 > URL: https://issues.apache.org/activemq/browse/AMQ-1074 > Project: ActiveMQ > Issue Type: Improvement >Reporter: james strachan > Fix For: 4.2.0 > > > We need to make a few changes to support MySQL's SQL dialect for JDBC Master > Slave... > http://incubator.apache.org/activemq/jdbc-master-slave.html > For details see this thread... > http://www.nabble.com/%28AMQ-992%29-DefaultDatabaseLocker-and-mysql-tf2682498.html#a7482369 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-1054) XA recover fails for 4.0.1
[ https://issues.apache.org/activemq/browse/AMQ-1054?page=comments#action_37581 ] james strachan commented on AMQ-1054: - Shoaib - I wonder could you try using ActiveMQ trunk (or tomorrows nightly snapshot build of 4.2-SNAPSHOT) to see if I've fixed the bug for you on your environment? I think I've nailed the ClassCastException you're seeing - am just not yet sure of the magic incantations to reproduce it so I can know for sure its fixed > XA recover fails for 4.0.1 > -- > > Key: AMQ-1054 > URL: https://issues.apache.org/activemq/browse/AMQ-1054 > Project: ActiveMQ > Issue Type: Bug > Environment: Java, JDK 1.4, Windows, Atomikos TransactionsEssentials > for the JTA/XA part >Reporter: Guy Pardon > Attachments: pom.xml > > > XAResource.recover seems to fail for 4.x of ActiveMQ: > ERROR IN RECOVERY [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 > 08:43:35,152 > [Lorg.apache.activemq.command.DataStructure; [thread: > SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: > org.apache.activemq.TransactionContext.recover(TransactionContext.java:508) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.datasource.xa.XATransactionalResource.recover(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.datasource.xa.XATransactionalResource.endRecovery(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.icatch.imp.TransactionServiceImp.recover(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: > com.atomikos.datasource.xa.XATransactionalResource.setRecoveryService(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.icatch.system.Configuration.addResource(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.checkSetup(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.createQueueConnection(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.createConnection(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > Also see http://www.atomikos-support.com/forums/viewtopic.php?t=351 (where I > borrowed this stack trace from). We have seen similar things in other > applications that tried to use ActiveMQ. I think this is a class cast error > in ActiveMQ... > With 3.1 there is no problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-1054) XA recover fails for 4.0.1
[ https://issues.apache.org/activemq/browse/AMQ-1054?page=comments#action_37580 ] james strachan commented on AMQ-1054: - Hi Guy Just to be sure - are you saying the bug doesn't happen for you on OSX/Unix? i.e. its a windows only bug? > XA recover fails for 4.0.1 > -- > > Key: AMQ-1054 > URL: https://issues.apache.org/activemq/browse/AMQ-1054 > Project: ActiveMQ > Issue Type: Bug > Environment: Java, JDK 1.4, Windows, Atomikos TransactionsEssentials > for the JTA/XA part >Reporter: Guy Pardon > Attachments: pom.xml > > > XAResource.recover seems to fail for 4.x of ActiveMQ: > ERROR IN RECOVERY [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 > 08:43:35,152 > [Lorg.apache.activemq.command.DataStructure; [thread: > SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: > org.apache.activemq.TransactionContext.recover(TransactionContext.java:508) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.datasource.xa.XATransactionalResource.recover(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.datasource.xa.XATransactionalResource.endRecovery(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.icatch.imp.TransactionServiceImp.recover(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: > com.atomikos.datasource.xa.XATransactionalResource.setRecoveryService(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.icatch.system.Configuration.addResource(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.checkSetup(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.createQueueConnection(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.createConnection(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > Also see http://www.atomikos-support.com/forums/viewtopic.php?t=351 (where I > borrowed this stack trace from). We have seen similar things in other > applications that tried to use ActiveMQ. I think this is a class cast error > in ActiveMQ... > With 3.1 there is no problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1074) support JDBC master slave on MySQL
support JDBC master slave on MySQL -- Key: AMQ-1074 URL: https://issues.apache.org/activemq/browse/AMQ-1074 Project: ActiveMQ Issue Type: Improvement Reporter: james strachan Fix For: 4.2.0 We need to make a few changes to support MySQL's SQL dialect for JDBC Master Slave... http://incubator.apache.org/activemq/jdbc-master-slave.html For details see this thread... http://www.nabble.com/%28AMQ-992%29-DefaultDatabaseLocker-and-mysql-tf2682498.html#a7482369 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-1054) XA recover fails for 4.0.1
[ https://issues.apache.org/activemq/browse/AMQ-1054?page=comments#action_37576 ] james strachan commented on AMQ-1054: - Just to make absolutely sure, I've added the test case into the 4.0 branch too https://svn.apache.org/repos/asf/incubator/activemq/branches/activemq-4.0/activemq-test-atomikos/ and the test case works fine. I wonder if these tests fail on a specific platform only? I wonder could someone try running these test cases on Windows (am an OS X / unix person myself) BTW I tried Java 1.4.2 with the 4.0 branch (which is basically 4.0.2) > XA recover fails for 4.0.1 > -- > > Key: AMQ-1054 > URL: https://issues.apache.org/activemq/browse/AMQ-1054 > Project: ActiveMQ > Issue Type: Bug > Environment: Java, JDK 1.4, Windows, Atomikos TransactionsEssentials > for the JTA/XA part >Reporter: Guy Pardon > Attachments: pom.xml > > > XAResource.recover seems to fail for 4.x of ActiveMQ: > ERROR IN RECOVERY [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 > 08:43:35,152 > [Lorg.apache.activemq.command.DataStructure; [thread: > SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: > org.apache.activemq.TransactionContext.recover(TransactionContext.java:508) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.datasource.xa.XATransactionalResource.recover(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.datasource.xa.XATransactionalResource.endRecovery(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.icatch.imp.TransactionServiceImp.recover(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: > com.atomikos.datasource.xa.XATransactionalResource.setRecoveryService(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.icatch.system.Configuration.addResource(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.checkSetup(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.createQueueConnection(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.createConnection(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > Also see http://www.atomikos-support.com/forums/viewtopic.php?t=351 (where I > borrowed this stack trace from). We have seen similar things in other > applications that tried to use ActiveMQ. I think this is a class cast error > in ActiveMQ... > With 3.1 there is no problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-1054) XA recover fails for 4.0.1
[ https://issues.apache.org/activemq/browse/AMQ-1054?page=all ] james strachan updated AMQ-1054: Attachment: pom.xml This pom.xml replaces the one in activemq-test-atomikos to run against 4.0.2 of ActiveMQ > XA recover fails for 4.0.1 > -- > > Key: AMQ-1054 > URL: https://issues.apache.org/activemq/browse/AMQ-1054 > Project: ActiveMQ > Issue Type: Bug > Environment: Java, JDK 1.4, Windows, Atomikos TransactionsEssentials > for the JTA/XA part >Reporter: Guy Pardon > Attachments: pom.xml > > > XAResource.recover seems to fail for 4.x of ActiveMQ: > ERROR IN RECOVERY [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 > 08:43:35,152 > [Lorg.apache.activemq.command.DataStructure; [thread: > SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: > org.apache.activemq.TransactionContext.recover(TransactionContext.java:508) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.datasource.xa.XATransactionalResource.recover(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.datasource.xa.XATransactionalResource.endRecovery(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.icatch.imp.TransactionServiceImp.recover(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: > com.atomikos.datasource.xa.XATransactionalResource.setRecoveryService(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.icatch.system.Configuration.addResource(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.checkSetup(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.createQueueConnection(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.createConnection(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > Also see http://www.atomikos-support.com/forums/viewtopic.php?t=351 (where I > borrowed this stack trace from). We have seen similar things in other > applications that tried to use ActiveMQ. I think this is a class cast error > in ActiveMQ... > With 3.1 there is no problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-1054) XA recover fails for 4.0.1
[ https://issues.apache.org/activemq/browse/AMQ-1054?page=comments#action_37574 ] james strachan commented on AMQ-1054: - FWIW I've tried the same test case against 4.0.2 as well and it works fine. I'm attaching the pom.xml file you can use in the activemq-test-atomikos directory to run the test case against 4.0.2 of ActiveMQ. > XA recover fails for 4.0.1 > -- > > Key: AMQ-1054 > URL: https://issues.apache.org/activemq/browse/AMQ-1054 > Project: ActiveMQ > Issue Type: Bug > Environment: Java, JDK 1.4, Windows, Atomikos TransactionsEssentials > for the JTA/XA part >Reporter: Guy Pardon > Attachments: pom.xml > > > XAResource.recover seems to fail for 4.x of ActiveMQ: > ERROR IN RECOVERY [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 > 08:43:35,152 > [Lorg.apache.activemq.command.DataStructure; [thread: > SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: > org.apache.activemq.TransactionContext.recover(TransactionContext.java:508) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.datasource.xa.XATransactionalResource.recover(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.datasource.xa.XATransactionalResource.endRecovery(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.icatch.imp.TransactionServiceImp.recover(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: > com.atomikos.datasource.xa.XATransactionalResource.setRecoveryService(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.icatch.system.Configuration.addResource(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.checkSetup(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.createQueueConnection(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.createConnection(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > Also see http://www.atomikos-support.com/forums/viewtopic.php?t=351 (where I > borrowed this stack trace from). We have seen similar things in other > applications that tried to use ActiveMQ. I think this is a class cast error > in ActiveMQ... > With 3.1 there is no problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-1054) XA recover fails for 4.0.1
[ https://issues.apache.org/activemq/browse/AMQ-1054?page=comments#action_37566 ] james strachan commented on AMQ-1054: - h3. Guy I've added your test case to subversion... https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-test-atomikos/ Unfortunately it works perfectly against trunk. I'm guessing the test case only fails if you have XA transactions to recover? h3. Shoaib Thanks for the great diagnosis! Yeah that line of code does look suspicious. I've patched the code in trunk to avoid the ClassCastException - though I'm not too sure how to reproduce the bug yet. I wonder could you try trunk and see if it now works for you? > XA recover fails for 4.0.1 > -- > > Key: AMQ-1054 > URL: https://issues.apache.org/activemq/browse/AMQ-1054 > Project: ActiveMQ > Issue Type: Bug > Environment: Java, JDK 1.4, Windows, Atomikos TransactionsEssentials > for the JTA/XA part >Reporter: Guy Pardon > > XAResource.recover seems to fail for 4.x of ActiveMQ: > ERROR IN RECOVERY [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 > 08:43:35,152 > [Lorg.apache.activemq.command.DataStructure; [thread: > SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: > org.apache.activemq.TransactionContext.recover(TransactionContext.java:508) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.datasource.xa.XATransactionalResource.recover(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.datasource.xa.XATransactionalResource.endRecovery(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 > at: com.atomikos.icatch.imp.TransactionServiceImp.recover(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: > com.atomikos.datasource.xa.XATransactionalResource.setRecoveryService(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.icatch.system.Configuration.addResource(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.checkSetup(Unknown Source) > [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.createQueueConnection(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > at: com.atomikos.jms.QueueConnectionFactoryBean.createConnection(Unknown > Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 > Also see http://www.atomikos-support.com/forums/viewtopic.php?t=351 (where I > borrowed this stack trace from). We have seen similar things in other > applications that tried to use ActiveMQ. I think this is a class cast error > in ActiveMQ... > With 3.1 there is no problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-1068) DestinationMap seems to use up lots of RAM if using deep hierarchies
[ https://issues.apache.org/activemq/browse/AMQ-1068?page=comments#action_37564 ] james strachan commented on AMQ-1068: - The fix was done in r478324 on trunk if folks wanna backport > DestinationMap seems to use up lots of RAM if using deep hierarchies > > > Key: AMQ-1068 > URL: https://issues.apache.org/activemq/browse/AMQ-1068 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 4.1.0, 4.0.2 >Reporter: james strachan > Assigned To: james strachan > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-1073) support selectors in virtual destinations to allow a message to be dispatched to multiple phyiscal queues if it matches the selector
[ https://issues.apache.org/activemq/browse/AMQ-1073?page=all ] james strachan resolved AMQ-1073. - Resolution: Fixed For documentation see http://activemq.org/site/virtual-destinations.html > support selectors in virtual destinations to allow a message to be dispatched > to multiple phyiscal queues if it matches the selector > > > Key: AMQ-1073 > URL: https://issues.apache.org/activemq/browse/AMQ-1073 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Reporter: james strachan > Assigned To: james strachan > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1053) allow a MessageTransformer to be registered with a producer or consumer to help transform a message going onto the bus or coming off the bus
allow a MessageTransformer to be registered with a producer or consumer to help transform a message going onto the bus or coming off the bus Key: AMQ-1053 URL: https://issues.apache.org/activemq/browse/AMQ-1053 Project: ActiveMQ Issue Type: New Feature Reporter: james strachan Assigned To: james strachan For example a user may wish to use ObjectMessage in their code - but in deployment use a TextMessage with XStream or JAXB as the marshalling. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-1053) allow a MessageTransformer to be registered with a producer or consumer to help transform a message going onto the bus or coming off the bus
[ https://issues.apache.org/activemq/browse/AMQ-1053?page=all ] james strachan updated AMQ-1053: Fix Version/s: 4.2.0 > allow a MessageTransformer to be registered with a producer or consumer to > help transform a message going onto the bus or coming off the bus > > > Key: AMQ-1053 > URL: https://issues.apache.org/activemq/browse/AMQ-1053 > Project: ActiveMQ > Issue Type: New Feature >Reporter: james strachan > Assigned To: james strachan > Fix For: 4.2.0 > > > For example a user may wish to use ObjectMessage in their code - but in > deployment use a TextMessage with XStream or JAXB as the marshalling. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-1051) be able to interact with the broker via messaging
[ https://issues.apache.org/activemq/browse/AMQ-1051?page=comments#action_37455 ] james strachan commented on AMQ-1051: - Code checked in - could use some documentation. Currently if you can send a message to the Topic *ActiveMQ.Agent* it will be interpreted as an activemq-console command. So the following kinds of commands are available * help * list * query * browse etc. I've tested it with XMPP so you can chat via Jabber to the broker! :) http://incubator.apache.org/activemq/xmpp.html The best way to get started is to run the web console http://incubator.apache.org/activemq/web-console.html > be able to interact with the broker via messaging > - > > Key: AMQ-1051 > URL: https://issues.apache.org/activemq/browse/AMQ-1051 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Reporter: james strachan > > Send a text message over JMS, XMPP, Stomp, Ajax or REST to communicate with > the broker, query queues/topics etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1051) be able to interact with the broker via messaging
be able to interact with the broker via messaging - Key: AMQ-1051 URL: https://issues.apache.org/activemq/browse/AMQ-1051 Project: ActiveMQ Issue Type: New Feature Components: Broker Reporter: james strachan Send a text message over JMS, XMPP, Stomp, Ajax or REST to communicate with the broker, query queues/topics etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1050) browse -QTopic=* does not seem to return anything...
browse -QTopic=* does not seem to return anything... Key: AMQ-1050 URL: https://issues.apache.org/activemq/browse/AMQ-1050 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.x Reporter: james strachan Assigned To: Adrian Co Fix For: 4.2.0 I think there's something funny going on in the regex stuff. I tried from the SimpleConsole typing query -QTopic=* and I get nothing. query returns tons of stuff though. I wonder if it might be simpler to have specific arguments for topic and queues? query -topic=* queyr -queue=* to avoid the complex regex of ObjectName etc? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-1017) Build of current trunk with Maven2 fails
[ https://issues.apache.org/activemq/browse/AMQ-1017?page=comments#action_37392 ] james strachan commented on AMQ-1017: - I guess we need someone else with a windows machine to trash their local repo and try again - it could be a windows-only-with-no-local-repo issue > Build of current trunk with Maven2 fails > > > Key: AMQ-1017 > URL: https://issues.apache.org/activemq/browse/AMQ-1017 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 4.1 > Environment: Windows XP, Maven 2.0.4, Java 1.5.0_06 >Reporter: Bernhard Wellhöfer >Priority: Critical > Attachments: mvn.log, mvn.log, mvn.log > > > A build of a fresh checkout from > https://svn.apache.org/repos/asf/incubator/activemq/trunk with Maven2 fails. > See the attached log of the build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-1017) Build of current trunk with Maven2 fails
[ https://issues.apache.org/activemq/browse/AMQ-1017?page=comments#action_37391 ] james strachan commented on AMQ-1017: - I've tried trashing the local repo too - and it still works fine for me. I'm kinda mystified why its failing for you. > Build of current trunk with Maven2 fails > > > Key: AMQ-1017 > URL: https://issues.apache.org/activemq/browse/AMQ-1017 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 4.1 > Environment: Windows XP, Maven 2.0.4, Java 1.5.0_06 >Reporter: Bernhard Wellhöfer >Priority: Critical > Attachments: mvn.log, mvn.log, mvn.log > > > A build of a fresh checkout from > https://svn.apache.org/repos/asf/incubator/activemq/trunk with Maven2 fails. > See the attached log of the build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-1036) web-console broken (queue browsing).
[
https://issues.apache.org/activemq/browse/AMQ-1036?page=comments#action_37369 ]
james strachan commented on AMQ-1036:
-
Which version are you using? Its working for me on the 4.1-SNAPSHOT
> web-console broken (queue browsing).
>
>
> Key: AMQ-1036
> URL: https://issues.apache.org/activemq/browse/AMQ-1036
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: incubation
>Reporter: Dave Syer
>
> I managed to build and launch the web-console from svn, but the queue
> browsing page is broken - queue.jsp uses properties of Queue e.g. ${row.size}
> that do not exist. When I hacked queue.jsp to remove references to those
> properties I got another error on trying to purge a queue:
> RequestURI=/activemq-web-console/purgeDestination.action
> Caused by:
> java.lang.IllegalArgumentException: Target bean must not be null
> at org.springframework.util.Assert.notNull(Assert.java:113)
> at
> org.springframework.validation.BeanPropertyBindingResult.(BeanPropertyBindingResult.java:58)
> at
> org.springframework.validation.DataBinder.initBeanPropertyAccess(DataBinder.java:167)
> at
> org.springframework.validation.DataBinder.getInternalBindingResult(DataBinder.java:186)
> at
> org.springframework.validation.DataBinder.getPropertyAccessor(DataBinder.java:196)
> at
> org.springframework.validation.DataBinder.applyPropertyValues(DataBinder.java:515)
> at org.springframework.validation.DataBinder.doBind(DataBinder.java:417)
> at
> org.springframework.web.bind.WebDataBinder.doBind(WebDataBinder.java:146)
> at
> org.springframework.web.bind.ServletRequestDataBinder.bind(ServletRequestDataBinder.java:108)
> at
> org.apache.activemq.web.handler.BindingBeanNameUrlHandlerMapping.getHandlerInternal(BindingBeanNameUrlHandlerMapping.java:43)
> ...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-1034) bad acknowledgement messages when rolling back on a large queue
[ https://issues.apache.org/activemq/browse/AMQ-1034?page=all ] james strachan resolved AMQ-1034. - Fix Version/s: 4.0.3 4.1 Resolution: Fixed hiram fixed this in trunk revision 472345. I've just back ported it to 4.0.x in revision: 472423 > bad acknowledgement messages when rolling back on a large queue > --- > > Key: AMQ-1034 > URL: https://issues.apache.org/activemq/browse/AMQ-1034 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 4.0.2, 4.1 >Reporter: james strachan > Assigned To: james strachan > Fix For: 4.0.3, 4.1 > > > See the test case RollbacksWhileConsumingLargeQueueTest for details of how to > reproduce -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1034) bad acknowledgement messages when rolling back on a large queue
bad acknowledgement messages when rolling back on a large queue --- Key: AMQ-1034 URL: https://issues.apache.org/activemq/browse/AMQ-1034 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.2, 4.1 Reporter: james strachan Assigned To: james strachan See the test case RollbacksWhileConsumingLargeQueueTest for details of how to reproduce -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-1017) Build of current trunk with Maven2 fails
[ https://issues.apache.org/activemq/browse/AMQ-1017?page=comments#action_37357 ] james strachan commented on AMQ-1017: - The build works perfectly for me on OS X and Linux. I guess it must be some windows issue. I wonder does trashing your ~/.m2/repository help? Am wondering if you've got some old version of some jar in your local repo? You definitely have the latest from trunk right? > Build of current trunk with Maven2 fails > > > Key: AMQ-1017 > URL: https://issues.apache.org/activemq/browse/AMQ-1017 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 4.1 > Environment: Windows XP, Maven 2.0.4, Java 1.5.0_06 >Reporter: Bernhard Wellhöfer >Priority: Critical > Attachments: mvn.log > > > A build of a fresh checkout from > https://svn.apache.org/repos/asf/incubator/activemq/trunk with Maven2 fails. > See the attached log of the build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-40) jabber support as client & server
[ https://issues.apache.org/activemq/browse/AMQ-40?page=comments#action_37289 ] james strachan commented on AMQ-40: --- FWIW in 4.1 its now via xmpp://host:port For more details see http://activemq.org/site/xmpp.html > jabber support as client & server > - > > Key: AMQ-40 > URL: https://issues.apache.org/activemq/browse/AMQ-40 > Project: ActiveMQ > Issue Type: New Feature >Reporter: james strachan >Priority: Minor > Fix For: 3.1 > > > we now support a new transport > jabber://localhost:61606 > which allows a Jabber client to connect to ActiveMQ and talk Jabber (XMPP) to > the ActiveMQ broker. This allows any Jabber client in any language to talk > natively to ActiveMQ. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-506) Jabber transport missing
[ https://issues.apache.org/activemq/browse/AMQ-506?page=all ] james strachan resolved AMQ-506. Fix Version/s: 4.1 (was: 4.2) Resolution: Fixed Now back as activemq-xmpp > Jabber transport missing > > > Key: AMQ-506 > URL: https://issues.apache.org/activemq/browse/AMQ-506 > Project: ActiveMQ > Issue Type: Improvement > Components: Transport >Affects Versions: 4.0 M4 >Reporter: Guillaume Nodet > Fix For: 4.1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-1007) XMPP support (Jabber support) so existing Jabber clients can be used to interact with and monitor ActiveMQ messages
[ https://issues.apache.org/activemq/browse/AMQ-1007?page=all ] james strachan resolved AMQ-1007. - Resolution: Fixed The activemq-xmpp module provides the functionality, for documentation see http://activemq.org/site/xmpp.html > XMPP support (Jabber support) so existing Jabber clients can be used to > interact with and monitor ActiveMQ messages > --- > > Key: AMQ-1007 > URL: https://issues.apache.org/activemq/browse/AMQ-1007 > Project: ActiveMQ > Issue Type: New Feature > Components: Transport >Reporter: james strachan > Assigned To: james strachan > Fix For: 4.1 > > > This is particularly useful for demos or testing things out in development. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1007) XMPP support (Jabber support) so existing Jabber clients can be used to interact with and monitor ActiveMQ messages
XMPP support (Jabber support) so existing Jabber clients can be used to interact with and monitor ActiveMQ messages --- Key: AMQ-1007 URL: https://issues.apache.org/activemq/browse/AMQ-1007 Project: ActiveMQ Issue Type: New Feature Components: Transport Reporter: james strachan Assigned To: james strachan Fix For: 4.1 This is particularly useful for demos or testing things out in development. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-950) createConnector="false" has no effect on Tiger
[ https://issues.apache.org/activemq/browse/AMQ-950?page=all ]
james strachan resolved AMQ-950.
Resolution: Fixed
Patch applied - many thanks Renaud.
BTW could you double check my version of your patch works - I only create a
connector if result != null and createConnector is true.
> createConnector="false" has no effect on Tiger
> --
>
> Key: AMQ-950
> URL: https://issues.apache.org/activemq/browse/AMQ-950
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 4.1
> Environment: JDK 1.5.0_08
>Reporter: Renaud Bruyeron
>Priority: Minor
> Fix For: 4.1
>
>
> On Tiger, activemq always creates a rmi connector on port 1099 no matter what
> I do with -Djavax.management... and
> In particular, setting createConnector="false" should prevent AMQ from
> setting up its own connector, but it does not.
> The problem is in the findMBeanServer() method:
> if (result == null && createMBeanServer) {
> result = createMBeanServer();
> }
> else {
> createConnector(result);
> }
> result is not null on Tiger with useJmx="true", and createConnector is not
> protected by if(createConnector) like it is on the non-Tiger flow.
> The fix (I think) is simply to do this:
> if (result == null && createMBeanServer) {
> result = createMBeanServer();
> }
> else {
> if(createConnector){
> createConnector(result);
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-917) Discovery Network Connector needs to clean up internal ...
[ https://issues.apache.org/activemq/browse/AMQ-917?page=all ] james strachan reassigned AMQ-917: -- Assignee: james strachan > Discovery Network Connector needs to clean up internal ... > -- > > Key: AMQ-917 > URL: https://issues.apache.org/activemq/browse/AMQ-917 > Project: ActiveMQ > Issue Type: Bug > Components: Connector >Reporter: Sridhar Komandur > Assigned To: james strachan > Attachments: patchfile.txt > > > Consider the following scenario: All the brokers are using a directory > service based discovery agent (for example, DNS). Broker A comes up and tries > to connect to broker B, which is not functional yet. The Discovery Network > Connector at A adds service B to its tracking state "bridges" (list of > connected services) before activating the connection. However, if there is a > failure, the data structure is not cleaned up. When the DNS Discovery Agent > module rescans (DNS) and passes on uri for B into DNC, it simply ignores it > (as its tracking state hasn't been cleaned up upon prior failure). > The attached patch should take care of this issue (in the observed code path) > - test log below: > 2006-09-11 15:36:11,810 [main ] INFO > network.DemandForwardingBridge1 - Starting a network connection between > vm://localhost#0 and tcp://null:0 has been established. > 2006-09-11 15:36:48,158 [main ] DEBUG > network.DemandForwardingBridge1 - stopping localhost bridge to null is > disposed already ? false > 2006-09-11 15:36:48,158 [main ] INFO > ransport.vm.VMTransportFactory1 - Shutting down VM connectors for broker: > localhost > 2006-09-11 15:36:48,159 [main ] INFO > ransport.vm.VMTransportFactory1 - Shutting down VM connectors for broker: > localhost > 2006-09-11 15:36:48,162 [main ] INFO > vemq.broker.TransportConnector1 - Connector vm://localhost Stopped > 2006-09-11 15:36:48,162 [main ] DEBUG > network.DemandForwardingBridge1 - localhost bridge to null stopped > 2006-09-11 15:37:11,246 [main ] WARN > ivemq.network.NetworkConnector1 - Could not start network bridge between: > vm://localhost?network=true and: tcp://komandur-2.desktop.amazon.com:61617 > due to: java.net.ConnectException: Connection refused > java.net.ConnectException: Connection refused -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-932) Quickly broken client connections lead to memory leaks
[ https://issues.apache.org/activemq/browse/AMQ-932?page=all ] james strachan resolved AMQ-932. Fix Version/s: 4.1 Resolution: Fixed Patch applied John with thanks - could you double check I've applied it correctly please? > Quickly broken client connections lead to memory leaks > -- > > Key: AMQ-932 > URL: https://issues.apache.org/activemq/browse/AMQ-932 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 4.0.2 >Reporter: John Heitmann > Fix For: 4.1 > > Attachments: 73.diff > > > Connections to the openwire port that are pathologically broken (for example > any http request) or that die in some other way extremely quickly will lead > to memory losses of aout 64Kb each time. This happens because many services > are stop()ed directly in the middle of start(), and then never stopped for > real, or stopped again but on an object tree with an inconsistent state. This > is usually also accompanied by the JMX message: > WARN ManagedTransportConnection - Failed to unregister mbean: > org.apache.activemq:BrokerName=localhost,Type=Connection,ConnectorName=default,Connection=25 > But that is a cosmetic symptom and not critical (and this has otherwise > nothing to do with JMX). > My patch is a band-aid that is functional but I'm not very happy with it. The > patch changes some service logic so that if stop is called in the middle of > start, the stop is instead queued and called at the end of start. There will > still be multiple stops, and you'll still see the cosmetic JMX error from the > second ineffectual stop, but the first stop cleans up correctly so there are > no leaks. > I think there's probably a better solution, but it was tough to see what. I'd > appreciate better ideas. Possibly something involving moving the dangerous > operations (wire format negotiation etc) out of start? > I am working on a unit test, but I can't promise I will have something to > submit. I'm having to play JVM games to detect the problem in a unit test and > that might not fly for general purpose use. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-826) LDAP based authorization support
[ https://issues.apache.org/activemq/browse/AMQ-826?page=comments#action_37009 ] james strachan commented on AMQ-826: Any progress on this yet? > LDAP based authorization support > > > Key: AMQ-826 > URL: https://issues.apache.org/activemq/browse/AMQ-826 > Project: ActiveMQ > Issue Type: Improvement >Reporter: james strachan > Assigned To: Nikola Goran Cutura > Attachments: LdapAuth.zip > > > Patch kindly added by ngcutura - discussion thread... > http://www.nabble.com/LDAP-Authorization-tf1851705.html#a5344494 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-930) Session 'consumers' hashtable susceptible to invalid operation exception
[
https://issues.apache.org/activemq/browse/AMQ-930?page=comments#action_36991 ]
james strachan commented on AMQ-930:
I don't quite understand the reason for this patch - I wonder if you could help
explain it?
Session.DispatchAsyncMessages() is only ever called in a separate thread pool
via a call to ThreadPool.QueueUserWorkItem(new
WaitCallback(session.DispatchAsyncMessages) in the MessageConsumer.
The idea is that only 1 thread at once calls this method for all consumers
created by the session. (In NMS, just like in JMS, messages are only dispatched
from one session at once to however many consumers it has - rather than
dispatching to multiple consumers in parallel).
Am wondering if a better fix is just to ensure that the collection
("consumer.Values") is completely thread safe to avoid the concurrent
modification errors you are seeing. I'm working on a patch right now - will
commit it shortly - am wondering if this is a better approach?
> Session 'consumers' hashtable susceptible to invalid operation exception
>
>
> Key: AMQ-930
> URL: https://issues.apache.org/activemq/browse/AMQ-930
> Project: ActiveMQ
> Issue Type: Bug
> Components: NMS (C# client)
>Affects Versions: incubation
> Environment: Windows XP, NMS API running against a AMQ 4.0.2 provider
>Reporter: Bryan Schmidt
>
> In a multithreaded environment that reuses the Session object, the following
> exception is thrown:
> Invalid operation exception with the text: "Collection was modified;
> enumeration operation may not execute."
> The exception is thrown when iterating through Session's consumers.Values
> collection. It appears that the lock is being ignored. Spinning up a new
> thread fixes the problem:
> --- Session.cs, DispatchAsyncMessages method ---
> public void DispatchAsyncMessages(object state)
> {
> // lets iterate through each consumer created by this session
> // ensuring that they have all pending messages dispatched
> lock (this)
> {
> // lets ensure that only 1 thread dispatches messages in a
> consumer at once
> foreach (MessageConsumer consumer in consumers.Values)
> {
> ThreadPool.QueueUserWorkItem(new
> WaitCallback(consumer.DispatchAsyncMessages));
> }
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-826) LDAP based authorization support
[ https://issues.apache.org/activemq/browse/AMQ-826?page=comments#action_36849 ] james strachan commented on AMQ-826: Great - thanks for the heads up. Good luck :) > LDAP based authorization support > > > Key: AMQ-826 > URL: https://issues.apache.org/activemq/browse/AMQ-826 > Project: ActiveMQ > Issue Type: Improvement >Reporter: james strachan > Assigned To: Nikola Goran Cutura > Attachments: LdapAuth.zip > > > Patch kindly added by ngcutura - discussion thread... > http://www.nabble.com/LDAP-Authorization-tf1851705.html#a5344494 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-893) on solaris you cannot easily kill a slave broker when using JDBC Master Slave
[ https://issues.apache.org/activemq/browse/AMQ-893?page=all ] james strachan resolved AMQ-893. Resolution: Fixed Have just added a short circuit for the loop trying to acquire the exclusive lock so that we fail fast if we are stopping > on solaris you cannot easily kill a slave broker when using JDBC Master Slave > - > > Key: AMQ-893 > URL: https://issues.apache.org/activemq/browse/AMQ-893 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 4.1 > Environment: Solaris, T2 >Reporter: james strachan > Assigned To: james strachan > Fix For: 4.1 > > > Seems to hang in a tight loop -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-865) C# Client's Listener doesn't receive messages if you don't explicitly call Subscribe
[
https://issues.apache.org/activemq/browse/AMQ-865?page=comments#action_36801 ]
james strachan commented on AMQ-865:
Here's another test case which seems to show a similar issue...
http://www.nabble.com/Durable-topic-subscription-needs-pump-primed.-tf2117517.html#a5852831
using System;
using System.Collections.Generic;
using System.Text;
using NUnit.Framework;
using NUnit.Extensions;
using ActiveMQ;
using NMS;
using ActiveMQ.Commands;
using System.Threading;
namespace ActiveMQDurableTest
{
[TestFixture]
public class DurableTest
{
private static string TOPIC = "TestTopic";
private static String URI = "tcp://localhost:61616";
private static String CLIENT_ID = "DurableClientId";
private static String CONSUMER_ID = "ConsumerId";
private static ConnectionFactory FACTORY = new ConnectionFactory(new
Uri(URI));
private int count = 0;
public void RegisterDurableConsumer()
{
using (IConnection connection = FACTORY.CreateConnection())
{
connection.ClientId = CLIENT_ID;
connection.Start();
using (ISession session =
connection.CreateSession(AcknowledgementMode.DupsOkAcknowledge))
{
ITopic topic = session.GetTopic(TOPIC);
IMessageConsumer consumer =
session.CreateDurableConsumer(topic, CONSUMER_ID, "2 > 1", false);
consumer.Dispose();
}
connection.Stop();
}
}
public void SendPersistentMessage()
{
using (IConnection connection = FACTORY.CreateConnection())
{
connection.Start();
using (ISession session =
connection.CreateSession(AcknowledgementMode.DupsOkAcknowledge))
{
ITopic topic = session.GetTopic(TOPIC);
ActiveMQTextMessage message = new
ActiveMQTextMessage("Hello");
message.NMSPersistent = true;
message.Persistent = true;
IMessageProducer producer = session.CreateProducer();
producer.Send(topic, message);
producer.Dispose();
}
connection.Stop();
}
}
[Test]
public void TestMe()
{
count = 0;
RegisterDurableConsumer();
SendPersistentMessage();
using (IConnection connection = FACTORY.CreateConnection())
{
connection.ClientId = CLIENT_ID;
connection.Start();
using (ISession session =
connection.CreateSession(AcknowledgementMode.DupsOkAcknowledge))
{
ITopic topic = session.GetTopic(TOPIC);
IMessageConsumer consumer =
session.CreateDurableConsumer(topic, CONSUMER_ID, "2 > 1", false);
consumer.Listener += new
MessageListener(consumer_Listener);
/// Don't know how else to give the system enough time.
///
Thread.Sleep(5000);
Assert.AreEqual(0, count);
Console.WriteLine("Count = " + count);
SendPersistentMessage();
Thread.Sleep(5000);
Assert.AreEqual(2, count);
Console.WriteLine("Count = " + count);
consumer.Dispose();
}
connection.Stop();
}
}
///
///
///
///
private void consumer_Listener(IMessage message)
{
++count;
- Hide quoted text -
}
}
}
> C# Client's Listener doesn't receive messages if you don't explicitly call
> Subscribe
>
>
> Key: AMQ-865
> URL: https://issues.apache.org/activemq/browse/AMQ-865
> Project: ActiveMQ
> Issue Type: Bug
> Components: NMS (C# client)
> Environment: Windows XP, VS 2005, ActiveMQ 4.0.1
>Reporter: Denis Abramov
>
> Easiest way to reproduce the bug would be to start the consumer using the
> following code and then AFTER the consumer starts, start some producer
> (either java or C#) and you will notice that the consumer will not get any
> messages (through trial and error I found that calling Receive() on the
> consumer at least once will make you lose a message but the listener will
> kick back in):
> using System;
> using ActiveMQ;
> using ActiveMQ.Commands;
> using NMS;
> namespace JMSClient
> {
> ///
> /// Summary description for Class1.
> ///
> class Class1
> {
> ///
> /// The main entry point for the application.
> ///
> [STAThread]
> static void Mai
[jira] Assigned: (AMQ-878) JMX Exception: "Destination already created" when recovering gigantic queues from database
[ https://issues.apache.org/activemq/browse/AMQ-878?page=all ] james strachan reassigned AMQ-878: -- Assignee: Hiram Chirino > JMX Exception: "Destination already created" when recovering gigantic queues > from database > -- > > Key: AMQ-878 > URL: https://issues.apache.org/activemq/browse/AMQ-878 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: incubation > Environment: Embeded broker, Any platform (OS, JDK) - currentlly > embeded in JBoss 4.0.4.GA >Reporter: Nikolai Penkov > Assigned To: Hiram Chirino > Attachments: async-recovery.patch > > > I think this issue is described in Hiram's blog: > http://blogbucket.blogspot.com/2006/05/scaling-to-gigantic-queues-and-topics.html. > E.g. when broker is stopped with a lot of messages in queue. When started - > recovery process is fired (currently on creation of a queue), and if another > subscriber requests queue - it creates a new one, because previous process > hasn't finished. > I think the simpliest solution for that problem is to start recovery process > in another thread with synchronization to sent process(sent process should be > suspended till full recovery is done) and subscriber notification method > (every sunscriber should be notified on recovery of message). > I have attached a patch to activemq-core, which I have tested with my > environment - JBoss 4.0.4.GA with Embeded Broker ActiveMQ trunk release, jdbc > persistence. > I am not a spec. in threads nor in ActiveMQ design, and I am sure that you > will find a more elegant sollution to what I have provided. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-826) LDAP based authorization support
[ https://issues.apache.org/activemq/browse/AMQ-826?page=comments#action_36746 ] james strachan commented on AMQ-826: The best thing is to grab the code from subversion... http://incubator.apache.org/activemq/source.html e.g. type svn co http://svn.apache.org/repos/asf/incubator/activemq/trunk activemq then build it via the following (after installing maven) cd activemq mvn install -Dmaven.test.skip=true e.g. http://incubator.apache.org/activemq/building.html the test case is here... https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/security/LDAPAuthorizationMapTest.java you can run the test case via cd activemq-core mvn test -Dtest=LDAPAuthorizationMapTest > LDAP based authorization support > > > Key: AMQ-826 > URL: https://issues.apache.org/activemq/browse/AMQ-826 > Project: ActiveMQ > Issue Type: Improvement >Reporter: james strachan > Assigned To: Nikola Goran Cutura > Attachments: LdapAuth.zip > > > Patch kindly added by ngcutura - discussion thread... > http://www.nabble.com/LDAP-Authorization-tf1851705.html#a5344494 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-826) LDAP based authorization support
[ https://issues.apache.org/activemq/browse/AMQ-826?page=comments#action_36725 ] james strachan commented on AMQ-826: Applied patch with thanks. I made a few minor changes to make things easily configurable via the XBean XML stuff. I've added the test case but disabled it so far - I've not figured out the magic combination of jars and versions and spring.xml configuration files to boot up ApacheDS in Spring for the test case - it seems the online documentation nor the spring.xml that comes with the 1.0-RC3 download actually work. I'm going to leave this issue open until someone figures out how to boot up ApacheDS with a suitable schema in a test case so we can actually test the LDAP authorization support > LDAP based authorization support > > > Key: AMQ-826 > URL: https://issues.apache.org/activemq/browse/AMQ-826 > Project: ActiveMQ > Issue Type: Improvement >Reporter: james strachan > Assigned To: Nikola Goran Cutura > Attachments: LdapAuth.zip > > > Patch kindly added by ngcutura - discussion thread... > http://www.nabble.com/LDAP-Authorization-tf1851705.html#a5344494 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-772) Build ships without activemq-web-4.0.jar
[ https://issues.apache.org/activemq/browse/AMQ-772?page=all ] james strachan resolved AMQ-772. Fix Version/s: 4.1 Resolution: Fixed Should be in tomorrows 4.1-SNAPSHOT distro > Build ships without activemq-web-4.0.jar > > > Key: AMQ-772 > URL: https://issues.apache.org/activemq/browse/AMQ-772 > Project: ActiveMQ > Issue Type: Bug >Reporter: Matt Parker > Fix For: 4.1 > > > Build ships without activemq-web-4.0.jar, so WAR generated by ant task > incomplete. I had to add this myself. Can you please add it to the release? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-766) add jmdns.jar to lib/optional in the binary distro
[ https://issues.apache.org/activemq/browse/AMQ-766?page=all ] james strachan resolved AMQ-766. Resolution: Fixed Should be in tomorrows 4.1-SNAPSHOT distro > add jmdns.jar to lib/optional in the binary distro > -- > > Key: AMQ-766 > URL: https://issues.apache.org/activemq/browse/AMQ-766 > Project: ActiveMQ > Issue Type: Improvement >Affects Versions: 4.0.1 >Reporter: james strachan > Fix For: 4.1 > > > its ASL 2.0 so I don't think we need a license file too but its worth double > checking -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-850) add the ability to timeout a consumer to prevent a bad, hung or unused consumer consumer from grabbing messages
[ https://issues.apache.org/activemq/browse/AMQ-850?page=all ] james strachan updated AMQ-850: --- Summary: add the ability to timeout a consumer to prevent a bad, hung or unused consumer consumer from grabbing messages (was: add the ability to timeout a prefetch buffer to prevent a single consumer grabbing messages) Description: If a MessageConsumer is created but not used, it still tends to get its prefetch-buffer worth of messages. If it does not process them within a specific time the consumer should either be closed, or the messages unacked and flushed from the buffer so that the consumer does not hog the messages. Similarly if a consumer gets a message but then locks up without processing the message we should lazily kill the consumer releasing and redelivering all its messages was:If a MessageConsumer is created but not used, it still tends to get its prefetch-buffer worth of messages. If it does not process them within a specific time the consumer should either be closed, or the messages unacked and flushed from the buffer so that the consumer does not hog the messages. > add the ability to timeout a consumer to prevent a bad, hung or unused > consumer consumer from grabbing messages > --- > > Key: AMQ-850 > URL: https://issues.apache.org/activemq/browse/AMQ-850 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Reporter: james strachan > Fix For: 4.2 > > > If a MessageConsumer is created but not used, it still tends to get its > prefetch-buffer worth of messages. If it does not process them within a > specific time the consumer should either be closed, or the messages unacked > and flushed from the buffer so that the consumer does not hog the messages. > Similarly if a consumer gets a message but then locks up without processing > the message we should lazily kill the consumer releasing and redelivering all > its messages -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-855) Add support for prefetchSize = 0
[ https://issues.apache.org/activemq/browse/AMQ-855?page=comments#action_36716 ] james strachan commented on AMQ-855: Andrew I just commented on this thread on why a prefetch of 1 is the lowest possible value to have while still fully implementing the JMS spec... http://www.nabble.com/forum/ViewPost.jtp?post=5583273&framed=y A few further comments... > Now, you could in theory hack together a "pull" model by setting prefetch > size = 0, so that basically each ack is a request for the next message Thats a prefetch of 1. With a prefetch of zero no messages would be dispatched so there could be no ack :) > Systems like this need to be designed under the assumption that clients will > not behave themselves. > They will deadlock themselves, slow down arbitrarily, boxes will go up and > down, etc. > These things happen all the time in real life and shouldn't have adverse > effects on other, well-behaved consumers. This is a valid problem - a badly behaving consumer can hog a message. However changing from a push to pull model or having prefetch of 0 or 1 will not change this. A hogged message is a hogged message however the consumer manages to get the message (pull or push). e.g. if we did implement prefetch of zero - which means don't deliver a message to a consumer at all - unless they perform a consumer.receive() - even then, the consumer could then hang/deadlock and never actually acknowledge or process the message. The workaround to this is to just kill consumers if they take too long to process a message - see this JIRA which I think what you really need http://issues.apache.org/activemq/browse/AMQ-850 > Add support for prefetchSize = 0 > > > Key: AMQ-855 > URL: https://issues.apache.org/activemq/browse/AMQ-855 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 4.0, 4.0.1, 4.0.2 > Environment: any >Reporter: Vadim Pesochinskiy >Priority: Critical > Fix For: 4.2 > > > This feature would enable to support following test case: > 2 servers are processing 3 submitted jobs with following processing times 10 > min, 1 min, 1 min. This sequence should finish in 10 minutes as one service > will pick up the 10 minutes job, meanwhile the other one should manage the > two 1 minute jobs. Since I cannot set prefetchSize=0, one of the 1 minute > jobs is sitting in prefetch buffer and the jobs are processed in 11 minutes > instead of 10. > This is simplification of the real scenario where I have about 30 consumers > submitting jobs to 20 consumers through AMQ 4.0.1. I have following problems: > • Messages are sitting in prefetch buffer are not available to processors, > which results in a lot of idle time. > • Order of processing is random. For some reason Job # 20 is processed after > Job # 1500. Since senders are synchronously blocked this can result in > time-outs. > • Some requests are real-time, i.e. there is a user waiting, so the system > cannot wait, so AMQ-850 does not fix this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-822) Eclipse fails to compile activemq-core due to invalid symbol in UdpTransportFactory.java
[ https://issues.apache.org/activemq/browse/AMQ-822?page=all ]
james strachan resolved AMQ-822.
Fix Version/s: 4.1
Resolution: Fixed
> Eclipse fails to compile activemq-core due to invalid symbol in
> UdpTransportFactory.java
>
>
> Key: AMQ-822
> URL: https://issues.apache.org/activemq/browse/AMQ-822
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
>Affects Versions: incubation
> Environment: RHEL-3
>Reporter: Maxim Fateev
>Priority: Trivial
> Fix For: 4.1
>
>
> UdpTransportFactory contains commented out code that contain symbol that
> eclipse cannot handle. The following fix was sufficient for code to be
> compiled without problem:
> [EMAIL PROTECTED]:/workplace/fateev/activemq/trunk> svn diff
> activemq-core/src/main/java/org/apache/activemq/transport/udp/UdpTransportFactory.java
> Index:
> activemq-core/src/main/java/org/apache/activemq/transport/udp/UdpTransportFactory.java
> ===
> ---
> activemq-core/src/main/java/org/apache/activemq/transport/udp/UdpTransportFactory.java
> (revision 421719)
> +++
> activemq-core/src/main/java/org/apache/activemq/transport/udp/UdpTransportFactory.java
> (working copy)
> @@ -161,7 +161,7 @@
> * switch to the target endpoint // based on the last packet that was
> * received // so that all future requests go to the newly created
> UDP
> * channel Endpoint from = info.getFrom();
> - * System.out.println("�setting the client side target
> to: " +
> + * System.out.println("setting the client side target to: " +
> * from); udpTransport.setTargetEndpoint(from); } }; return
> transport;
> */
> }
> [EMAIL PROTECTED]:/workplace/fateev/activemq/trunk>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-771) org.apache.activemq.broker.TransportConnection::stop should not attempt to send a message over the connection.
[ https://issues.apache.org/activemq/browse/AMQ-771?page=all ] james strachan reassigned AMQ-771: -- Assignee: Rob Davies > org.apache.activemq.broker.TransportConnection::stop should not attempt to > send a message over the connection. > -- > > Key: AMQ-771 > URL: https://issues.apache.org/activemq/browse/AMQ-771 > Project: ActiveMQ > Issue Type: Bug > Components: Connector >Affects Versions: 4.0, 4.0.1 >Reporter: Kevin Yaussy > Assigned To: Rob Davies > > Especially when using "failover", there can be a problem with respect to > TransportConnection::stop attempting to send a "shutdown" message over the > connection. If another thread is sending messages to the connection, and it > gets stuck for some reason, such as a network freeze, the target machine > panics, or the target process freezes for some reason, the > TransportConnection::dispatch will eventually block, locking the > MutextTransport object. When the InactivityMonitor wakes up and detects that > the connection is dead, it will go through the process of stopping the > connection. This goes back into TransportConnection, and calls stop, which > attemtps to lock the MutexTransport so it can send the "shutdown" command. > Now, both threads are stuck, potentially for a long time, as a box panic will > not cleanly close the tcp connection. > I'm not sure the rationale for wanting to send a shutdown command to the > other side of the connection, since the target has to handle the connection > going down hard anyway. Seems to me, if you are intending on closing the > connection, just close it - don't try to be nice to the other side. > Especially in this code path, there is something wrong with the other side > anyway. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-868) consolidate the C++ clients in SVN more, removing old CMS code
[ https://issues.apache.org/activemq/browse/AMQ-868?page=all ] james strachan reassigned AMQ-868: -- Assignee: Timothy Bish > consolidate the C++ clients in SVN more, removing old CMS code > -- > > Key: AMQ-868 > URL: https://issues.apache.org/activemq/browse/AMQ-868 > Project: ActiveMQ > Issue Type: New Feature >Reporter: james strachan > Assigned To: Timothy Bish > > We've got a couple of CMS code bases in SVN now, lets remove the old one -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-861) Kaha DB files are not removed
[ https://issues.apache.org/activemq/browse/AMQ-861?page=all ] james strachan reassigned AMQ-861: -- Assignee: Rob Davies > Kaha DB files are not removed > - > > Key: AMQ-861 > URL: https://issues.apache.org/activemq/browse/AMQ-861 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 4.0.1 > Environment: Win XP, Java 5 >Reporter: Vadim Pesochinskiy > Assigned To: Rob Davies > Fix For: 4.1 > > > I have request-response point to point test case, which I ran for 12 hours. > Each message is exactly 5KBytes. This is what I see in the Kaha directory: > 779 Aug 1 17:03 roots-data1 > 32M Aug 2 15:28 queue-data4 > 32M Aug 2 18:02 queue-data5 > 32M Aug 2 19:03 queue-data6 > 32M Aug 2 20:04 queue-data7 > 32M Aug 2 21:05 queue-data8 > 32M Aug 2 22:07 queue-data9 > 32M Aug 2 23:08 queue-data10 > 32M Aug 3 00:09 queue-data11 > 32M Aug 3 01:10 queue-data12 > 32M Aug 3 02:12 queue-data13 > 32M Aug 3 03:13 queue-data14 > 32M Aug 3 04:19 queue-data15 > 32M Aug 3 05:20 queue-data16 > 32M Aug 3 06:21 queue-data17 > 32M Aug 3 07:22 queue-data18 > 32M Aug 3 08:23 queue-data19 > 19M Aug 3 09:25 queue-data20 > 8.6K Aug 3 09:52 kaha.idx -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-769) Expose MessageGroupMap implementation to be configurable via BrokerService property
[
https://issues.apache.org/activemq/browse/AMQ-769?page=comments#action_36708 ]
james strachan commented on AMQ-769:
BTW a quick warning about SimpleMessageGroupMap - if you use lots of different
message group IDs then there is a chance of a memory leak as they may not be
closed down properly by bad JMS clients.
But you are right we need a way to make it easier to supply a different
MessageGroupMap implementation. Am working on it right now - should have
something soon
> Expose MessageGroupMap implementation to be configurable via BrokerService
> property
> ---
>
> Key: AMQ-769
> URL: https://issues.apache.org/activemq/browse/AMQ-769
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 4.0
> Environment: Active MQ 4.0
>Reporter: Sanjiv Jivan
>
> I need to use the SimpleMessageGroupMap implmentation of MessageGroupMap
> instad of the default MessageGroupHashBucket implmentation. Presently there's
> no easy way to do this. Additionally the member "messageGroupOwners" in
> org.apache.activemq.broker.region.Queue is private, with no setter and the
> getter has
> public MessageGroupMap getMessageGroupOwners() {
> if (messageGroupOwners == null) {
> messageGroupOwners = new
> MessageGroupHashBucket(messageGroupHashBucketCount);
> }
> return messageGroupOwners;
> }
> So basically there's no easy way to use another implmentation of
> MessageGroupMap in this class. (This lazy create method is also not
> threadsafe. Might be better to default initialize messageGroupOwners )
> I had to jump through a bunh of hoops, starting with subclassing
> BrokerService exposing the messageGroupOwners class, followed by overriding
> createRegionBroker() where it creates an annonymous subclass of RegionBroker
> , overriding createQueueRegion and createTempQueueRegion where I create
> subclasses of QueueRegion and TempQueueRegion respectively to have them be
> configured to use the configured MessageGroupMap.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-776) ConduitBridge can malfunction when first of a set of consumers goes away
[ https://issues.apache.org/activemq/browse/AMQ-776?page=all ] james strachan reassigned AMQ-776: -- Assignee: Rob Davies > ConduitBridge can malfunction when first of a set of consumers goes away > > > Key: AMQ-776 > URL: https://issues.apache.org/activemq/browse/AMQ-776 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 4.0.1 >Reporter: Kevin Yaussy > Assigned To: Rob Davies >Priority: Critical > Attachments: ConduitBridge.patch > > > When the following scenario is followed, any of the subsequent consumers will > stop receiving messages. I've reproduced this using the ConsumerTool, and > ProducerTool supplied in the example area of the distribution. > +++ > Start Broker A > Start Broker B > Start Consumer 1, connecting to Broker B, consuming FOO > Start Consumer 2, connecting to Broker B, consuming FOO > Start Publisher, connecting to Broker A, publishing FOO > Ctl-C out of Consumer 1 > Consumer 2 stops receiving messages > +++ > Seems to me that ConduitBridge is supposed to track all consumers for a given > subscription, by way of DemandSubscription. It is seeding DemandSubscription > with the originating consumer, but when subsequent consumers are added, the > ConduitBridge::addToAlreadyInterestedConsumers re-adds the original > subscriber to the DemandSubscription's map - so the map only ever has the > original subscription. > I've attached a patch. Hope the change is good. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-860) include javadocs inside the binary distro build
include javadocs inside the binary distro build --- Key: AMQ-860 URL: https://issues.apache.org/activemq/browse/AMQ-860 Project: ActiveMQ Issue Type: Improvement Reporter: james strachan -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-859) nightly snapshots to include source distro
nightly snapshots to include source distro -- Key: AMQ-859 URL: https://issues.apache.org/activemq/browse/AMQ-859 Project: ActiveMQ Issue Type: Improvement Reporter: james strachan Assigned To: Fritz Oconer -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-843) temporary queues seem to not work properly in C# when trying to implement request response
[ https://issues.apache.org/activemq/browse/AMQ-843?page=all ]
james strachan resolved AMQ-843.
Fix Version/s: 4.1
Resolution: Fixed
I've added the TemporaryQueueTest.cs NUnit to reproduce this and fixed the bug
> temporary queues seem to not work properly in C# when trying to implement
> request response
> --
>
> Key: AMQ-843
> URL: https://issues.apache.org/activemq/browse/AMQ-843
> Project: ActiveMQ
> Issue Type: Bug
> Components: NMS (C# client)
>Reporter: james strachan
> Fix For: 4.1
>
>
> The following code seems to fail...
> //Send msg to common q with reply to temp q.
> ITemporaryQueue tempQ = session.CreateTemporaryQueue();
> rqstMsg.NMSReplyTo = tempQ;
> rqstMsg.NMSPersistent = false;
> producer.Send(rqstMsg);
>
> //Get msg from common q.
> ActiveMQTextMessage request = consumer.Receive(new TimeSpan(0, 0,
> 5)) as ActiveMQTextMessage;
>
> ITextMessage response = session.CreateTextMessage("this is a
> response!!");
> response.NMSCorrelationID = request.NMSCorrelationID;
>
> IMessageProducer producerTempQ = session.CreateProducer(
> request.NMSReplyTo);
> //Write msg to temp q.
> producerTempQ.Send(response); //EXCEPTION: QUEUE DOESNT EXIST
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-858) create a super pom for tooling projects in activemq so we can create a nightly build of the various maven plugins
create a super pom for tooling projects in activemq so we can create a nightly build of the various maven plugins - Key: AMQ-858 URL: https://issues.apache.org/activemq/browse/AMQ-858 Project: ActiveMQ Issue Type: Bug Reporter: james strachan Assigned To: Adrian Co Priority: Critical Fix For: 4.1 We need to move all the m2 plugins under tooling/ (they nearly all are) then create a pom.xml there for building all the tooling plugings. Folks from there can then do 'mvn clean install' to build and install all the m2 plugins. We can then create a nightly build of the m2 plugins easily. (Right now plugins are not always auto-downloaded when folks try to use stuff in say activemq-perftest module) e.g. macstrac:/workspace/eclipse/activemq jstrachan$ cd activemq-perftest/ macstrac:/workspace/eclipse/activemq/activemq-perftest jstrachan$ mvn activemq-perf:broker [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'activemq-perf'. [INFO] org.apache.maven.plugins: checking for updates from apache-snapshots [INFO] org.codehaus.mojo: checking for updates from apache-snapshots [INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: checking for updates from apache-snapshots [INFO] snapshot org.apache.maven.plugins:maven-compiler-plugin:2.1-SNAPSHOT: checking for updates from apache-snapshots [INFO] artifact org.apache.maven.plugins:maven-eclipse-plugin: checking for updates from apache-snapshots [INFO] snapshot org.apache.maven.plugins:maven-eclipse-plugin:2.3-SNAPSHOT: checking for updates from apache-snapshots [INFO] snapshot org.apache.maven.plugins:maven-plugins:2-SNAPSHOT: checking for updates from apache-snapshots [INFO] artifact org.apache.activemq:maven-activemq-memtest-plugin: checking for updates from apache-snapshots [INFO] artifact org.apache.activemq:maven-activemq-memtest-plugin: checking for updates from central [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.activemq:maven-activemq-memtest-plugin' does not exist or no valid version could be found [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 13 seconds [INFO] Finished at: Thu Aug 03 02:55:57 BST 2006 [INFO] Final Memory: 3M/5M [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-853) Make BrokerFactoryBean use pre-existing app context as parent
[ https://issues.apache.org/activemq/browse/AMQ-853?page=all ] james strachan resolved AMQ-853. Resolution: Fixed Patch applied with thanks. With more complex patches its better to actually supply a patch file - see the [creating patches|http://incubator.apache.org/activemq/contributing.html]. This patch was so simple I think I've not messed it up :) > Make BrokerFactoryBean use pre-existing app context as parent > - > > Key: AMQ-853 > URL: https://issues.apache.org/activemq/browse/AMQ-853 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 4.1 >Reporter: Jason Carreira > Fix For: 4.1 > > Original Estimate: 15 minutes > Remaining Estimate: 15 minutes > > I've made a local enhancement to the BrokerFactoryBean to make it where your > activeMQ XML configuration files refer to beans configured in your Spring > application context. Basically I just made the BrokerFactoryBean implement > ApplicationContextAware so the ApplicationContext will be set, then in > afterPropertiesSet() when it's creating the context for the config resource > location, it does this: > context = new ResourceXmlApplicationContext(config, applicationContext) > passing in the Spring application context as the parent application context > for the ResourceXmlApplicationContext. > I did this for myself so I could use the same DataSource as the backing > DataSource for JDBC persistence. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-842) Amazon's contributed C++ Openwire Client
[ https://issues.apache.org/activemq/browse/AMQ-842?page=all ] james strachan resolved AMQ-842. Resolution: Fixed Patch applied, many thanks. Until we figure out what to do with our various C++ code bases I've added it into an amazon directory; we can then hopefully consolidate our C++ codebases. > Amazon's contributed C++ Openwire Client > > > Key: AMQ-842 > URL: https://issues.apache.org/activemq/browse/AMQ-842 > Project: ActiveMQ > Issue Type: Improvement >Reporter: Andrew Lusk > Attachments: amq_openwirecpp-0.1.2.tar.gz > > > In the spirit of OSCON, here is the latest tarball of our C++ Openwire > client. I believe that all of the source headers are in order. (at last!) > High-level documentation: > http://www.activemq.org/site/openwire-cpp-client.html > Let me know what I can do to expedite this being committed. Thanks for your > patience guys. > In order for this to be committed, we need the following at the bottom of the > project NOTICE file: > Portions of this software copyright 2006 Amazon.com, inc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-839) Opening a connection after closing a connectoin with the same clientid sometimes fails
[ https://issues.apache.org/activemq/browse/AMQ-839?page=all ] james strachan resolved AMQ-839. Fix Version/s: 4.1 Resolution: Fixed Patch applied. Could you try reproduce the issue? Let us know if its not fixed and we can reopen. If its not fixed, a JUnit test case would help us know for sure if we've fixed it:) > Opening a connection after closing a connectoin with the same clientid > sometimes fails > -- > > Key: AMQ-839 > URL: https://issues.apache.org/activemq/browse/AMQ-839 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 4.0.1 > Environment: Linux Red Hat Enterprise 4 >Reporter: Christopher Mihaly > Fix For: 4.1 > > > If a client closes a connection, and then fairly quicly tries to open a > connection with the same clientid, this sometimes fails. Apparently, the > connection is not completely closed on the broker when the close on the > connection completes. This allows the client to try to open a conection and > receive a client already connected exception. The close connection should > not return until the connection is actually closed, or at least an attribute > on the collection should allow for setting if you want to wait or not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-849) Not all properties of the Message are copied during a call to Message.copy(Message)
[ https://issues.apache.org/activemq/browse/AMQ-849?page=all ] james strachan resolved AMQ-849. Fix Version/s: 4.1 (was: 4.0.3) Resolution: Fixed Patch applied - many thanks > Not all properties of the Message are copied during a call to > Message.copy(Message) > --- > > Key: AMQ-849 > URL: https://issues.apache.org/activemq/browse/AMQ-849 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 4.0.1, 4.0.2 >Reporter: Mathew Kuppe > Fix For: 4.1 > > Attachments: message-copy-patch.txt > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > Noticed that when using copyOnSend feature and compression, sent messages > were not being compressed. It was then found that this was due to the fact > that the connection that is used to determine whether compression should be > performed or not, was null for the copied message. A look into the Message > found that the connection and a number of other properties of the Message > were not copied in the copy(Message) > The patch attached copies the remaining properties of the Message to the > message copy. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-847) Memory Leaks
[ https://issues.apache.org/activemq/browse/AMQ-847?page=comments#action_36647 ] james strachan commented on AMQ-847: I think 1) is a duplicate of AMQ-835 maybe? > Memory Leaks > > > Key: AMQ-847 > URL: https://issues.apache.org/activemq/browse/AMQ-847 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Reporter: Hiram Chirino > Assigned To: Hiram Chirino > Fix For: 4.0.3, 4.1 > > > 1) factoryStats in the connection factory was holding on to connections even > when they are closed. > 2) peer BrokerInfos were never removed even when the peer disconnected. > 3) messages dispatched from a Queue would retain a referece to the client > connection even after they had been acked. > 4) ScheduledThreadPoolExecutor does not always seem to release references to > canceled tasks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-816) new transport for load balancing client requests across many brokers
[ https://issues.apache.org/activemq/browse/AMQ-816?page=comments#action_36629 ] james strachan commented on AMQ-816: Was talking about this possible new feature with some users the other day and we tried to come up with a name to refer to this new kinda transport. I was previously struggling to think of one - then we ended up using the term 'jedi'. The name has kinda stuck - I think its cool :) So we could call this the *jedi:* transport :) > new transport for load balancing client requests across many brokers > > > Key: AMQ-816 > URL: https://issues.apache.org/activemq/browse/AMQ-816 > Project: ActiveMQ > Issue Type: Improvement >Reporter: james strachan > Fix For: 4.2 > > > Rather than creating store and forward networks, it might be nice to have a > kind of composite transport where... > * consumers are created on each broker found/discovered. This allows messages > to be sent to any broker and consumed by any consumer > * producers could dynmically choose which broker to send a message to (or > could just pick one broker per session/producer) > this allows for a load balancing layer at the client side which avoids the > need for store/forward networks (which results in more network traffic and > often increases load on the brokers). > So it basically pushes load back to the clients. The downside of this appoach > is that the clients have more connections to brokers - but given the linear > scalability of this, it sounds a great idea to me at least :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-844) tcp connections hang
[ https://issues.apache.org/activemq/browse/AMQ-844?page=comments#action_36628 ] james strachan commented on AMQ-844: BTW I wonder if you create a thread dump when things are hanging if there is any kind of deadlock in the broker? > tcp connections hang > > > Key: AMQ-844 > URL: https://issues.apache.org/activemq/browse/AMQ-844 > Project: ActiveMQ > Issue Type: Bug > Components: Connector >Affects Versions: 4.0.2 > Environment: Tried with j2sdk1.4.2_06 and jdk1.5.0_05 on redhat > enterprise linux 4 (2.6 kernel). >Reporter: Ian Kallen >Priority: Minor > > This problem readily occurs running the standard examples: > ant -Durl=tcp://10.10.3.73:61616?trace=true -Dmax=100 consumer > ant -Durl=tcp://10.10.3.73:61616 -Dmax=10 producer > ...run the producer side for 2-5 iterations before is just hangs. Once it's > in that state, all subsequent client connections hang (i.e. control-C out of > either consumer or producer and restart the connection: hangs). > Upping and lowering soTimeout and other connection parameters has so far > proven fruitless. Switching JVMs, up'ing from 4.0.1 to 4.0.2-SNAPSHOT (on > both client and server), and including/excluding "-Ddurable=true" made no > difference (all orignal test attempts were with durable messages but in the > end, not incluing that had no effect on whether or not the clients eventually > hang). The config on the server looks like this: > http://activemq.org/config/1.0";> >class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"/> > > > dataSource="#postgres-ds"/> > > > uri="tcp://10.10.3.73:61616?trace=true" /> > > > > > > > > > > > > > > FWIW, this doesn't happen when running the same tests on a laptop (MacOS > tiger) with clients on loopback. Bug is "Minor" but (since is't only > exhibited by a small group of us)without being able validate the client > connections, this is a not show-stopper for production use of activemq. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-823) Incorect handling of message size in ByteArrayOutputStream::write
[ https://issues.apache.org/activemq/browse/AMQ-823?page=all ] james strachan reassigned AMQ-823: -- Assignee: Nathan Mittler > Incorect handling of message size in ByteArrayOutputStream::write > - > > Key: AMQ-823 > URL: https://issues.apache.org/activemq/browse/AMQ-823 > Project: ActiveMQ > Issue Type: Bug > Components: CMS (C++ client) >Affects Versions: incubation > Environment: RHEL 4/32bit >Reporter: Radek Sedmak > Assigned To: Nathan Mittler > Original Estimate: 10 minutes > Remaining Estimate: 10 minutes > > when you are sending message via openwire protocol, > ByteArrayOutputStream::write is called in certain moment ... > when message size is greater then defaul CHUNK space is reallocated and there > is "check for EOF offset". > >if( offset > bodySize ) > expandBody() ; > but should be there > if ( offset >= bodySize ) > expandBody(); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-824) Missing NULL pointer check in MessageConsumer::autoAcknowledge
[ https://issues.apache.org/activemq/browse/AMQ-824?page=all ]
james strachan reassigned AMQ-824:
--
Assignee: Nathan Mittler
> Missing NULL pointer check in MessageConsumer::autoAcknowledge
> ---
>
> Key: AMQ-824
> URL: https://issues.apache.org/activemq/browse/AMQ-824
> Project: ActiveMQ
> Issue Type: Bug
> Components: CMS (C++ client)
>Affects Versions: incubation
> Environment: RHEL ES 4/32bit
>Reporter: Radek Sedmak
> Assigned To: Nathan Mittler
> Original Estimate: 10 minutes
> Remaining Estimate: 10 minutes
>
> When you call consumer->receive() on empty queue receive method returns NULL
> message but before return MessageConsumer::autoAcknowledge method is invoked.
> This method doesn't check message against NULL, this cause coredump is
> message is NULL.
> Patch:
> p MessageConsumer::autoAcknowledge(p message)
> {
> try
> {
> if ( message != NULL ) { // <-- Check NULL here !
> // Is the message an ActiveMQMessage? (throws bad_cast otherwise)
> p activeMessage = p_dyncast
> (message) ;
> // Register the handler for client acknowledgment
> activeMessage->setAcknowledger( smartify(this) ) ;
> if( acknowledgementMode != ClientAckMode )
> doAcknowledge(activeMessage) ;
> }
> }
> catch( bad_cast& bc )
> {
> // ignore
> }
> return message ;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-707) makefile plus some changes for the CMS C++ client
[ https://issues.apache.org/activemq/browse/AMQ-707?page=all ] james strachan reassigned AMQ-707: -- Assignee: Nathan Mittler Thought you might find this interesting > makefile plus some changes for the CMS C++ client > - > > Key: AMQ-707 > URL: https://issues.apache.org/activemq/browse/AMQ-707 > Project: ActiveMQ > Issue Type: Improvement > Components: JMS client >Affects Versions: 4.0 RC2 >Reporter: Manuel Teira > Assigned To: Nathan Mittler >Priority: Minor > Fix For: 4.1 > > Attachments: patch.bz2 > > > I've written a trivial makefile to be able to compile the CMS over Stomp C++ > client on Solaris , using Sun Workshop 6. > I've also made some changes: > -Added a strerror_r macro for solaris. > -Define MSG_NOSIGNAL as zero for solaris > -Added 'using namespace activemq' to some files to make Sun Workshop find > some objects. > -Corrected a pair of memory leaks found under purify sessions. > -Corrected a bug in StompTransportFactory::createTransport, not using the > argument brokerUrl > -Deleted a trailing comma in a enum in Session.h, making Sun CC to warn. > -Added a dummy test to just send a message. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-843) temporary queues seem to not work properly in C# when trying to implement request response
temporary queues seem to not work properly in C# when trying to implement
request response
--
Key: AMQ-843
URL: https://issues.apache.org/activemq/browse/AMQ-843
Project: ActiveMQ
Issue Type: Bug
Components: NMS (C# client)
Reporter: james strachan
The following code seems to fail...
//Send msg to common q with reply to temp q.
ITemporaryQueue tempQ = session.CreateTemporaryQueue();
rqstMsg.NMSReplyTo = tempQ;
rqstMsg.NMSPersistent = false;
producer.Send(rqstMsg);
//Get msg from common q.
ActiveMQTextMessage request = consumer.Receive(new TimeSpan(0, 0,
5)) as ActiveMQTextMessage;
ITextMessage response = session.CreateTextMessage("this is a
response!!");
response.NMSCorrelationID = request.NMSCorrelationID;
IMessageProducer producerTempQ = session.CreateProducer(
request.NMSReplyTo);
//Write msg to temp q.
producerTempQ.Send(response); //EXCEPTION: QUEUE DOESNT EXIST
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-830) switch the C# code to use System.Runtime.InteropServices.Marshal.SizeOf) instead of sizeof() to avoid issues on .Net 1.1 (vs2003)
[ https://issues.apache.org/activemq/browse/AMQ-830?page=all ] james strachan resolved AMQ-830. Resolution: Duplicate Duplicate of AMQ-821 > switch the C# code to use System.Runtime.InteropServices.Marshal.SizeOf) > instead of sizeof() to avoid issues on .Net 1.1 (vs2003) > - > > Key: AMQ-830 > URL: https://issues.apache.org/activemq/browse/AMQ-830 > Project: ActiveMQ > Issue Type: Bug >Reporter: james strachan > Fix For: 4.1 > > > For background see > http://www.nabble.com/can-amq-dotnet-build-by-.net-framework1.1-%28vs2003%29-tf1958469.html#a5389861 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-821) Openwire code (from HEAD) doesn't compile on .Net 1.1 - uses sizeof(int)
[ https://issues.apache.org/activemq/browse/AMQ-821?page=all ]
james strachan updated AMQ-821:
---
Fix Version/s: 4.1
(was: incubation)
changed fix version
> Openwire code (from HEAD) doesn't compile on .Net 1.1 - uses sizeof(int)
>
>
> Key: AMQ-821
> URL: https://issues.apache.org/activemq/browse/AMQ-821
> Project: ActiveMQ
> Issue Type: Bug
> Components: JMS client
> Environment: Net 1.1
>Reporter: Dan Haywood
>Priority: Minor
> Fix For: 4.1
>
> Attachments: ActiveMQTextMessage.cs.diff, nant.build.diff
>
>
> sizeof(int) is unsafe code on Net-1.1.
> I've attached patches to put the code in unsafe { ... } block, plus fix to
> nant.build. Same code also (still) compiles on 2.0.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-840) add spring aware ConnectionFactory implementations which automatically set the clientIDPrefix from the Spring Bean Name
[ https://issues.apache.org/activemq/browse/AMQ-840?page=all ] james strachan resolved AMQ-840. Resolution: Fixed using the org.apache.activemq.spring.ActiveMQConnectionFactory (or ActiveMQXAConnectionFactory) will now auto-default the clientIDPrefix property from the Spring Bean Name > add spring aware ConnectionFactory implementations which automatically set > the clientIDPrefix from the Spring Bean Name > --- > > Key: AMQ-840 > URL: https://issues.apache.org/activemq/browse/AMQ-840 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Reporter: james strachan > Fix For: 4.1 > > > This will make it a little easier to debug and trace JMS applications if you > have many different JMS connections being created in different applications > or WARs if you use descriptive bean names for each connection -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-836) add a clientIDPrefix to ActiveMQConnectionFactory so that we can specify the prefix for any auto-generated clientIDs
[ https://issues.apache.org/activemq/browse/AMQ-836?page=all ] james strachan resolved AMQ-836. Resolution: Fixed You can now specify this on a property on the ActiveMQConnectionFactory POJO or via a URI such as tcp://localhost:61616?jms.clientIDPrefix=Cheese > add a clientIDPrefix to ActiveMQConnectionFactory so that we can specify the > prefix for any auto-generated clientIDs > > > Key: AMQ-836 > URL: https://issues.apache.org/activemq/browse/AMQ-836 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Reporter: james strachan > Fix For: 4.1 > > > Its very useful to configure clientIDs on JMS connections for when browsing > the status of a system via JMX... > http://incubator.apache.org/activemq/jmx.html > however the JMS specification only allows you to set the clientID for a > *single* Connection. So in an application where you are using a > ConnectionFactory to make multiple connection objects you cannot specify a > client ID easily. > So it would be good to allow a clientIDPrefix to be set which can then be > appended with a counter/timestamp to ensure uniqueness - but at least it will > start with a descriptive text in consoles etc -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-827) allow the usageManager to be configured in Kb or Mb to make configuration a little easier
[ https://issues.apache.org/activemq/browse/AMQ-827?page=comments#action_36609 ] james strachan commented on AMQ-827: It was much harder & messier to do via string parsing & suffixes - as we'd have to add a String based setter then do string parsing whereas adding different setters was simpler and lead to a cleaner POJO > allow the usageManager to be configured in Kb or Mb to make configuration a > little easier > - > > Key: AMQ-827 > URL: https://issues.apache.org/activemq/browse/AMQ-827 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Reporter: james strachan > Assigned To: james strachan > Fix For: 4.1 > > > something like > would be much simpler than having to get the > calculator out to type 100 * 1024 * 1024 :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-831) provide a JDBC based exclusive lock so that if just using the JDBCPersistenceAdapter (without the journal) we can have failover of brokers
[ https://issues.apache.org/activemq/browse/AMQ-831?page=all ] james strachan resolved AMQ-831. Fix Version/s: 4.1 Resolution: Fixed For description of the feature see: http://activemq.org/site/jdbc-master-slave.html > provide a JDBC based exclusive lock so that if just using the > JDBCPersistenceAdapter (without the journal) we can have failover of brokers > -- > > Key: AMQ-831 > URL: https://issues.apache.org/activemq/browse/AMQ-831 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Reporter: james strachan > Assigned To: james strachan > Fix For: 4.1 > > > It would be good to be able to start, say, 3 brokers all talking to the same > database such that the first one in locks a table with an exclusive lock and > stops other nodes from getting in. If that broker fails, its connection to > the database dies then another broker should be able to jump in and take over. > Basically a JDBC version of the file locking mechanism already in the journal > code such as in these examples... > http://svn.apache.org/viewvc/incubator/activemq/trunk/activeio/activeio-core/src/main/java/org/apache/activeio/journal/active/ControlFile.java?view=markup > http://svn.apache.org/viewvc/incubator/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/store/DefaultPersistenceAdapterFactory.java?revision=421936&view=markup -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-837) add a moveTo() method on the QueueViewMBean for doing dead letter queue processing
add a moveTo() method on the QueueViewMBean for doing dead letter queue processing -- Key: AMQ-837 URL: https://issues.apache.org/activemq/browse/AMQ-837 Project: ActiveMQ Issue Type: Improvement Components: CMS Reporter: james strachan -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-836) add a clientIDPrefix to ActiveMQConnectionFactory so that we can specify the prefix for any auto-generated clientIDs
add a clientIDPrefix to ActiveMQConnectionFactory so that we can specify the prefix for any auto-generated clientIDs Key: AMQ-836 URL: https://issues.apache.org/activemq/browse/AMQ-836 Project: ActiveMQ Issue Type: New Feature Components: Broker Reporter: james strachan Fix For: 4.1 Its very useful to configure clientIDs on JMS connections for when browsing the status of a system via JMX... http://incubator.apache.org/activemq/jmx.html however the JMS specification only allows you to set the clientID for a *single* Connection. So in an application where you are using a ConnectionFactory to make multiple connection objects you cannot specify a client ID easily. So it would be good to allow a clientIDPrefix to be set which can then be appended with a counter/timestamp to ensure uniqueness - but at least it will start with a descriptive text in consoles etc -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-835) memory leak in ActiveMQConnection
[ https://issues.apache.org/activemq/browse/AMQ-835?page=all ] james strachan resolved AMQ-835. Fix Version/s: 4.1 Resolution: Fixed Many thanks for the patch! I've applied to to 4.1 in revision 423797 > memory leak in ActiveMQConnection > - > > Key: AMQ-835 > URL: https://issues.apache.org/activemq/browse/AMQ-835 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 4.0.1 >Reporter: Ozgur Cetinturk > Fix For: 4.1 > > > when connection closing, connection doesn't remove itself from factoryStats. > so every opened connection cause to grow memory. this can be fixed by adding > factoryStats.removeConnection(this); in the close() method. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-831) provide a JDBC based exclusive lock so that if just using the JDBCPersistenceAdapter (without the journal) we can have failover of brokers
provide a JDBC based exclusive lock so that if just using the JDBCPersistenceAdapter (without the journal) we can have failover of brokers -- Key: AMQ-831 URL: https://issues.apache.org/activemq/browse/AMQ-831 Project: ActiveMQ Issue Type: New Feature Components: Broker Reporter: james strachan Assigned To: james strachan It would be good to be able to start, say, 3 brokers all talking to the same database such that the first one in locks a table with an exclusive lock and stops other nodes from getting in. If that broker fails, its connection to the database dies then another broker should be able to jump in and take over. Basically a JDBC version of the file locking mechanism already in the journal code such as in these examples... http://svn.apache.org/viewvc/incubator/activemq/trunk/activeio/activeio-core/src/main/java/org/apache/activeio/journal/active/ControlFile.java?view=markup http://svn.apache.org/viewvc/incubator/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/store/DefaultPersistenceAdapterFactory.java?revision=421936&view=markup -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-829) use some INFO level logging in failover: transport when a transport error occurs and when the transport is resumed
use some INFO level logging in failover: transport when a transport error occurs and when the transport is resumed -- Key: AMQ-829 URL: https://issues.apache.org/activemq/browse/AMQ-829 Project: ActiveMQ Issue Type: Improvement Affects Versions: 4.0.1 Reporter: james strachan Fix For: 4.1 So choose a few log statements and make them info by default -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-828) add some XML configuration way to force the creation of certain destinations on startup
[ https://issues.apache.org/activemq/browse/AMQ-828?page=comments#action_36584 ] james strachan commented on AMQ-828: The simplest way to prevent destinations being auto-created on the fly is to use security to remove the admin role from the destinations http://incubator.apache.org/activemq/security.html > add some XML configuration way to force the creation of certain destinations > on startup > --- > > Key: AMQ-828 > URL: https://issues.apache.org/activemq/browse/AMQ-828 > Project: ActiveMQ > Issue Type: Improvement >Reporter: james strachan > Assigned To: james strachan > Fix For: 4.1 > > > e.g. have some kind of XML like > > > foo.bar > foo.xyz > > > a.b.c > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-828) add some XML configuration way to force the creation of certain destinations on startup
add some XML configuration way to force the creation of certain destinations on startup --- Key: AMQ-828 URL: https://issues.apache.org/activemq/browse/AMQ-828 Project: ActiveMQ Issue Type: Improvement Reporter: james strachan Assigned To: james strachan Fix For: 4.1 e.g. have some kind of XML like foo.bar foo.xyz a.b.c -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-827) allow the usageManager to be configured in Kb or Mb to make configuration a little easier
[ https://issues.apache.org/activemq/browse/AMQ-827?page=all ] james strachan resolved AMQ-827. Resolution: Fixed You can now use the setter methods / XML attributes limit="123" // bytes limitKb="123" // kilobytes limitMb="123" // megabytes > allow the usageManager to be configured in Kb or Mb to make configuration a > little easier > - > > Key: AMQ-827 > URL: https://issues.apache.org/activemq/browse/AMQ-827 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Reporter: james strachan > Assigned To: james strachan > Fix For: 4.1 > > > something like > would be much simpler than having to get the > calculator out to type 100 * 1024 * 1024 :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-827) allow the usageManager to be configured in Kb or Mb to make configuration a little easier
allow the usageManager to be configured in Kb or Mb to make configuration a little easier - Key: AMQ-827 URL: https://issues.apache.org/activemq/browse/AMQ-827 Project: ActiveMQ Issue Type: Improvement Components: Broker Reporter: james strachan Assigned To: james strachan Fix For: 4.1 something like would be much simpler than having to get the calculator out to type 100 * 1024 * 1024 :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-826) LDAP based authorization support
[ https://issues.apache.org/activemq/browse/AMQ-826?page=all ] james strachan updated AMQ-826: --- Attachment: LdapAuth.zip > LDAP based authorization support > > > Key: AMQ-826 > URL: https://issues.apache.org/activemq/browse/AMQ-826 > Project: ActiveMQ > Issue Type: Improvement >Reporter: james strachan > Attachments: LdapAuth.zip > > > Patch kindly added by ngcutura - discussion thread... > http://www.nabble.com/LDAP-Authorization-tf1851705.html#a5344494 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-826) LDAP based authorization support
LDAP based authorization support Key: AMQ-826 URL: https://issues.apache.org/activemq/browse/AMQ-826 Project: ActiveMQ Issue Type: Improvement Reporter: james strachan Patch kindly added by ngcutura - discussion thread... http://www.nabble.com/LDAP-Authorization-tf1851705.html#a5344494 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-825) activemq fails to work with spring-2.0-rc1
[ https://issues.apache.org/activemq/browse/AMQ-825?page=all ] james strachan resolved AMQ-825. Resolution: Fixed We avoid using File objects on the default persistence adapter and use Strings instead. Its unfortunate (I tried patching xbean-spring to get around this but I'm afraid it doesn't seem possible). So folks using Java to configure the dataDirectory will need to change foo.setDataDirectory(file) to foo.setDataDirectoryFile(file) or switch to using a String > activemq fails to work with spring-2.0-rc1 > -- > > Key: AMQ-825 > URL: https://issues.apache.org/activemq/browse/AMQ-825 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 4.0.1 >Reporter: james strachan > Assigned To: james strachan > Fix For: 4.1 > > > we get a failure trying to coerce a String into a File for the dataDirectory > property on the DefaultPersistenceAdapterFactory -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-825) activemq fails to work with spring-2.0-rc1
[ https://issues.apache.org/activemq/browse/AMQ-825?page=comments#action_36580 ] james strachan commented on AMQ-825: BTW to workaround this issue I tried adding a FileEditor to xbean-spring but that didn't help at all. It seems 2.0-rc1 or later requires URI syntax for files as strings. e.g. 'foo' -.> 'file:foo' etc. So am thinking its better to just not use File types in the DefaultPersistenceAdapterFactory and use Strings by default. The downside is this would break folks using the Java API; but better that than break everyone who uses the activemq.xml configuration mechanism > activemq fails to work with spring-2.0-rc1 > -- > > Key: AMQ-825 > URL: https://issues.apache.org/activemq/browse/AMQ-825 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 4.0.1 >Reporter: james strachan > Assigned To: james strachan > Fix For: 4.1 > > > we get a failure trying to coerce a String into a File for the dataDirectory > property on the DefaultPersistenceAdapterFactory -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-825) activemq fails to work with spring-2.0-rc1
activemq fails to work with spring-2.0-rc1 -- Key: AMQ-825 URL: https://issues.apache.org/activemq/browse/AMQ-825 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.0.1 Reporter: james strachan Assigned To: james strachan Fix For: 4.1 we get a failure trying to coerce a String into a File for the dataDirectory property on the DefaultPersistenceAdapterFactory -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-817) typo in C client
typo in C client Key: AMQ-817 URL: https://issues.apache.org/activemq/browse/AMQ-817 Project: ActiveMQ Type: Bug Components: CMS Reporter: james strachan Contributed by BasharTeg on IRC... ow_marshal.c line 72, should be if( *object == 0 ) instead of if( object == 0 ) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-811) MBean improvements
[ https://issues.apache.org/activemq/browse/AMQ-811?page=all ] james strachan resolved AMQ-811: Resolution: Fixed > MBean improvements > -- > > Key: AMQ-811 > URL: https://issues.apache.org/activemq/browse/AMQ-811 > Project: ActiveMQ > Type: Improvement > Versions: 4.0.1 > Reporter: james strachan > Assignee: james strachan > Fix For: 4.1 > > > We could do with some improvements in the MBean APIs... > * allow Messages to be browsed on a BrokerViewMBean (e.g. adding a > browseMessages() or browseMessages(selector) method > * allow durable subscriptions to be destroyed via > DurableSubscriptionViewMBean.destroy() > For more background see > http://www.nabble.com/ActiveMQ-JMX-Questions..-tf1917262.html#a5248649 > http://www.nabble.com/Maintaining-connections-subscriptions-tf1921466.html#a5260973 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-744) add a "vmstat" agent to the maven activemq performance plugin so we can track the CPU, IO, RAM use on the machine we are running the test on
[ https://issues.apache.org/activemq/browse/AMQ-744?page=comments#action_36552 ] james strachan commented on AMQ-744: Looks great - thanks! > add a "vmstat" agent to the maven activemq performance plugin so we can track > the CPU, IO, RAM use on the machine we are running the test on > > > Key: AMQ-744 > URL: https://issues.apache.org/activemq/browse/AMQ-744 > Project: ActiveMQ > Type: Improvement > Components: Performance Test > Reporter: james strachan > Assignee: Adrian Co > Fix For: 4.1 > > > When running a performance test it would be good to spawn off a process to > run 'vmstat' which works on linux and solaris (the flags may differ etc) > which outputs the amout of CPU use in system/user code and how much is idle > together with RAM & IO numbers. > I'd be good to include in each snapshot whatever vmstat numbes we can find so > we can see how the box was doing as the test was running. > e.g. > > > > Note that we may wanna make a few different machine monitoring agents using > different tools - so lets make it pluggable - let 'em write whatever XML they > can - though we should be able to get linux and solaris done (linux only > would be fine for now) > To call vmstat we'll need to do a System.exec() then parse the results etc -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-812) add the ability to find all active and inactive queues & topics in the system as MBeans
add the ability to find all active and inactive queues & topics in the system as MBeans --- Key: AMQ-812 URL: https://issues.apache.org/activemq/browse/AMQ-812 Project: ActiveMQ Type: Improvement Components: Broker Reporter: james strachan Fix For: 4.1 Currently we only show active destinations in JMX. We need a way to show all of them, including inactive ones -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
