[jira] Closed: (GERONIMO-472) MDB Deployment Fails
[ http://nagoya.apache.org/jira/browse/GERONIMO-472?page=history ] Hiram Chirino closed GERONIMO-472: -- Resolution: Fixed Fixed. MDB Deployment Fails Key: GERONIMO-472 URL: http://nagoya.apache.org/jira/browse/GERONIMO-472 Project: Apache Geronimo Type: Bug Components: deployment, OpenEJB Versions: 1.0-M3 Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 1.0-M4 Several problems are causing MDB deployment to fail: - Deployment states that ActivationSpec attributes do not exist.. but they do. Seems like a case problem with the letter of the attribute name. Fixed this by using Introspector.decapitalize(...) in the MdbBuild to fix attribute name. - The resource-link from the mdb to the resource adapter is resulting in: Server reports: Unknown or ambiguous resource name query: geronimo.server:j2eeType=JCAResourceAdapter,J2EEServer=geronimo,J2EEApplication=null,name=SampleActiveMQResourceAdapter,* match count: 0. Fixed this adjusting the RefContext to use the resourceAdapterIndex map instead of the connectionFactoryIndex to lookup the resourceAdapater. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-475) Deployment tool barfs with ArrayIndexOutOfBoundsException
Deployment tool barfs with ArrayIndexOutOfBoundsException - Key: GERONIMO-475 URL: http://nagoya.apache.org/jira/browse/GERONIMO-475 Project: Apache Geronimo Type: Bug Components: deployment Versions: 1.0-M3 Reporter: Hiram Chirino Fix For: 1.0-M4 Ran: java -jar bin\deployer.jar --user system --password list-modules Got: Exception in thread main java.lang.ArrayIndexOutOfBoundsException: 3 at org.apache.geronimo.deployment.cli.ServerConnection.init(ServerConnection.java:102) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:109) at org.apache.geronimo.deployment.cli.DeployTool.main(DeployTool.java:252) I know it's an invalid command, but the tool should report a better error. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-507) ConnectException occurs after MDB deployment and server restart. MDB deploying before Broker
ConnectException occurs after MDB deployment and server restart. MDB deploying before Broker - Key: GERONIMO-507 URL: http://nagoya.apache.org/jira/browse/GERONIMO-507 Project: Apache Geronimo Type: Bug Components: ActiveMQ Versions: 1.0-M3 Reporter: Hiram Chirino Assigned to: Hiram Chirino MDB deploys fine to the server. Server is restarted and you get the following error: 14:30:17,048 WARN [GBeanSingleReference] Exception occured while attempting to fully start: objectName=geronimo.server:EJBModule=activemq-itest-ejb-1.3-SNAPSHOT.jar,J2EEAppli Could not start the endpoint. at org.codehaus.activemq.ra.ActiveMQAsfEndpointWorker.start(ActiveMQAsfEndpointWorker.java:98) at org.codehaus.activemq.ra.ActiveMQResourceAdapter.endpointActivation(ActiveMQResourceAdapter.java:179) at org.apache.geronimo.connector.ResourceAdapterWrapper.endpointActivation(ResourceAdapterWrapper.java:96) at org.apache.geronimo.connector.ResourceAdapterWrapper$$FastClassByCGLIB$$4ab28e73.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:87) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) ... at org.apache.geronimo.kernel.Kernel.startRecursiveGBean(Kernel.java:423) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:150) Caused by: javax.jms.JMSException: Initialization of TcpTransportChannel failed. URI was: tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused: connect at org.codehaus.activemq.util.JMSExceptionHelper.newJMSException(JMSExceptionHelper.java:49) at org.codehaus.activemq.transport.tcp.TcpTransportChannel.init(TcpTransportChannel.java:102) at org.codehaus.activemq.transport.tcp.TcpTransportChannelFactory.create(TcpTransportChannelFactory.java:43) ... at org.codehaus.activemq.ra.ActiveMQBaseEndpointWorker.getPhysicalConnection(ActiveMQBaseEndpointWorker.java:117) at org.codehaus.activemq.ra.ActiveMQAsfEndpointWorker.start(ActiveMQAsfEndpointWorker.java:90) ... 76 more Caused by: java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) ... at java.net.Socket.init(Socket.java:178) at org.codehaus.activemq.transport.tcp.TcpTransportChannel.createSocket(TcpTransportChannel.java:472) at org.codehaus.activemq.transport.tcp.TcpTransportChannel.init(TcpTransportChannel.java:98) It seems like the MDB is being deployed before the ActiveMQ broker is up and running. Since the message Broker is a remote resource that may be up or down, the Resource Adapter should support automatic recovery and should show a sincer error message when the message broker is down. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-507) ConnectException occurs after MDB deployment and server restart. MDB deploying before Broker
[ http://nagoya.apache.org/jira/browse/GERONIMO-507?page=history ] Hiram Chirino closed GERONIMO-507: -- Resolution: Fixed Fix Version: 1.0-M4 The resource adapter no implements recovery with exponential rollback. The max delay of the reconnect is currently 30 seconds. Once the max delay is hit, the adapter will issue warning log messages so that a adminstrator can look into why a connection cannot be established to the broker. ConnectException occurs after MDB deployment and server restart. MDB deploying before Broker - Key: GERONIMO-507 URL: http://nagoya.apache.org/jira/browse/GERONIMO-507 Project: Apache Geronimo Type: Bug Components: ActiveMQ Versions: 1.0-M3 Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 1.0-M4 MDB deploys fine to the server. Server is restarted and you get the following error: 14:30:17,048 WARN [GBeanSingleReference] Exception occured while attempting to fully start: objectName=geronimo.server:EJBModule=activemq-itest-ejb-1.3-SNAPSHOT.jar,J2EEAppli Could not start the endpoint. at org.codehaus.activemq.ra.ActiveMQAsfEndpointWorker.start(ActiveMQAsfEndpointWorker.java:98) at org.codehaus.activemq.ra.ActiveMQResourceAdapter.endpointActivation(ActiveMQResourceAdapter.java:179) at org.apache.geronimo.connector.ResourceAdapterWrapper.endpointActivation(ResourceAdapterWrapper.java:96) at org.apache.geronimo.connector.ResourceAdapterWrapper$$FastClassByCGLIB$$4ab28e73.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:87) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) ... at org.apache.geronimo.kernel.Kernel.startRecursiveGBean(Kernel.java:423) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:150) Caused by: javax.jms.JMSException: Initialization of TcpTransportChannel failed. URI was: tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused: connect at org.codehaus.activemq.util.JMSExceptionHelper.newJMSException(JMSExceptionHelper.java:49) at org.codehaus.activemq.transport.tcp.TcpTransportChannel.init(TcpTransportChannel.java:102) at org.codehaus.activemq.transport.tcp.TcpTransportChannelFactory.create(TcpTransportChannelFactory.java:43) ... at org.codehaus.activemq.ra.ActiveMQBaseEndpointWorker.getPhysicalConnection(ActiveMQBaseEndpointWorker.java:117) at org.codehaus.activemq.ra.ActiveMQAsfEndpointWorker.start(ActiveMQAsfEndpointWorker.java:90) ... 76 more Caused by: java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) ... at java.net.Socket.init(Socket.java:178) at org.codehaus.activemq.transport.tcp.TcpTransportChannel.createSocket(TcpTransportChannel.java:472) at org.codehaus.activemq.transport.tcp.TcpTransportChannel.init(TcpTransportChannel.java:98) It seems like the MDB is being deployed before the ActiveMQ broker is up and running. Since the message Broker is a remote resource that may be up or down, the Resource Adapter should support automatic recovery and should show a sincer error message when the message broker is down. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-478) Deployer must not echo password when prompting
[ http://nagoya.apache.org/jira/browse/GERONIMO-478?page=comments#action_56397 ] Hiram Chirino commented on GERONIMO-478: The password hiding strategy that the patch uses is not very optimal since it is continously updating the screen to overwrite the typed password. Over a slow ssh connection this feature might not be so good. Another approach might be to used something like http://jline.sourceforge.net/#reading_password We site says that jline is lgpl but http://web1.2020media.com/j/jez/javanicuscom/blog2/items/162-index.html seems to indicate that it has recently relicensed as BSD. Deployer must not echo password when prompting -- Key: GERONIMO-478 URL: http://nagoya.apache.org/jira/browse/GERONIMO-478 Project: Apache Geronimo Type: Bug Components: deployment Reporter: Jeremy Boynes Attachments: geronimo-478.patch, geronimo-478.patch When no password is specified on the command line the deployer prompts the user for one. When this is being entered it is echoed onto the screen. On a windows machine the value entered is also displayed if up-arrow is pressed when being prompted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-638) no way to get broker-led replay of messages for messages ACK'd in a transaction after rollback
[ https://issues.apache.org/activemq/browse/AMQ-638?page=all ] Hiram Chirino updated AMQ-638: -- Fix Version: 4.2 Since this will require some thought to get right, and does not seem like it's critical feature users are requesting.. I'm targeting this for thr 4.2... perhaps we will get to this by then. no way to get broker-led replay of messages for messages ACK'd in a transaction after rollback -- Key: AMQ-638 URL: https://issues.apache.org/activemq/browse/AMQ-638 Project: ActiveMQ Type: Improvement Components: Broker Reporter: james strachan Assignee: Hiram Chirino Priority: Trivial Fix For: 4.2 Currently in OpenWire the client is expected to replay messages ACK'd in a transaction and then rolled back - which in general is a much better idea as its simpler faster avoids common ordering problems. However for simple stomp clients, we should have an option to allow a Rollback to mean, redeliver all messages which were ACK'd in the transaction. I wonder should we add a flag to ConsumerInfo to indicate if brokerRedeliveryOnRollback is enabled? Then we can keep Stomp clients super simple. -- 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-637) Enhance ActiveMQInput/Outputstream to use a real TCP connection.
[ https://issues.apache.org/activemq/browse/AMQ-637?page=all ] Hiram Chirino updated AMQ-637: -- Fix Version: 4.2 This could take a bit of thought to implement correctly. Putting out till 4.2. Enhance ActiveMQInput/Outputstream to use a real TCP connection. Key: AMQ-637 URL: https://issues.apache.org/activemq/browse/AMQ-637 Project: ActiveMQ Type: Improvement Reporter: Robert Newson Fix For: 4.2 Currently the ActiveMQInputStream and ActiveMQOutputStreams chunk large messages into 64k chunks. Instead of that, could the act of calling getInputStream(Destination) negotiates a new TCP socket connection? Using ActiveMQ will still give us location transparency, but will the full streaming power of TCP. I spoke with Hiram about this and he thought it would be a fairly simple enhancement. I'm happy to work with him on this as we have a strong need for this functionality. -- 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-644) create Java Service Wrapper for ActiveMQ
[ https://issues.apache.org/activemq/browse/AMQ-644?page=all ] Hiram Chirino updated AMQ-644: -- Fix Version: 4.1 seems easy. Let try to get it in for 4.1 create Java Service Wrapper for ActiveMQ Key: AMQ-644 URL: https://issues.apache.org/activemq/browse/AMQ-644 Project: ActiveMQ Type: New Feature Components: Broker Reporter: james strachan Priority: Minor Fix For: 4.1 Attachments: wrapper.conf http://wrapper.tanukisoftware.org/doc/english/introduction.html -- 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-526) get TwoBrokerMulticastQueueTest to work
[ https://issues.apache.org/activemq/browse/AMQ-526?page=all ] Hiram Chirino updated AMQ-526: -- type: Test (was: Bug) Regression: [Regression, Broken Unit Test] (was: [Broken Unit Test, Regression]) get TwoBrokerMulticastQueueTest to work --- Key: AMQ-526 URL: https://issues.apache.org/activemq/browse/AMQ-526 Project: ActiveMQ Type: Test Components: Test Cases Versions: 4.0 Reporter: Adrian Co Assignee: Adrian Co currently, some test case hangs, some fails. -- 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-611) Race condition in DataContainer
[ https://issues.apache.org/activemq/browse/AMQ-611?page=all ] Hiram Chirino resolved AMQ-611: --- Fix Version: 4.0 Resolution: Fixed Assign To: Hiram Chirino This issue should not occur in 4.0 anymore. I highly recommend that you upgrade. Race condition in DataContainer --- Key: AMQ-611 URL: https://issues.apache.org/activemq/browse/AMQ-611 Project: ActiveMQ Type: Bug Versions: 3.2.2 Environment: Windows XP Pro. Bug found in 3.1 (but appears to still be in 3.2.2) Reporter: Steve Bate Assignee: Hiram Chirino Fix For: 4.0 We are seeing a problem with a IOException from the FileDataBlock when running with multiple slow clients. It appears to be happening because the DataContainer write(byte[]) operation sets the readBlock and writes the data block length then data block content. Another thread sees the read block and reads the data block length but the write thread has not written the contents yet so an IOException or EOFException is thrown in the read thread (in readFully). The write method is synchronized but the read method is not. See: FileDataBlock.read, FileDataBlock.write, DataContainer.write (line 111), and DataContainer.read (line 131) I can reproduce the error reliably in a debugger by controlling the order of the operations. Unfortunately it's difficult to write a repeatable automated test case since this is a race condition type of error. Let me know if you need more information. -- 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-567) Time in queue statistics handy
[ https://issues.apache.org/activemq/browse/AMQ-567?page=all ] Hiram Chirino resolved AMQ-567: --- Fix Version: 4.0 Resolution: Won't Fix I don't think that the JMX interfaces should expose any 'rate' type counters. Rates are can be calculated by the client by sampling the jmx metrics on the queue object. This way, different clients can choose different sample rates. Please reopen this issue if have a more specific counter that you want the broker to expose. Time in queue statistics handy -- Key: AMQ-567 URL: https://issues.apache.org/activemq/browse/AMQ-567 Project: ActiveMQ Type: New Feature Components: Broker Versions: 4.0 M4 Environment: any Reporter: Scott Ellsworth Fix For: 4.0 It would be very keen if the JMX console exposed queue statistics, such as average length of time in queue for current messages, longest/shortest time in queue for current messages, average time in queue for serviced messages (as opposed to those waiting), longestlshortest time for same, and a list of messages in the queue with when they were posted, and how long they have been waiting. -- 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-559) activemq.dtd has duplicate lines
[ https://issues.apache.org/activemq/browse/AMQ-559?page=all ] Hiram Chirino resolved AMQ-559: --- Fix Version: 3.2.5 Resolution: Fixed Thanks for info.. fixed. activemq.dtd has duplicate lines Key: AMQ-559 URL: https://issues.apache.org/activemq/browse/AMQ-559 Project: ActiveMQ Type: Bug Components: Broker Versions: 3.2.2 Reporter: Jim Beattie Priority: Minor Fix For: 3.2.5 The file org/activemq/activemq.dtd in activemq-core-3.2.2.jar contains some duplicate lines. My XML parser (OC4J) complains about these. Here are the duplicated lines: !-- Default values for all bean definitions. Can be overridden at the bean level. See those attribute definitions for details. -- !ATTLIST beans default-lazy-init (true | false) false !ATTLIST beans default-dependency-check (none | objects | simple | all) none !ATTLIST beans default-autowire (no | byName | byType | constructor | autodetect) no These lines appear starting a line 21 and line 539. Removing the second set of duplicate lines should resolve the 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] Closed: (AMQ-521) Enable dumping of config/property at runtime for debugging purposes
[ https://issues.apache.org/activemq/browse/AMQ-521?page=all ] Hiram Chirino closed AMQ-521: - Resolution: Incomplete Don't know what the issue means. Enable dumping of config/property at runtime for debugging purposes --- Key: AMQ-521 URL: https://issues.apache.org/activemq/browse/AMQ-521 Project: ActiveMQ Type: Wish Components: Broker Reporter: Sridhar Komandur Enable dumping of config/property at runtime for debugging purposes -- 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-491) The build cannot continue because of the following unsatisfied dependency: org.mortbay.jetty-5.1-SNAPSHOT.jar
[ https://issues.apache.org/activemq/browse/AMQ-491?page=all ] Hiram Chirino resolved AMQ-491: --- Fix Version: 3.2.4 Resolution: Fixed Assign To: Hiram Chirino 3.2.4 built fine. The build cannot continue because of the following unsatisfied dependency: org.mortbay.jetty-5.1-SNAPSHOT.jar - Key: AMQ-491 URL: https://issues.apache.org/activemq/browse/AMQ-491 Project: ActiveMQ Type: Bug Versions: 3.2, 3.2.1 Environment: Mac OS X tiger, Linux 2.9, Maven 1.1 beta Reporter: Razor Tooth Assignee: Hiram Chirino Fix For: 3.2.4 Original Estimate: 1 day Remaining: 1 day See output below. Verified w/ debug on that URLs to fetch jar file are well-formed but content does not exist in the repository. + | Executing default ActiveMQ :: Optional | Memory: 7M/9M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml default: build:end: Attempting to download geronimo-kernel-1.0-SNAPSHOT.jar. Attempting to download geronimo-system-1.0-SNAPSHOT.jar. Attempting to download org.mortbay.jetty-5.1-SNAPSHOT.jar. WARNING: Failed to download org.mortbay.jetty-5.1-SNAPSHOT.jar. BUILD FAILED File.. /Users/dkords/.maven/cache/maven-multiproject-plugin-1.4.1/plugin.jelly Element... maven:reactor Line.. 218 Column -1 The build cannot continue because of the following unsatisfied dependency: org.mortbay.jetty-5.1-SNAPSHOT.jar Total time : 42 seconds Finished at : Monday, January 16, 2006 10:06:42 PM PST -- 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-388) JDBC support for Firebird database
[ https://issues.apache.org/activemq/browse/AMQ-388?page=all ] Hiram Chirino updated AMQ-388: -- Fix Version: 4.2 Putting on the 4.2 roadmap.. this is call to all the firebird guru's out there... who wants to take a crack at implementing this? Please attach a patch! JDBC support for Firebird database -- Key: AMQ-388 URL: https://issues.apache.org/activemq/browse/AMQ-388 Project: ActiveMQ Type: New Feature Components: Message Store Reporter: Richard DeBay Fix For: 4.2 Support does not exist for the Firebird database. Information can be found at http://www.firebirdsql.org and the JDBC mailing list is at [EMAIL PROTECTED] It shouldn't be difficult, Firebird is an open enterprise level database, so it should have all the features you require. -- 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-386) Remove a POJO listener from a queue.
[ https://issues.apache.org/activemq/browse/AMQ-386?page=all ] Hiram Chirino resolved AMQ-386: --- Resolution: Won't Fix I think it would be best if you asked this question on the http://jencks.codehaus.org site. They might have a good answer for you. Remove a POJO listener from a queue. Key: AMQ-386 URL: https://issues.apache.org/activemq/browse/AMQ-386 Project: ActiveMQ Type: New Feature Components: Broker Versions: 3.1 Environment: linux Reporter: Okke Harsta Currently I'm refactoring a batch framework that was implemented with MDB's and the Weblogic/JBoss container to a standalone framework that uses ActiveMQ and Spring. One of the required features is to pause a batch. In Weblogic this was implemented with proprietary code (undeploying the MDB) and in JBoss using the MBean api for the jndi bound queue. Is there a way I can remove a POJO listener from a queue with the ActiveMQ api or 'pause' a queue so the onMessage of the messageListener is not called but the messages are persisted?. I know the J2EE spec does not cover this requirement, therefore the issue type 'wish'. A running batch must be able to be paused and there are no references to classes involved in the processing. Only the queuename where a POJO bean is listening to is known. Maybe this question is better asked on the wiki, if so please let me know. -- 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-358) JNDI / LDAP discovery mechanism
[ https://issues.apache.org/activemq/browse/AMQ-358?page=all ] Hiram Chirino updated AMQ-358: -- Fix Version: 4.3 Nice to have feature.. target 4.3 on roadmap JNDI / LDAP discovery mechanism --- Key: AMQ-358 URL: https://issues.apache.org/activemq/browse/AMQ-358 Project: ActiveMQ Type: New Feature Reporter: james strachan Fix For: 4.3 It'd be nice to use a clustered JNDI or LDAP server to perform discovery of networks, clusters 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-752) fix the uberjar to tidy up the notice/license files to make it absolutely clear whats going on
[
https://issues.apache.org/activemq/browse/AMQ-752?page=comments#action_36401 ]
Hiram Chirino commented on AMQ-752:
---
I've changed the build so that NOTICE and LICENSE files do not overwrite one
another anymore. Those files are moved
the the META-INF/${jar-name/ directory before we extract the next jar into the
uber jar. So it's now possible to look at the original LICENSE,
DISCLAIMER,NOTICE, and COPYRIGHT files that were include in each jar of the
uber jar.
Please let me know if that's still does not meet the requirements.
fix the uberjar to tidy up the notice/license files to make it absolutely
clear whats going on
--
Key: AMQ-752
URL: https://issues.apache.org/activemq/browse/AMQ-752
Project: ActiveMQ
Type: Bug
Reporter: james strachan
Priority: Blocker
Fix For: 4.0.1, 4.1
all the various LICENSEs need to be appended into a single LICENSE and the
notices consolidated.
Also we might want to...
* the MANIFEST lacks a Implementation-Vendor-Id. not reported harmful but is
in the spec. suggested value: org.apache.
* the MANIFEST lacks a Specification-Version but has an
Implementation-Version. suggested value 4.0.
* better if the source extracts into a directory with a different name from
the binary distribution. for example, incubator-activemq-src for the source
and incubator-activemq for the binary (say.
* i would prefer the binaries and distributions names to contain apache. for
example apache-incubator-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] Commented: (AMQ-665) Error while using management interface on messages with binary data.
[ https://issues.apache.org/activemq/browse/AMQ-665?page=comments#action_36406 ] Hiram Chirino commented on AMQ-665: --- A test case for this would be great! Error while using management interface on messages with binary data. Key: AMQ-665 URL: https://issues.apache.org/activemq/browse/AMQ-665 Project: ActiveMQ Type: Bug Versions: 4.0 Reporter: Bruce Mitchener Assignee: Jonas Lim Priority: Minor Fix For: 4.1, 4.0.1 I'm sending binary data through STOMP (with a content-length header). When I go into jconsole and try to use 'browse' to view the message, I get this exception on the server side: javax.management.openmbean.OpenDataException: Argument's element itemValues[7]=[EMAIL PROTECTED] is not a valid value for this item (itemName=BodyPreview,itemType=javax.management.openmbean.ArrayType(name=[Ljava.lang.Byte;,dimension=1,elementType=javax.management.openmbean.SimpleType(name=java.lang.Byte))). at javax.management.openmbean.CompositeDataSupport.init(CompositeDataSupport.java:145) at javax.management.openmbean.CompositeDataSupport.init(CompositeDataSupport.java:190) at org.apache.activemq.broker.jmx.OpenTypeSupport.convert(OpenTypeSupport.java:253) at org.apache.activemq.broker.jmx.DestinationView.browse(DestinationView.java:91) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.sun.jmx.mbeanserver.StandardMetaDataImpl.invoke(StandardMetaDataImpl.java:414) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1408) at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:81) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1245) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1341) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:782) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:595) -- 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-626) fix test cases MultipleTestsWithSpring*Test which seem to fail due to another test keeping a broker/journal open
[ https://issues.apache.org/activemq/browse/AMQ-626?page=all ] Hiram Chirino updated AMQ-626: -- type: Test (was: Bug) Fix Version: (was: 4.1) fix test cases MultipleTestsWithSpring*Test which seem to fail due to another test keeping a broker/journal open Key: AMQ-626 URL: https://issues.apache.org/activemq/browse/AMQ-626 Project: ActiveMQ Type: Test Components: Test Cases Versions: 4.0 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] Updated: (AMQ-610) fix the test case FanoutTransportBrokerTest which is failing now due to the fix for AMQ-607 by making the open of the socket occur in the start() method
[ https://issues.apache.org/activemq/browse/AMQ-610?page=all ] Hiram Chirino updated AMQ-610: -- type: Test (was: Bug) Fix Version: (was: 4.1) fix the test case FanoutTransportBrokerTest which is failing now due to the fix for AMQ-607 by making the open of the socket occur in the start() method Key: AMQ-610 URL: https://issues.apache.org/activemq/browse/AMQ-610 Project: ActiveMQ Type: Test Components: Test Cases Versions: 4.0 Reporter: james strachan Assignee: Hiram Chirino -- 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-479) TEST org.apache.activemq.usecases.TwoBrokerQueueClientsReconnectTest FAILED
[ https://issues.apache.org/activemq/browse/AMQ-479?page=all ] Hiram Chirino updated AMQ-479: -- type: Test (was: Bug) Fix Version: (was: 4.1) TEST org.apache.activemq.usecases.TwoBrokerQueueClientsReconnectTest FAILED --- Key: AMQ-479 URL: https://issues.apache.org/activemq/browse/AMQ-479 Project: ActiveMQ Type: Test Components: Test Cases Versions: 4.0 Reporter: Adrian Co Priority: Minor disabling test until it's working -- 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-583) DiscoveryTransportBrokerTest can fail on some platforms
[ https://issues.apache.org/activemq/browse/AMQ-583?page=all ] Hiram Chirino updated AMQ-583: -- type: Test (was: Bug) Fix Version: (was: 4.1) DiscoveryTransportBrokerTest can fail on some platforms --- Key: AMQ-583 URL: https://issues.apache.org/activemq/browse/AMQ-583 Project: ActiveMQ Type: Test Components: Test Cases Versions: 4.0 RC2 Reporter: james strachan Assignee: Darwin Flores e.g. on our CI test rig it works on aladdin but fils on iago, jafa, spinach. Could this be an envrionment thing? (other processes running on the box or something - multicast not properly supported etc?) Or is it just something to do with the test case? -- 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-629) test case SslTransportBrokerTest not working
[ https://issues.apache.org/activemq/browse/AMQ-629?page=all ] Hiram Chirino updated AMQ-629: -- type: Test (was: Bug) Fix Version: (was: 4.1) test case SslTransportBrokerTest not working Key: AMQ-629 URL: https://issues.apache.org/activemq/browse/AMQ-629 Project: ActiveMQ Type: Test Components: Test Cases Reporter: james strachan Assignee: Adrian Co -- 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-475) TEST org.apache.activemq.usecases.ThreeBrokerQueueNetworkTest FAILED
[ https://issues.apache.org/activemq/browse/AMQ-475?page=all ] Hiram Chirino updated AMQ-475: -- type: Test (was: Bug) Fix Version: (was: 4.1) TEST org.apache.activemq.usecases.ThreeBrokerQueueNetworkTest FAILED Key: AMQ-475 URL: https://issues.apache.org/activemq/browse/AMQ-475 Project: ActiveMQ Type: Test Components: Test Cases Versions: 4.0 M4 Environment: OS X Reporter: Hiram Chirino Priority: Minor disabling test till it's fixed. -- 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-477) TEST org.apache.activemq.usecases.ThreeBrokerTopicNetworkUsingTcpTest FAILED
[ https://issues.apache.org/activemq/browse/AMQ-477?page=all ] Hiram Chirino updated AMQ-477: -- type: Test (was: Bug) Fix Version: (was: 4.1) TEST org.apache.activemq.usecases.ThreeBrokerTopicNetworkUsingTcpTest FAILED Key: AMQ-477 URL: https://issues.apache.org/activemq/browse/AMQ-477 Project: ActiveMQ Type: Test Components: Test Cases Versions: 4.0 Environment: OS X Reporter: Hiram Chirino Assignee: Rob Davies Priority: Minor disabling test until it passes -- 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-713) possible bug with LastImageRecoveryPolicy
[ https://issues.apache.org/activemq/browse/AMQ-713?page=all ] Hiram Chirino resolved AMQ-713: --- Fix Version: (was: 4.1) Resolution: Duplicate possible bug with LastImageRecoveryPolicy - Key: AMQ-713 URL: https://issues.apache.org/activemq/browse/AMQ-713 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 RC2 Reporter: Jonas Lim investigate possible bug with LastImageRecoveryPolicy . A unit test for this would also help. http://www.nabble.com/Special-Topic-Queue...-t1558344.html -- 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-512) enhance the command line tools to allow messages on queues to be browsed, queues to be purged, messages deleted, dead letter queues to be redispatched to orginal queues etc
[ https://issues.apache.org/activemq/browse/AMQ-512?page=comments#action_36408 ] Hiram Chirino commented on AMQ-512: --- I'll add in the selector support the the JMX method since I think that is simpler solution. enhance the command line tools to allow messages on queues to be browsed, queues to be purged, messages deleted, dead letter queues to be redispatched to orginal queues etc Key: AMQ-512 URL: https://issues.apache.org/activemq/browse/AMQ-512 Project: ActiveMQ Type: New Feature Reporter: james strachan Assignee: Adrian Co Fix For: 4.1 You should be able to reuse the MBeans for the operations of these commands -- 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-754) Be nice to have a DestinationView.browse that could accept a message selector string
[ https://issues.apache.org/activemq/browse/AMQ-754?page=all ] Hiram Chirino resolved AMQ-754: --- Resolution: Fixed Browse method with selector is now supported. Be nice to have a DestinationView.browse that could accept a message selector string Key: AMQ-754 URL: https://issues.apache.org/activemq/browse/AMQ-754 Project: ActiveMQ Type: New Feature Components: Broker Versions: 4.0 Reporter: Adrian Co Assignee: Hiram Chirino Fix For: 4.1 It would be nice if the DestinationView MBean could implement a browse command that could accept a message selector to filter the messages that could be browsed. -- 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-512) enhance the command line tools to allow messages on queues to be browsed, queues to be purged, messages deleted, dead letter queues to be redispatched to orginal queues etc
[ https://issues.apache.org/activemq/browse/AMQ-512?page=comments#action_36410 ] Hiram Chirino commented on AMQ-512: --- Adrian.. a browse method now exists that you can pass in a selector. enhance the command line tools to allow messages on queues to be browsed, queues to be purged, messages deleted, dead letter queues to be redispatched to orginal queues etc Key: AMQ-512 URL: https://issues.apache.org/activemq/browse/AMQ-512 Project: ActiveMQ Type: New Feature Reporter: james strachan Assignee: Adrian Co Fix For: 4.1 You should be able to reuse the MBeans for the operations of these commands -- 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-657) FailoverTransport inhibits exception-listener and transport-listener
[ https://issues.apache.org/activemq/browse/AMQ-657?page=all ] Hiram Chirino resolved AMQ-657: --- Fix Version: 4.0 Resolution: Fixed fix confirmed in 4.0 FailoverTransport inhibits exception-listener and transport-listener Key: AMQ-657 URL: https://issues.apache.org/activemq/browse/AMQ-657 Project: ActiveMQ Type: Test Versions: incubation Reporter: Kevin Yaussy Assignee: Hiram Chirino Fix For: 4.0 When using failover, it looks to me like my ExceptionListener (set via TopicConnection.setExceptionListener) gets removed, or at least never called when there is an exception on the connection. Additionally, I've tried using the ActiveMQConnection.addTransportListener, and failover transport seems to keep onException, transportInterupted and transportResumed from being called. -- 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: (GERONIMO-2132) Move activemq gbean integration modules from ActiveMQ to Geronimo
Move activemq gbean integration modules from ActiveMQ to Geronimo - Key: GERONIMO-2132 URL: http://issues.apache.org/jira/browse/GERONIMO-2132 Project: Geronimo Type: New Feature Security: public (Regular issues) Components: ActiveMQ Reporter: Hiram Chirino Fix For: 1.2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2132) Move activemq gbean integration modules from ActiveMQ to Geronimo
[ http://issues.apache.org/jira/browse/GERONIMO-2132?page=all ] Hiram Chirino updated GERONIMO-2132: Attachment: amq4.patch Move activemq gbean integration modules from ActiveMQ to Geronimo - Key: GERONIMO-2132 URL: http://issues.apache.org/jira/browse/GERONIMO-2132 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: ActiveMQ Reporter: Hiram Chirino Fix For: 1.2 Attachments: amq4.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-759) Removed the gbean modules as they have moved to the Geronimo project source tree
Removed the gbean modules as they have moved to the Geronimo project source tree Key: AMQ-759 URL: https://issues.apache.org/activemq/browse/AMQ-759 Project: ActiveMQ Type: Improvement Components: Geronimo Integration Reporter: Hiram Chirino Assigned to: Hiram Chirino Priority: Trivial Fix For: 4.1 See: http://issues.apache.org/jira/browse/GERONIMO-2132 -- 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-759) Removed the gbean modules as they have moved to the Geronimo project source tree
[ https://issues.apache.org/activemq/browse/AMQ-759?page=all ] Hiram Chirino resolved AMQ-759: --- Resolution: Fixed done in svn rev 415036 Removed the gbean modules as they have moved to the Geronimo project source tree Key: AMQ-759 URL: https://issues.apache.org/activemq/browse/AMQ-759 Project: ActiveMQ Type: Improvement Components: Geronimo Integration Reporter: Hiram Chirino Assignee: Hiram Chirino Priority: Trivial Fix For: 4.1 See: http://issues.apache.org/jira/browse/GERONIMO-2132 -- 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: (GERONIMO-2135) Improve the ActiveMQ GBeans
Improve the ActiveMQ GBeans
---
Key: GERONIMO-2135
URL: http://issues.apache.org/jira/browse/GERONIMO-2135
Project: Geronimo
Type: Improvement
Security: public (Regular issues)
Components: ActiveMQ
Reporter: Hiram Chirino
Assigned to: Hiram Chirino
Fix For: 1.2
Suggestions by David Jencks:
I think that this gbean adaptation code should be in geronimo rather
than amq. I'm OK with applying it as is but would prefer some issues
to be addressed first or, even better, immediately after the
transfer (assuming it is done with svn mv).
1. DataSourceReference should be replaced by the geronimo class that
does the same thing, ConnectionFactorySource.
2. I think it would be preferable to get the module/configuration
classloader in the constructor as a magic attribute and use it in
BrokerServiceGBeanImpl.doStart rather than the classloader of
BrokerServiceGBeanImpl.
3. Same for TransportConnectorGBeanImpl.
4. This is a question, not really an issue, about this code:
+protected TransportConnector createBrokerConnector(String url)
throws Exception {
+return brokerService.getBrokerContainer().addConnector(url);
+}
To me it seems like this code is combining the functions of factory
object and container. Is this necessary and appropriate? I'd be
more comfortable with
Connector connector = ConnectorFactory.createConnector(url);
brokerService.getBrokerContainer().addConnector(connector);
I find that the combination style typically creates problems whenever
trying to extend stuff, say by wrapping the connector. What do you
think?
5. hardcoding the protocols in ActiveMQManagerGBean seems like a
temporary expedient at best.
6. javadoc on public JMSConnector addConnector( ... in the manager
gbean seems wrong... does not appear to return an object name.
7. Typo and innaccuracies in the first package.html... this stuff is
only going to work in geronimo, jsr77/88 is not enough.
8. I'm not sure exactly what our official policy is but I prefer to
remove public from methods in interfaces since it is the only
choice and implied.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2135) Improve the ActiveMQ GBeans
[ http://issues.apache.org/jira/browse/GERONIMO-2135?page=all ]
Hiram Chirino updated GERONIMO-2135:
Attachment: GERONIMO-2135.patch
Fixes most of the items in this issue.
Improve the ActiveMQ GBeans
---
Key: GERONIMO-2135
URL: http://issues.apache.org/jira/browse/GERONIMO-2135
Project: Geronimo
Type: Improvement
Security: public(Regular issues)
Components: ActiveMQ
Reporter: Hiram Chirino
Assignee: Hiram Chirino
Fix For: 1.2
Attachments: GERONIMO-2135.patch
Suggestions by David Jencks:
I think that this gbean adaptation code should be in geronimo rather
than amq. I'm OK with applying it as is but would prefer some issues
to be addressed first or, even better, immediately after the
transfer (assuming it is done with svn mv).
1. DataSourceReference should be replaced by the geronimo class that
does the same thing, ConnectionFactorySource.
2. I think it would be preferable to get the module/configuration
classloader in the constructor as a magic attribute and use it in
BrokerServiceGBeanImpl.doStart rather than the classloader of
BrokerServiceGBeanImpl.
3. Same for TransportConnectorGBeanImpl.
4. This is a question, not really an issue, about this code:
+protected TransportConnector createBrokerConnector(String url)
throws Exception {
+return brokerService.getBrokerContainer().addConnector(url);
+}
To me it seems like this code is combining the functions of factory
object and container. Is this necessary and appropriate? I'd be
more comfortable with
Connector connector = ConnectorFactory.createConnector(url);
brokerService.getBrokerContainer().addConnector(connector);
I find that the combination style typically creates problems whenever
trying to extend stuff, say by wrapping the connector. What do you
think?
5. hardcoding the protocols in ActiveMQManagerGBean seems like a
temporary expedient at best.
6. javadoc on public JMSConnector addConnector( ... in the manager
gbean seems wrong... does not appear to return an object name.
7. Typo and innaccuracies in the first package.html... this stuff is
only going to work in geronimo, jsr77/88 is not enough.
8. I'm not sure exactly what our official policy is but I prefer to
remove public from methods in interfaces since it is the only
choice and implied.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Reopened: (AMQ-732) Infinite recovery loop.
[ https://issues.apache.org/activemq/browse/AMQ-732?page=all ]
Hiram Chirino reopened AMQ-732:
---
ah.. just noticed that 4.0.1 did not build a new activeio and ship with the new
version. I guess this will make it into 4.0.2 then.
Infinite recovery loop.
---
Key: AMQ-732
URL: https://issues.apache.org/activemq/browse/AMQ-732
Project: ActiveMQ
Type: Bug
Components: Broker
Versions: 4.0
Environment: Linux RHEL 3
Reporter: Maxim Fateev
Assignee: Hiram Chirino
Fix For: 4.1, 4.0.2
Attachments: activemq-data-1-journal.tar.gz, activemq-data-2-journal.tar.gz
The simplest way to reproduce the problem:
1. Remove storage directory.
2. Start broker using the following code:
public static void main(String[] args) throws Exception {
BrokerService broker = new BrokerService();
broker.setPersistent(true);
DefaultPersistenceAdapterFactory pFactory = new
DefaultPersistenceAdapterFactory();
pFactory.setJournalLogFiles(1);
pFactory.setJournalLogFileSize(2048);
broker.setPersistenceFactory(pFactory);
broker.setUseJmx(false);
broker.addConnector(tcp://localhost:61616);
broker.start();
Thread.sleep(1l);
}
3. Shutdown the broker.
4. Start broker.
It enters infinite loop
[ main] BrokerService INFO
ActiveMQ null JMS Message Broker (localhost) is starting
[ main] BrokerService INFO For
help or more information please see: http://incubator.apache.org/activemq/
[ main] JDBCPersistenceAdapter INFO
Database driver recognized: [apache_derby_embedded_jdbc_driver]
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER
VARCHAR(250), MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT,
MSG BLOB, PRIMARY KEY ( ID ) )
[ main] DefaultJDBCAdapter DEBUG Could
not create JDBC tables; The message table already existed. Failure was:
CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER VARCHAR(250),
MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT, MSG BLOB,
PRIMARY KEY ( ID ) ) Message: Table/View 'ACTIVEMQ_MSGS' already exists in
Schema 'APP'. SQLState: X0Y32 Vendor code: 2
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_MIDX ON ACTIVEMQ_MSGS
(MSGID_PROD,MSGID_SEQ)
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_CIDX ON ACTIVEMQ_MSGS (CONTAINER)
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_EIDX ON ACTIVEMQ_MSGS (EXPIRATION)
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL,
CLIENT_ID VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR
VARCHAR(250), LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID,
SUB_NAME))
[ main] DefaultJDBCAdapter DEBUG Could
not create JDBC tables; The message table already existed. Failure was:
CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL, CLIENT_ID
VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR VARCHAR(250),
LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID, SUB_NAME))
Message: Table/View 'ACTIVEMQ_ACKS' already exists in Schema 'APP'. SQLState:
X0Y32 Vendor code: 2
[ main] JDBCPersistenceAdapter DEBUG
Cleaning up old messages.
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: DELETE FROM ACTIVEMQ_MSGS WHERE ( EXPIRATION0 AND
EXPIRATION?) OR ID = ( SELECT min(ACTIVEMQ_ACKS.LAST_ACKED_ID) FROM
ACTIVEMQ_ACKS WHERE ACTIVEMQ_ACKS.CONTAINER=ACTIVEMQ_MSGS.CONTAINER)
[ main] DefaultJDBCAdapter DEBUG Deleted
0 old message(s).
[ main] JDBCPersistenceAdapter DEBUG Cleanup
done.
[ main] JournalPersistenceAdapter INFO Journal
Recovery Started from: Active Journal: using 1 x 0.001953125 Megs at:
/workplace/fateev/install/activemq-4.0-SNAPSHOT/activemq-core/activemq-data/journal
[ main] JournalPersistenceAdapter DEBUG TRACE
Entry: RECOVERED
[Journal Writer] LogFileManager DEBUG
getNextDataRecordLocation offset=53
[Journal Writer] LogFileManager DEBUG
getNextDataRecordLocation offset=97
[Journal Writer] LogFileManager DEBUG
[jira] Updated: (AMQ-732) Infinite recovery loop.
[ https://issues.apache.org/activemq/browse/AMQ-732?page=all ]
Hiram Chirino updated AMQ-732:
--
Fix Version: 4.0.2
(was: 4.0.1)
Infinite recovery loop.
---
Key: AMQ-732
URL: https://issues.apache.org/activemq/browse/AMQ-732
Project: ActiveMQ
Type: Bug
Components: Broker
Versions: 4.0
Environment: Linux RHEL 3
Reporter: Maxim Fateev
Assignee: Hiram Chirino
Fix For: 4.1, 4.0.2
Attachments: activemq-data-1-journal.tar.gz, activemq-data-2-journal.tar.gz
The simplest way to reproduce the problem:
1. Remove storage directory.
2. Start broker using the following code:
public static void main(String[] args) throws Exception {
BrokerService broker = new BrokerService();
broker.setPersistent(true);
DefaultPersistenceAdapterFactory pFactory = new
DefaultPersistenceAdapterFactory();
pFactory.setJournalLogFiles(1);
pFactory.setJournalLogFileSize(2048);
broker.setPersistenceFactory(pFactory);
broker.setUseJmx(false);
broker.addConnector(tcp://localhost:61616);
broker.start();
Thread.sleep(1l);
}
3. Shutdown the broker.
4. Start broker.
It enters infinite loop
[ main] BrokerService INFO
ActiveMQ null JMS Message Broker (localhost) is starting
[ main] BrokerService INFO For
help or more information please see: http://incubator.apache.org/activemq/
[ main] JDBCPersistenceAdapter INFO
Database driver recognized: [apache_derby_embedded_jdbc_driver]
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER
VARCHAR(250), MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT,
MSG BLOB, PRIMARY KEY ( ID ) )
[ main] DefaultJDBCAdapter DEBUG Could
not create JDBC tables; The message table already existed. Failure was:
CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER VARCHAR(250),
MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT, MSG BLOB,
PRIMARY KEY ( ID ) ) Message: Table/View 'ACTIVEMQ_MSGS' already exists in
Schema 'APP'. SQLState: X0Y32 Vendor code: 2
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_MIDX ON ACTIVEMQ_MSGS
(MSGID_PROD,MSGID_SEQ)
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_CIDX ON ACTIVEMQ_MSGS (CONTAINER)
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_EIDX ON ACTIVEMQ_MSGS (EXPIRATION)
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL,
CLIENT_ID VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR
VARCHAR(250), LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID,
SUB_NAME))
[ main] DefaultJDBCAdapter DEBUG Could
not create JDBC tables; The message table already existed. Failure was:
CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL, CLIENT_ID
VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR VARCHAR(250),
LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID, SUB_NAME))
Message: Table/View 'ACTIVEMQ_ACKS' already exists in Schema 'APP'. SQLState:
X0Y32 Vendor code: 2
[ main] JDBCPersistenceAdapter DEBUG
Cleaning up old messages.
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: DELETE FROM ACTIVEMQ_MSGS WHERE ( EXPIRATION0 AND
EXPIRATION?) OR ID = ( SELECT min(ACTIVEMQ_ACKS.LAST_ACKED_ID) FROM
ACTIVEMQ_ACKS WHERE ACTIVEMQ_ACKS.CONTAINER=ACTIVEMQ_MSGS.CONTAINER)
[ main] DefaultJDBCAdapter DEBUG Deleted
0 old message(s).
[ main] JDBCPersistenceAdapter DEBUG Cleanup
done.
[ main] JournalPersistenceAdapter INFO Journal
Recovery Started from: Active Journal: using 1 x 0.001953125 Megs at:
/workplace/fateev/install/activemq-4.0-SNAPSHOT/activemq-core/activemq-data/journal
[ main] JournalPersistenceAdapter DEBUG TRACE
Entry: RECOVERED
[Journal Writer] LogFileManager DEBUG
getNextDataRecordLocation offset=53
[Journal Writer] LogFileManager DEBUG
getNextDataRecordLocation offset=97
[Journal Writer] LogFileManager DEBUG
getNextDataRecordLocation overflowing into next logFile=0
[
[jira] Created: (AMQ-780) Suppress logging client exceptions on the broker when the broker is shutting down.
Suppress logging client exceptions on the broker when the broker is shutting down. -- Key: AMQ-780 URL: https://issues.apache.org/activemq/browse/AMQ-780 Project: ActiveMQ Type: Improvement Components: Broker Versions: 4.0 Reporter: Hiram Chirino Assigned to: Hiram Chirino Priority: Minor Fix For: 4.1 When a client is sending async exceptions to the broker, and the borker is shutdown there is a windows where the client connector gets errors from the broker because the client continues to send messaes to the connector even though the broker has been shutdown. We should suppress the logging fo those exceptions on the broker side if the broker has been shutdown and we should send back 1 single connection error to the client informing it that the broker has been shutdown. We should also subsequently stop the client connection so no further messaes are received from the client. -- 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-786) Eliminated an unneed Thread.currentThread().interrupt() in ResponseCorrelator.java
[ https://issues.apache.org/activemq/browse/AMQ-786?page=all ] Hiram Chirino resolved AMQ-786: --- Resolution: Fixed fix in trunk rev 418156 fix in 4.0 rev 418336 Eliminated an unneed Thread.currentThread().interrupt() in ResponseCorrelator.java -- Key: AMQ-786 URL: https://issues.apache.org/activemq/browse/AMQ-786 Project: ActiveMQ Type: Improvement Components: Broker Versions: 4.0 Reporter: Hiram Chirino Assignee: Hiram Chirino Priority: Minor Fix For: 4.1, 4.0.2 -- 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: (GERONIMO-2132) Move activemq gbean integration modules from ActiveMQ to Geronimo
[ http://issues.apache.org/jira/browse/GERONIMO-2132?page=comments#action_12418966 ] Hiram Chirino commented on GERONIMO-2132: - I just recently found out that we need 3 +1 from PMC memebers for RTC. I think the patch that did this failed to get that support. I think we may need to make sure that we do get the 3 +1's from the PMC before we proceed any further. Move activemq gbean integration modules from ActiveMQ to Geronimo - Key: GERONIMO-2132 URL: http://issues.apache.org/jira/browse/GERONIMO-2132 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: ActiveMQ Reporter: Hiram Chirino Fix For: 1.2 Attachments: amq4.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-2135) Improve the ActiveMQ GBeans
[ http://issues.apache.org/jira/browse/GERONIMO-2135?page=all ]
Hiram Chirino resolved GERONIMO-2135:
-
Resolution: Fixed
thanks for the review guys. patch is applied now.
Improve the ActiveMQ GBeans
---
Key: GERONIMO-2135
URL: http://issues.apache.org/jira/browse/GERONIMO-2135
Project: Geronimo
Type: Improvement
Security: public(Regular issues)
Components: ActiveMQ
Reporter: Hiram Chirino
Assignee: Hiram Chirino
Fix For: 1.2
Attachments: GERONIMO-2135.patch
Suggestions by David Jencks:
I think that this gbean adaptation code should be in geronimo rather
than amq. I'm OK with applying it as is but would prefer some issues
to be addressed first or, even better, immediately after the
transfer (assuming it is done with svn mv).
1. DataSourceReference should be replaced by the geronimo class that
does the same thing, ConnectionFactorySource.
2. I think it would be preferable to get the module/configuration
classloader in the constructor as a magic attribute and use it in
BrokerServiceGBeanImpl.doStart rather than the classloader of
BrokerServiceGBeanImpl.
3. Same for TransportConnectorGBeanImpl.
4. This is a question, not really an issue, about this code:
+protected TransportConnector createBrokerConnector(String url)
throws Exception {
+return brokerService.getBrokerContainer().addConnector(url);
+}
To me it seems like this code is combining the functions of factory
object and container. Is this necessary and appropriate? I'd be
more comfortable with
Connector connector = ConnectorFactory.createConnector(url);
brokerService.getBrokerContainer().addConnector(connector);
I find that the combination style typically creates problems whenever
trying to extend stuff, say by wrapping the connector. What do you
think?
5. hardcoding the protocols in ActiveMQManagerGBean seems like a
temporary expedient at best.
6. javadoc on public JMSConnector addConnector( ... in the manager
gbean seems wrong... does not appear to return an object name.
7. Typo and innaccuracies in the first package.html... this stuff is
only going to work in geronimo, jsr77/88 is not enough.
8. I'm not sure exactly what our official policy is but I prefer to
remove public from methods in interfaces since it is the only
choice and implied.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (AMQ-796) Client may shtudown when failover connection is reconnecting. We need to maintain at least 1 non-daemon thread alive.
Client may shtudown when failover connection is reconnecting. We need to maintain at least 1 non-daemon thread alive. -- Key: AMQ-796 URL: https://issues.apache.org/activemq/browse/AMQ-796 Project: ActiveMQ Type: Bug Versions: 4.0 Reporter: Hiram Chirino Fix For: 4.1, 4.0.2 Dejan Reported on the User lists: Hi, after some experiments I found that this problem only exists if there are no other threads in the application. It seems like connection thread dies before it manages to reconnect. By starting another thread in the application, it succeeds to recover from master failure and reconnect to the slave broker. So I have a workaround for now, but it would be nice to make this work even for simple (single-threaded) clients. Regards, Dejan -- 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-799) Handle async ConnectionError that may happen between brokers using a network bridge.
Handle async ConnectionError that may happen between brokers using a network bridge. Key: AMQ-799 URL: https://issues.apache.org/activemq/browse/AMQ-799 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 Reporter: Hiram Chirino Fix For: 4.1, 4.0.2 -- 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-799) Handle async ConnectionError that may happen between brokers using a network bridge.
[ https://issues.apache.org/activemq/browse/AMQ-799?page=all ] Hiram Chirino resolved AMQ-799: --- Resolution: Fixed Handle async ConnectionError that may happen between brokers using a network bridge. Key: AMQ-799 URL: https://issues.apache.org/activemq/browse/AMQ-799 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 Reporter: Hiram Chirino Fix For: 4.1, 4.0.2 -- 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-802) Broker Network connections over SSH tunnels do not get established.
Broker Network connections over SSH tunnels do not get established. --- Key: AMQ-802 URL: https://issues.apache.org/activemq/browse/AMQ-802 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 Reporter: Hiram Chirino Assigned to: Hiram Chirino Fix For: 4.1, 4.0.2 Due to the way that ssh tunnels accept a connection but then close a socket if they cannot establish a connection to the remote host, the network connector fails to re-connect to the remote host when it is started. -- 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-802) Broker Network connections over SSH tunnels do not get established.
[ https://issues.apache.org/activemq/browse/AMQ-802?page=comments#action_36538 ] Hiram Chirino commented on AMQ-802: --- This can even lead to a busy loop as the failover connection establishes a connection and then the network bridge detects that the connection failed and then failover starts again and the loop restarts. Broker Network connections over SSH tunnels do not get established. --- Key: AMQ-802 URL: https://issues.apache.org/activemq/browse/AMQ-802 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 4.1, 4.0.2 Due to the way that ssh tunnels accept a connection but then close a socket if they cannot establish a connection to the remote host, the network connector fails to re-connect to the remote host when it is started. -- 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-803) The static multicast discovery agent should include reconnect logic when it is notified that one of it's sevices failed.
The static multicast discovery agent should include reconnect logic when it is notified that one of it's sevices failed. Key: AMQ-803 URL: https://issues.apache.org/activemq/browse/AMQ-803 Project: ActiveMQ Type: New Feature Reporter: Hiram Chirino Assigned to: Hiram Chirino Fix For: 4.0.2, 4.1 This could substancially make the network connector code simpler since it does not need to deal with failover connections which cause problems for the connector. -- 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-804) Use of Temporary Destinations over broker networks can cause the network bridges to die.
Use of Temporary Destinations over broker networks can cause the network bridges to die. Key: AMQ-804 URL: https://issues.apache.org/activemq/browse/AMQ-804 Project: ActiveMQ Type: Bug Components: Broker Reporter: Hiram Chirino Fix For: 4.1 And when the bridge dies, it is not re-established. -- 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-804) Use of Temporary Destinations over broker networks can cause the network bridges to die.
[ https://issues.apache.org/activemq/browse/AMQ-804?page=comments#action_36540 ] Hiram Chirino commented on AMQ-804: --- I noticed that the issue is cause when the client the created the temporary destination and a subscription to that temporary destination is killed. The remote broker sometimes gets the destination removed and consumer removed commands in the wrong order. The error happens when the destination removed arrives before the consumer removed at the network bridge. When the destination remove command executes it fails because it still has a subscription active on it. Use of Temporary Destinations over broker networks can cause the network bridges to die. Key: AMQ-804 URL: https://issues.apache.org/activemq/browse/AMQ-804 Project: ActiveMQ Type: Bug Components: Broker Reporter: Hiram Chirino Fix For: 4.1 And when the bridge dies, it is not re-established. -- 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-805) Restart network bridges if they ever get stopped
Restart network bridges if they ever get stopped Key: AMQ-805 URL: https://issues.apache.org/activemq/browse/AMQ-805 Project: ActiveMQ Type: Improvement Reporter: Hiram Chirino Assigned to: Hiram Chirino Right now it seems like we only trap remote exceptions and then restart the bridge. I think we should restart the network bridge if the bridge fails for any reason. -- 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-808) The DestinationMap removeAll is removing too many nodes out of the map.
The DestinationMap removeAll is removing too many nodes out of the map.
---
Key: AMQ-808
URL: https://issues.apache.org/activemq/browse/AMQ-808
Project: ActiveMQ
Type: Bug
Components: Broker
Versions: 4.0
Reporter: Hiram Chirino
Assigned to: Hiram Chirino
Fix For: 4.1, 4.0.2
This was initially noticed because at times avisoryies stopped working for some
cases. This is due to the way the Region uses a DestinationMap to find all the
destinations that match a subscription.
A unit test that fails looks like:
public void testAddAndRemove() throws Exception {
put(FOO.A, v1);
assertMapValue(FOO., v1);
put(FOO.B, v2);
assertMapValue(FOO., v1, v2);
Set set = map.removeAll(createDestination(FOO.A));
assertMapValue(FOO., v2); // This Fails. nothing is left in FOO.
}
--
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-808) The DestinationMap removeAll is removing too many nodes out of the map.
[ https://issues.apache.org/activemq/browse/AMQ-808?page=all ]
Hiram Chirino updated AMQ-808:
--
Description:
This was initially noticed because at times avisoryies stopped working for some
cases. This is due to the way the Region uses a DestinationMap to find all the
destinations that match a subscription.
A unit test that fails looks like:
{code:java}
public void testAddAndRemove() throws Exception {
put(FOO.A, v1);
assertMapValue(FOO., v1);
put(FOO.B, v2);
assertMapValue(FOO., v1, v2);
Set set = map.removeAll(createDestination(FOO.A));
assertMapValue(FOO., v2); // This Fails. nothing is left in FOO.
}
{code}
was:
This was initially noticed because at times avisoryies stopped working for some
cases. This is due to the way the Region uses a DestinationMap to find all the
destinations that match a subscription.
A unit test that fails looks like:
public void testAddAndRemove() throws Exception {
put(FOO.A, v1);
assertMapValue(FOO., v1);
put(FOO.B, v2);
assertMapValue(FOO., v1, v2);
Set set = map.removeAll(createDestination(FOO.A));
assertMapValue(FOO., v2); // This Fails. nothing is left in FOO.
}
The DestinationMap removeAll is removing too many nodes out of the map.
---
Key: AMQ-808
URL: https://issues.apache.org/activemq/browse/AMQ-808
Project: ActiveMQ
Type: Bug
Components: Broker
Versions: 4.0
Reporter: Hiram Chirino
Assignee: Hiram Chirino
Fix For: 4.1, 4.0.2
This was initially noticed because at times avisoryies stopped working for
some cases. This is due to the way the Region uses a DestinationMap to find
all the destinations that match a subscription.
A unit test that fails looks like:
{code:java}
public void testAddAndRemove() throws Exception {
put(FOO.A, v1);
assertMapValue(FOO., v1);
put(FOO.B, v2);
assertMapValue(FOO., v1, v2);
Set set = map.removeAll(createDestination(FOO.A));
assertMapValue(FOO., v2); // This Fails. nothing is left in FOO.
}
{code}
--
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-808) The DestinationMap removeAll is removing too many nodes out of the map.
[ https://issues.apache.org/activemq/browse/AMQ-808?page=all ]
Hiram Chirino resolved AMQ-808:
---
Resolution: Fixed
fixed.
The DestinationMap removeAll is removing too many nodes out of the map.
---
Key: AMQ-808
URL: https://issues.apache.org/activemq/browse/AMQ-808
Project: ActiveMQ
Type: Bug
Components: Broker
Versions: 4.0
Reporter: Hiram Chirino
Assignee: Hiram Chirino
Fix For: 4.1, 4.0.2
This was initially noticed because at times avisoryies stopped working for
some cases. This is due to the way the Region uses a DestinationMap to find
all the destinations that match a subscription.
A unit test that fails looks like:
{code:java}
public void testAddAndRemove() throws Exception {
put(FOO.A, v1);
assertMapValue(FOO., v1);
put(FOO.B, v2);
assertMapValue(FOO., v1, v2);
Set set = map.removeAll(createDestination(FOO.A));
assertMapValue(FOO., v2); // This Fails. nothing is left in FOO.
}
{code}
--
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-809) Make it easier to just enable the command trancing of the TransportLogger.
Make it easier to just enable the command trancing of the TransportLogger. -- Key: AMQ-809 URL: https://issues.apache.org/activemq/browse/AMQ-809 Project: ActiveMQ Type: Improvement Versions: 4.0 Reporter: Hiram Chirino Assigned to: Hiram Chirino Fix For: 4.1, 4.0.2 The log4j category for trace logging of message currently org.apache.activemq.transport.TransportLogger:n this makes it hard to enable the debug logging of just the trace messages since org.apache.activemq.transport is too broad of a category and TransportLogger:n is a variable category name. We should make it org.apache.activemq.transport.TransportLogger.Connection:n so that it's easier to just enable the logging for this one component. Also log usage of the other request methods. -- 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-608) Change logging level of some DemandForwardingBridge log messages.
[ https://issues.apache.org/activemq/browse/AMQ-608?page=all ] Hiram Chirino resolved AMQ-608: --- Resolution: Fixed Patch applied! Thanks Kevin! Change logging level of some DemandForwardingBridge log messages. - Key: AMQ-608 URL: https://issues.apache.org/activemq/browse/AMQ-608 Project: ActiveMQ Type: Improvement Components: Broker Versions: 4.0 Reporter: Kevin Yaussy Assignee: Hiram Chirino Fix For: 4.1, 4.0.2 Attachments: DemandForwardingBridge.java, DemandForwardingBridgeSupport.java, DemandForwardingBridgeSupport.patch, FailoverTransport.java, FailoverTransport.java, FailoverTransport.patch, InactivityMonitor.patch, InactivityMonitor.patch2 In DemandForwardingBridge, I'd like to be able to see subscription messages (and unsubscription messages), but not bridging messages. Both classes of log messages are log.trace. Seems like the bridging messages should remain trace, as you would want to look at that when you are doing pretty detailed debugging. However, I'd like to see subscribe/unsubscribe messages all the time. If those could be either info or debug, that would allow me to turn those on separately. I realize that I can see what is currently subscribed via the JMX console. However, seeing the subscribe/unsubscribe messages will allow diagnostics over time - who subscribed when type of questions. Mainly, I'm referring to messages logged as trace in: DemandForwardingBridge.serviceRemoteConsumerAdvisory DemandForwardingBridge.removeDemandSubscription -- 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-813) can get a shutdown hang when using embedded broker with VM transport along with the activemq-web module
[ https://issues.apache.org/activemq/browse/AMQ-813?page=all ] Hiram Chirino resolved AMQ-813: --- Fix Version: 4.0.2 Resolution: Fixed Assign To: Hiram Chirino Fixed: http://svn.apache.org/viewvc/incubator/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/transport/vm/VMTransport.java?r1=415306r2=420714pathrev=420714 The VMTransport's oneway method was dropping the send request when the peer was disconnected like in the case where the broker is shutdown at the same time that the client is shutdown. can get a shutdown hang when using embedded broker with VM transport along with the activemq-web module --- Key: AMQ-813 URL: https://issues.apache.org/activemq/browse/AMQ-813 Project: ActiveMQ Type: Bug Reporter: james strachan Assignee: Hiram Chirino Fix For: 4.1, 4.0.2 See attached thread dump. I think we just need to use a timeout on the close operations (such as to close consumers, sessions, producers) Full thread dump Java HotSpot(TM) Client VM (1.5.0_04-b05 mixed mode, sharing): Shutdown prio=1 tid=0x08385960 nid=0x5e99 in Object.wait() [0xaed7d000..0xaed7e130] at java.lang.Object.wait(Native Method) - waiting on 0x88af01c8 (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 0x88af01c8 (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:41) at org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:72) at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1130) at org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1660) at org.apache.activemq.ActiveMQMessageConsumer.close(ActiveMQMessageConsumer.java:516) at org.apache.activemq.web.WebClient.closeConsumers(WebClient.java:135) - locked 0x893e6558 (a org.apache.activemq.web.WebClient) at org.apache.activemq.web.WebClient.close(WebClient.java:145) - locked 0x893e6558 (a org.apache.activemq.web.WebClient) at org.apache.activemq.web.WebClient.valueUnbound(WebClient.java:318) at org.mortbay.jetty.servlet.AbstractSessionManager$Session.unbindValue(AbstractSessionManager.java:899) at org.mortbay.jetty.servlet.AbstractSessionManager$Session.invalidate(AbstractSessionManager.java:755) - locked 0x893caa88 (a org.mortbay.jetty.servlet.HashSessionManager$Session) at org.mortbay.jetty.servlet.AbstractSessionManager.doStop(AbstractSessionManager.java:551) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:63) at org.mortbay.jetty.servlet.SessionHandler.doStop(SessionHandler.java:124) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:63) at org.mortbay.jetty.handler.HandlerWrapper.doStop(HandlerWrapper.java:131) at org.mortbay.jetty.handler.ContextHandler.doStop(ContextHandler.java:467) at org.mortbay.jetty.webapp.WebAppContext.doStop(WebAppContext.java:477) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:63) at org.mortbay.jetty.handler.HandlerCollection.doStop(HandlerCollection.java:173) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:63) at org.mortbay.jetty.handler.HandlerCollection.doStop(HandlerCollection.java:173) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:63) at org.mortbay.jetty.handler.HandlerWrapper.doStop(HandlerWrapper.java:131) at org.mortbay.jetty.Server.doStop(Server.java:242) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:63) at org.mortbay.jetty.Server$ShutdownHookThread.run(Server.java:450) -- 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-732) Infinite recovery loop.
[
https://issues.apache.org/activemq/browse/AMQ-732?page=comments#action_36556 ]
Hiram Chirino commented on AMQ-732:
---
We need to build activeio beta-4 and ship with that.
Infinite recovery loop.
---
Key: AMQ-732
URL: https://issues.apache.org/activemq/browse/AMQ-732
Project: ActiveMQ
Type: Bug
Components: Broker
Versions: 4.0
Environment: Linux RHEL 3
Reporter: Maxim Fateev
Assignee: Hiram Chirino
Fix For: 4.1, 4.0.2
Attachments: activemq-data-1-journal.tar.gz, activemq-data-2-journal.tar.gz
The simplest way to reproduce the problem:
1. Remove storage directory.
2. Start broker using the following code:
public static void main(String[] args) throws Exception {
BrokerService broker = new BrokerService();
broker.setPersistent(true);
DefaultPersistenceAdapterFactory pFactory = new
DefaultPersistenceAdapterFactory();
pFactory.setJournalLogFiles(1);
pFactory.setJournalLogFileSize(2048);
broker.setPersistenceFactory(pFactory);
broker.setUseJmx(false);
broker.addConnector(tcp://localhost:61616);
broker.start();
Thread.sleep(1l);
}
3. Shutdown the broker.
4. Start broker.
It enters infinite loop
[ main] BrokerService INFO
ActiveMQ null JMS Message Broker (localhost) is starting
[ main] BrokerService INFO For
help or more information please see: http://incubator.apache.org/activemq/
[ main] JDBCPersistenceAdapter INFO
Database driver recognized: [apache_derby_embedded_jdbc_driver]
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER
VARCHAR(250), MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT,
MSG BLOB, PRIMARY KEY ( ID ) )
[ main] DefaultJDBCAdapter DEBUG Could
not create JDBC tables; The message table already existed. Failure was:
CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER VARCHAR(250),
MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT, MSG BLOB,
PRIMARY KEY ( ID ) ) Message: Table/View 'ACTIVEMQ_MSGS' already exists in
Schema 'APP'. SQLState: X0Y32 Vendor code: 2
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_MIDX ON ACTIVEMQ_MSGS
(MSGID_PROD,MSGID_SEQ)
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_CIDX ON ACTIVEMQ_MSGS (CONTAINER)
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_EIDX ON ACTIVEMQ_MSGS (EXPIRATION)
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL,
CLIENT_ID VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR
VARCHAR(250), LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID,
SUB_NAME))
[ main] DefaultJDBCAdapter DEBUG Could
not create JDBC tables; The message table already existed. Failure was:
CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL, CLIENT_ID
VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR VARCHAR(250),
LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID, SUB_NAME))
Message: Table/View 'ACTIVEMQ_ACKS' already exists in Schema 'APP'. SQLState:
X0Y32 Vendor code: 2
[ main] JDBCPersistenceAdapter DEBUG
Cleaning up old messages.
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: DELETE FROM ACTIVEMQ_MSGS WHERE ( EXPIRATION0 AND
EXPIRATION?) OR ID = ( SELECT min(ACTIVEMQ_ACKS.LAST_ACKED_ID) FROM
ACTIVEMQ_ACKS WHERE ACTIVEMQ_ACKS.CONTAINER=ACTIVEMQ_MSGS.CONTAINER)
[ main] DefaultJDBCAdapter DEBUG Deleted
0 old message(s).
[ main] JDBCPersistenceAdapter DEBUG Cleanup
done.
[ main] JournalPersistenceAdapter INFO Journal
Recovery Started from: Active Journal: using 1 x 0.001953125 Megs at:
/workplace/fateev/install/activemq-4.0-SNAPSHOT/activemq-core/activemq-data/journal
[ main] JournalPersistenceAdapter DEBUG TRACE
Entry: RECOVERED
[Journal Writer] LogFileManager DEBUG
getNextDataRecordLocation offset=53
[Journal Writer] LogFileManager DEBUG
getNextDataRecordLocation offset=97
[Journal Writer] LogFileManager DEBUG
getNextDataRecordLocation overflowing into next logFile=0
[
[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_36560 ] Hiram Chirino commented on AMQ-816: --- Sounds similar to the fanout transport we currently have. Except that in the fanout transport it's backwards. We broadcast the publish to multiple brokers and only consume from 1. new transport for load balancing client requests across many brokers Key: AMQ-816 URL: https://issues.apache.org/activemq/browse/AMQ-816 Project: ActiveMQ 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] Updated: (AMQ-361) duplicate delivery, already consumed messages are reconsumed after server restart
[ https://issues.apache.org/activemq/browse/AMQ-361?page=all ] Hiram Chirino updated AMQ-361: -- Fix Version: 4.1 (was: 4.0.1) Version: 4.0 (was: 3.1) Could you please provide a test case that shows this in action? duplicate delivery, already consumed messages are reconsumed after server restart - Key: AMQ-361 URL: https://issues.apache.org/activemq/browse/AMQ-361 Project: ActiveMQ Type: Bug Components: Broker, Message Store, JCA Container Versions: 4.0 Environment: windows xp, jdk 1.5, embedded activemq 3.1 broker, jboss 4.02, persistent messages with derby db. Reporter: Gokturk Ozer Fix For: 4.1 Attachments: 1.log I am running an embedded activemq broker inside jboss server, I send 1000 messages with ~10K size each to a queue, these messages are consumed by MDBs. After all the messages are consumed, I check the queue via hermes, it also shows no message in the queue. Everything works perfect up to this point. I observe the problem after I stop the jboss server. I connect to derby database via networkserver, I still see some messages in activemq_msgs table. I shutdown derby networkserver and start jboss again, I see from the log that some of the messages which were consumed previously, are being consumed again. If I start the server without deploying the MDB and check the queue via hermes, I see some but not all the messages which were consumed previously still in the queue, before restart hermes was showing no 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] Assigned: (AMQ-480) add consume ability to openwire-c
[ https://issues.apache.org/activemq/browse/AMQ-480?page=all ] Hiram Chirino reassigned AMQ-480: - Assign To: (was: Hiram Chirino) Will revisit this later as time allows. add consume ability to openwire-c - Key: AMQ-480 URL: https://issues.apache.org/activemq/browse/AMQ-480 Project: ActiveMQ Type: Improvement Reporter: james strachan Fix For: 4.3 -- 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-773) Build ships without incompatitable commons-logging and log4j
[ https://issues.apache.org/activemq/browse/AMQ-773?page=all ] Hiram Chirino resolved AMQ-773: --- Fix Version: 4.1 Resolution: Fixed Assign To: Hiram Chirino upgraded to 1.1 Build ships without incompatitable commons-logging and log4j Key: AMQ-773 URL: https://issues.apache.org/activemq/browse/AMQ-773 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0.1 Reporter: Matt Parker Assignee: Hiram Chirino Fix For: 4.1, 4.0.2 commons-logging calls Category.log in lo4j, which is depericated in the version of log4j that ships in 4.0.1. Please upgrade the commons-log to commons-logging-1.1.jar -- 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-719) OpenWire ActiveMQTextMessage not sharable between JMS client and dotNet client
[ https://issues.apache.org/activemq/browse/AMQ-719?page=all ] Hiram Chirino resolved AMQ-719: --- Resolution: Fixed Patch applied! Thanks! OpenWire ActiveMQTextMessage not sharable between JMS client and dotNet client -- Key: AMQ-719 URL: https://issues.apache.org/activemq/browse/AMQ-719 Project: ActiveMQ Type: Bug Components: JMS client Versions: 4.0 Environment: ActiveMQ incubator 4.0 release - windows xp pro - jdk1.5 - dotNet2003 - openwire dotnet client from svn head Reporter: James Bradt Fix For: 4.1, 4.0.2 The payload content for a JMS message contains initial bytes for the length of the text string. The payload content for an dotNet openwire content does not contain this information. This mismatch in payload results in invalid payloads when passing jms messages between technologies. -- 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] Reopened: (AMQ-701) Unix scripts in distro should have mode 755
[ https://issues.apache.org/activemq/browse/AMQ-701?page=all ] Hiram Chirino reopened AMQ-701: --- Assign To: Hiram Chirino (was: Adrian Co) This will be fixed in the 4.1 releases. The maven assembly descriptor needs to be configured with this information. Unix scripts in distro should have mode 755 --- Key: AMQ-701 URL: https://issues.apache.org/activemq/browse/AMQ-701 Project: ActiveMQ Type: Improvement Components: Broker Versions: 4.0 RC3, 4.0 RC2, 4.0 M4 Reporter: Jason Dillon Assignee: Hiram Chirino Fix For: 4.1 All of the unix scripts in the distro should have their mode set to 755, as in: cd bin/ chmod 755 activemq browse bstat list query shutdown Users should be able to unzip/untgz the distro and then run bin/activemq with out any extra steps. zipfileset supports a filemode attribute, and tarfileset suports a mode attribute that allow you to set the right mode on the archived files. See the release target here for a real example: http://svn.sourceforge.net/viewcvs.cgi/p4spam/p4spam/trunk/build.xml?view=markuprev=57 -- 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-701) Unix scripts in distro should have mode 755
[ https://issues.apache.org/activemq/browse/AMQ-701?page=all ] Hiram Chirino resolved AMQ-701: --- Resolution: Fixed Resolved in trunk rev 421396 Unix scripts in distro should have mode 755 --- Key: AMQ-701 URL: https://issues.apache.org/activemq/browse/AMQ-701 Project: ActiveMQ Type: Improvement Components: Broker Versions: 4.0 RC3, 4.0 RC2, 4.0 M4 Reporter: Jason Dillon Assignee: Hiram Chirino Fix For: 4.1 All of the unix scripts in the distro should have their mode set to 755, as in: cd bin/ chmod 755 activemq browse bstat list query shutdown Users should be able to unzip/untgz the distro and then run bin/activemq with out any extra steps. zipfileset supports a filemode attribute, and tarfileset suports a mode attribute that allow you to set the right mode on the archived files. See the release target here for a real example: http://svn.sourceforge.net/viewcvs.cgi/p4spam/p4spam/trunk/build.xml?view=markuprev=57 -- 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-701) Unix scripts in distro should have mode 755
[ https://issues.apache.org/activemq/browse/AMQ-701?page=comments#action_36575 ] Hiram Chirino commented on AMQ-701: --- I think going with patform specific distributions is the way to go. It solves problems like Windows users not being able to read the README and LICENSE files due to EOL issues. Same thing applies to the eamples and documentation. I would be open to creating *-windows.zip, *-windows.tar.gz, *-unix.zip, and *-unix.tar.gz if you really think that folks on both patforms want to have the zip and tar.gz options. But I don't think that is the case either. Also when a user uses cygwin, he's going to want to use the unix distribution since the EOL characters are unix style and he can use .sh files to launch activemq. So I'm not sure there is a down side this yet. Unix scripts in distro should have mode 755 --- Key: AMQ-701 URL: https://issues.apache.org/activemq/browse/AMQ-701 Project: ActiveMQ Type: Improvement Components: Broker Versions: 4.0 RC3, 4.0 RC2, 4.0 M4 Reporter: Jason Dillon Assignee: Hiram Chirino Fix For: 4.1 All of the unix scripts in the distro should have their mode set to 755, as in: cd bin/ chmod 755 activemq browse bstat list query shutdown Users should be able to unzip/untgz the distro and then run bin/activemq with out any extra steps. zipfileset supports a filemode attribute, and tarfileset suports a mode attribute that allow you to set the right mode on the archived files. See the release target here for a real example: http://svn.sourceforge.net/viewcvs.cgi/p4spam/p4spam/trunk/build.xml?view=markuprev=57 -- 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: (SM-483) Code snippets missing from soem static HTML pages
[ https://issues.apache.org/activemq/browse/SM-483?page=all ] Hiram Chirino resolved SM-483. -- Resolution: Fixed I exported all the pages and the sniplets are now working again. Code snippets missing from soem static HTML pages - Key: SM-483 URL: https://issues.apache.org/activemq/browse/SM-483 Project: ServiceMix Issue Type: Bug Reporter: Bruce Snyder Assigned To: Hiram Chirino I've run across a couple of pages where code snippets are missing from the static HTML pages but are present in the wiki pages. I'm assuming that this is maybe due to some issue with the wiki -- html export plugin, but I'm no expert. Here are a couple pages where code snippets are missing: http://www.servicemix.org/site/saaj.html http://servicemix.org/site/pojo-support.html -- 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-788) MapMessage should support largs String values
[ https://issues.apache.org/activemq/browse/AMQ-788?page=all ] Hiram Chirino resolved AMQ-788. --- Fix Version/s: 4.0.2 Resolution: Fixed applied to 4.0 branch rev 425426 MapMessage should support largs String values - Key: AMQ-788 URL: https://issues.apache.org/activemq/browse/AMQ-788 Project: ActiveMQ Issue Type: Improvement Affects Versions: 4.0 Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.0.2, 4.1 Currently the largest string value that you can put in a MapMessage is about 32k big. We should support bigger String values also. -- 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: (XBEAN-33) [RTC] Add a new Wiki source generator that generates wiki markup so that reference docs can be pasted into confluence.
[RTC] Add a new Wiki source generator that generates wiki markup so that reference docs can be pasted into confluence. -- Key: XBEAN-33 URL: http://issues.apache.org/jira/browse/XBEAN-33 Project: XBean Issue Type: RTC Components: maven-plugin, spring Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 2.6 Added a new generator plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (XBEAN-33) [RTC] Add a new Wiki source generator that generates wiki markup so that reference docs can be pasted into confluence.
[ http://issues.apache.org/jira/browse/XBEAN-33?page=comments#action_12424992 ] Hiram Chirino commented on XBEAN-33: Please note that I also added more metadata to the ElementMapping so that the wiki generator could group and cross link element references based on Java types. [RTC] Add a new Wiki source generator that generates wiki markup so that reference docs can be pasted into confluence. -- Key: XBEAN-33 URL: http://issues.apache.org/jira/browse/XBEAN-33 Project: XBean Issue Type: RTC Components: spring, maven-plugin Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 2.6 Attachments: XBEAN-33.patch Added a new generator plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (XBEAN-33) [RTC] Add a new Wiki source generator that generates wiki markup so that reference docs can be pasted into confluence.
[ http://issues.apache.org/jira/browse/XBEAN-33?page=all ] Hiram Chirino updated XBEAN-33: --- Attachment: XBEAN-33.patch Attaching patch. [RTC] Add a new Wiki source generator that generates wiki markup so that reference docs can be pasted into confluence. -- Key: XBEAN-33 URL: http://issues.apache.org/jira/browse/XBEAN-33 Project: XBean Issue Type: RTC Components: spring, maven-plugin Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 2.6 Attachments: XBEAN-33.patch Added a new generator plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (XBEAN-36) [RTC] Support annotating properties with the ProperyEditor that should be used when wiring in the value.
[RTC] Support annotating properties with the ProperyEditor that should be used when wiring in the value. Key: XBEAN-36 URL: http://issues.apache.org/jira/browse/XBEAN-36 Project: XBean Issue Type: New Feature Components: spring Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 2.6 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (XBEAN-36) [RTC] Support annotating properties with the ProperyEditor that should be used when wiring in the value.
[ http://issues.apache.org/jira/browse/XBEAN-36?page=all ] Hiram Chirino updated XBEAN-36: --- Attachment: XBEAN-36.patch Attaching patch that implements the requirment. [RTC] Support annotating properties with the ProperyEditor that should be used when wiring in the value. Key: XBEAN-36 URL: http://issues.apache.org/jira/browse/XBEAN-36 Project: XBean Issue Type: New Feature Components: spring Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 2.6 Attachments: XBEAN-36.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (XBEAN-36) [RTC] Support annotating properties with the ProperyEditor that should be used when wiring in the value.
[ http://issues.apache.org/jira/browse/XBEAN-36?page=all ]
Hiram Chirino updated XBEAN-36:
---
Description:
This patch allows you to configure a PropertyEditor for any property. For
example, if you annotate a property as follows:
/**
* Sets the amount of beer remaining in the keg (in ml)
*
* @org.apache.xbean.Property
propertyEditor=org.apache.xbean.spring.example.MilliLittersPropertyEditor
* @param remaining
*/
public void setRemaining(long remaining) {
this.remaining = remaining;
}
Then when you configure the value of the 'remaining' property in xbean then the
MilliLittersPropertyEditor will be used to convert the string value to a long.
In the test case, our MilliLittersPropertyEditor can handle converting
different units of measurement to ml. For example:
beans xmlns:x=http://xbean.apache.org/schemas/pizza;
x:keg id=ml1000 remaining=1000 ml/
x:keg id=pints5 remaining=5 pints/
x:keg id=liter20 remaining=20 liter/
x:keg id=empty remaining=0/
/beans
[RTC] Support annotating properties with the ProperyEditor that should be
used when wiring in the value.
Key: XBEAN-36
URL: http://issues.apache.org/jira/browse/XBEAN-36
Project: XBean
Issue Type: New Feature
Components: spring
Reporter: Hiram Chirino
Assigned To: Hiram Chirino
Fix For: 2.6
Attachments: XBEAN-36.patch
This patch allows you to configure a PropertyEditor for any property. For
example, if you annotate a property as follows:
/**
* Sets the amount of beer remaining in the keg (in ml)
*
* @org.apache.xbean.Property
propertyEditor=org.apache.xbean.spring.example.MilliLittersPropertyEditor
* @param remaining
*/
public void setRemaining(long remaining) {
this.remaining = remaining;
}
Then when you configure the value of the 'remaining' property in xbean then
the MilliLittersPropertyEditor will be used to convert the string value to a
long. In the test case, our MilliLittersPropertyEditor can handle converting
different units of measurement to ml. For example:
beans xmlns:x=http://xbean.apache.org/schemas/pizza;
x:keg id=ml1000 remaining=1000 ml/
x:keg id=pints5 remaining=5 pints/
x:keg id=liter20 remaining=20 liter/
x:keg id=empty remaining=0/
/beans
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (XBEAN-33) [RTC] Add a new Wiki source generator that generates wiki markup so that reference docs can be pasted into confluence.
[ http://issues.apache.org/jira/browse/XBEAN-33?page=comments#action_12426009 ] Hiram Chirino commented on XBEAN-33: The one cool thing is that since we are moving to Confluence generated websites, this would produce reference documentation that has the same look and feel. [RTC] Add a new Wiki source generator that generates wiki markup so that reference docs can be pasted into confluence. -- Key: XBEAN-33 URL: http://issues.apache.org/jira/browse/XBEAN-33 Project: XBean Issue Type: RTC Components: spring, maven-plugin Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 2.6 Attachments: XBEAN-33.patch Added a new generator plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/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_36711 ] Hiram Chirino commented on AMQ-855: --- I don't think this is a valid need. If each server/worker thread only creates 1 consumer with a prefetch of 1 then the jobs will be proccessed in 11 minutes. I think the problem is occuring becuse each sever/work thread is creating multiple consumers and each has a prefetch. Mutliple consumers can be avoided by using consumers that use destination wild cards. 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] Commented: (XBEAN-36) [RTC] Support annotating properties with the ProperyEditor that should be used when wiring in the value.
[
http://issues.apache.org/jira/browse/XBEAN-36?page=comments#action_12427039 ]
Hiram Chirino commented on XBEAN-36:
good catch. I'll fix it in a jiffy.
[RTC] Support annotating properties with the ProperyEditor that should be
used when wiring in the value.
Key: XBEAN-36
URL: http://issues.apache.org/jira/browse/XBEAN-36
Project: XBean
Issue Type: New Feature
Components: spring
Reporter: Hiram Chirino
Assigned To: Hiram Chirino
Fix For: 2.6
Attachments: XBEAN-36.patch
This patch allows you to configure a PropertyEditor for any property. For
example, if you annotate a property as follows:
/**
* Sets the amount of beer remaining in the keg (in ml)
*
* @org.apache.xbean.Property
propertyEditor=org.apache.xbean.spring.example.MilliLittersPropertyEditor
* @param remaining
*/
public void setRemaining(long remaining) {
this.remaining = remaining;
}
Then when you configure the value of the 'remaining' property in xbean then
the MilliLittersPropertyEditor will be used to convert the string value to a
long. In the test case, our MilliLittersPropertyEditor can handle converting
different units of measurement to ml. For example:
beans xmlns:x=http://xbean.apache.org/schemas/pizza;
x:keg id=ml1000 remaining=1000 ml/
x:keg id=pints5 remaining=5 pints/
x:keg id=liter20 remaining=20 liter/
x:keg id=empty remaining=0/
/beans
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-792) allow asynchronous dispatch to consumers in the broker for non-durable topics
[ https://issues.apache.org/activemq/browse/AMQ-792?page=all ] Hiram Chirino updated AMQ-792: -- Fix Version/s: 4.0.3 Applied fix to 4.0 branch in revision 431369. allow asynchronous dispatch to consumers in the broker for non-durable topics - Key: AMQ-792 URL: https://issues.apache.org/activemq/browse/AMQ-792 Project: ActiveMQ Issue Type: Improvement Components: Broker Reporter: james strachan Fix For: 4.1, 4.0.3 We typically use the current thread in the broker to dispatch to all the available non-durable consumers for performance - as this hugely reduces the context switching and increases performance. However (see AMQ-688) sometimes this can cause one dead consumer to block a producer. Some folks may want to switch this strategy to use slower asynchronous dispatch with a thread pool to reduce the risk of blocking a producer at the expensive of lower performance -- 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-848) Consolidate all LICENSE files to a single file.
[ https://issues.apache.org/activemq/browse/AMQ-848?page=all ] Hiram Chirino resolved AMQ-848. --- Fix Version/s: 4.0.2 Resolution: Fixed Consolidate all LICENSE files to a single file. --- Key: AMQ-848 URL: https://issues.apache.org/activemq/browse/AMQ-848 Project: ActiveMQ Issue Type: Improvement Affects Versions: 4.0.2 Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.1, 4.0.2 For an example see: http://www.apache.org/dev/release.html -- 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] Closed: (GERONIMO-2132) Move activemq gbean integration modules from ActiveMQ to Geronimo
[ http://issues.apache.org/jira/browse/GERONIMO-2132?page=all ] Hiram Chirino closed GERONIMO-2132. --- Resolution: Fixed good point. closing. Move activemq gbean integration modules from ActiveMQ to Geronimo - Key: GERONIMO-2132 URL: http://issues.apache.org/jira/browse/GERONIMO-2132 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: ActiveMQ Reporter: Hiram Chirino Assigned To: Jason Dillon Fix For: 1.2 Attachments: amq4.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-886) Timing bug could cause duplicate client id exception in network code.
Timing bug could cause duplicate client id exception in network code. - Key: AMQ-886 URL: https://issues.apache.org/activemq/browse/AMQ-886 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.0 Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.0.3, 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] Created: (AMQ-887) Allow temp destination message bridging to be disable across demand based bridges.
Allow temp destination message bridging to be disable across demand based bridges. -- Key: AMQ-887 URL: https://issues.apache.org/activemq/browse/AMQ-887 Project: ActiveMQ Issue Type: New Feature Reporter: Hiram Chirino Assigned To: Hiram Chirino 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] Commented: (AMQ-886) Timing bug could cause duplicate client id exception in network code.
[ https://issues.apache.org/activemq/browse/AMQ-886?page=comments#action_36815 ] Hiram Chirino commented on AMQ-886: --- Applied fix to trunk in rev 433244 Timing bug could cause duplicate client id exception in network code. - Key: AMQ-886 URL: https://issues.apache.org/activemq/browse/AMQ-886 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.0 Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.1, 4.0.3 -- 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-887) Allow temp destination message bridging to be disable across demand based bridges.
[ https://issues.apache.org/activemq/browse/AMQ-887?page=comments#action_36816 ] Hiram Chirino commented on AMQ-887: --- Since there currently exists a problme where the network bridges fail when temp destinations are used across them, the default setting should be to diable temp destination bridging untill we get that fixed. Allow temp destination message bridging to be disable across demand based bridges. -- Key: AMQ-887 URL: https://issues.apache.org/activemq/browse/AMQ-887 Project: ActiveMQ Issue Type: New Feature Reporter: Hiram Chirino Assigned To: Hiram Chirino 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] Created: (AMQ-888) Licence headers missing from several source files.
Licence headers missing from several source files.
--
Key: AMQ-888
URL: https://issues.apache.org/activemq/browse/AMQ-888
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 4.0
Reporter: Hiram Chirino
Assigned To: Hiram Chirino
Fix For: 4.1, 4.0.2
robert burrell donkin reported:
{quote}
missing license headers from some of the files i checked at random
gives me concerns. for example:
maven-bundle-plugin/src/main/java/org/apache/activemq/maven/BundleMojo.java
activemq-web-demo worries me: there are a lot of files without license
headers and some which have them were not created at the ASF (which is
ok but gives me concerns about the rest).
i would like to see the issue of licenses in the source tidied up
before this release ships. i haven't gone through every file but IMO
this needs to be done.
{quote}
--
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-888) Licence headers missing from several source files.
[ https://issues.apache.org/activemq/browse/AMQ-888?page=all ]
Hiram Chirino updated AMQ-888:
--
Attachment: findunlicensed.pl
Using the attached perl script to find the source files that do not have a
licence header attached.
Licence headers missing from several source files.
--
Key: AMQ-888
URL: https://issues.apache.org/activemq/browse/AMQ-888
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 4.0
Reporter: Hiram Chirino
Assigned To: Hiram Chirino
Fix For: 4.1, 4.0.2
Attachments: findunlicensed.pl
robert burrell donkin reported:
{quote}
missing license headers from some of the files i checked at random
gives me concerns. for example:
maven-bundle-plugin/src/main/java/org/apache/activemq/maven/BundleMojo.java
activemq-web-demo worries me: there are a lot of files without license
headers and some which have them were not created at the ASF (which is
ok but gives me concerns about the rest).
i would like to see the issue of licenses in the source tidied up
before this release ships. i haven't gone through every file but IMO
this needs to be done.
{quote}
--
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-888) Licence headers missing from several source files.
[
https://issues.apache.org/activemq/browse/AMQ-888?page=comments#action_36818 ]
Hiram Chirino commented on AMQ-888:
---
added a bunch of licence headers
* in trunk in rev 433286
* in 4.0 branch in rev 433295
Licence headers missing from several source files.
--
Key: AMQ-888
URL: https://issues.apache.org/activemq/browse/AMQ-888
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 4.0
Reporter: Hiram Chirino
Assigned To: Hiram Chirino
Fix For: 4.1, 4.0.2
Attachments: findunlicensed.pl
robert burrell donkin reported:
{quote}
missing license headers from some of the files i checked at random
gives me concerns. for example:
maven-bundle-plugin/src/main/java/org/apache/activemq/maven/BundleMojo.java
activemq-web-demo worries me: there are a lot of files without license
headers and some which have them were not created at the ASF (which is
ok but gives me concerns about the rest).
i would like to see the issue of licenses in the source tidied up
before this release ships. i haven't gone through every file but IMO
this needs to be done.
{quote}
--
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-888) Licence headers missing from several source files.
[
https://issues.apache.org/activemq/browse/AMQ-888?page=comments#action_36819 ]
Hiram Chirino commented on AMQ-888:
---
Added a few more headers
* in trunk rev 433353
* in 4.0 branch rev 433354
Licence headers missing from several source files.
--
Key: AMQ-888
URL: https://issues.apache.org/activemq/browse/AMQ-888
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 4.0
Reporter: Hiram Chirino
Assigned To: Hiram Chirino
Fix For: 4.1, 4.0.2
Attachments: findunlicensed.pl
robert burrell donkin reported:
{quote}
missing license headers from some of the files i checked at random
gives me concerns. for example:
maven-bundle-plugin/src/main/java/org/apache/activemq/maven/BundleMojo.java
activemq-web-demo worries me: there are a lot of files without license
headers and some which have them were not created at the ASF (which is
ok but gives me concerns about the rest).
i would like to see the issue of licenses in the source tidied up
before this release ships. i haven't gone through every file but IMO
this needs to be done.
{quote}
--
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-492) Design error in MulticastDiscoveryAgent use of FailoverTransportConnector?
[ http://jira.activemq.org/jira//browse/AMQ-492?page=all ] Hiram Chirino resolved AMQ-492: --- Resolution: Fixed Design error in MulticastDiscoveryAgent use of FailoverTransportConnector? -- Key: AMQ-492 URL: http://jira.activemq.org/jira//browse/AMQ-492 Project: ActiveMQ Type: Bug Components: Connector Versions: 4.0 Environment: w2k and linux w java 1.5 Reporter: Dennis Cook Assignee: Hiram Chirino Fix For: 4.0 I have been trying to get my head around the multicast discovery mechanism. In particular its use of the FailoverTransport class is bothering me. The issue presented itself when viewing the DEBUG level log entries that were generated after one broker of a pair, connected using this discovery mechanism, was stopped. The FailoverTransport went into a very tight endless loop of attempts to reconnect. My first thought to tweak the Failover properties in the network connector URI. But alais, the uri was for the multicast not the failover. No problem, just duplicate the failover properties on the multicast agent. After doing so, I started to think why is failover needed at all wont the connection be reestablished when the broker returns and advertises itself again? Can someone comment on this issue? Is the bug that the failover properties where not available or is the problem that failover was used at all? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-533) Unable to create ACTIVEMQ_ACK table
[ http://jira.activemq.org/jira//browse/AMQ-533?page=comments#action_35809 ] Hiram Chirino commented on AMQ-533: --- ActiveMQ has not been enhanced so that the SQL statements used can be tuned. In you case, you would want to used something similar to... broker useJmx=false persistenceAdapter journaledJDBC useJournal=false statements statements stringIdDataType =VARCHAR(128)/ /statements /journaledJDBC /persistenceAdapter /broker For more info on what attributes can be set on the statements element, see: http://activemq.codehaus.org/maven/apidocs/org/apache/activemq/store/jdbc/Statements.html All the settable bean properties can be used as attributes of the statements element. Unable to create ACTIVEMQ_ACK table --- Key: AMQ-533 URL: http://jira.activemq.org/jira//browse/AMQ-533 Project: ActiveMQ Type: Bug Components: Message Store Versions: 3.2.2 Environment: MySQL 4.1.11 (InnoDB engine, UTF-8 default characterset), MySQL 3.1.8 connector/J, Java 1.5.0_06, Windows XP SP2, ActiveMQ 3.2.2 Reporter: N W Priority: Blocker Fix For: 4.0 M5 I received the following error when trying to run ActiveMQ for the first time in the above environment: Specified key was too long; max key length is 1024 bytes... when ActiveMQ tries to create the ACTIVEMQ_ACKS table. It looks like the pk for that table involves two columns which are defined in DefaultStatementProvider.java as being VARCHAR(250)s. In in UTF-8 characterset each char is composed of 3 bytes such that in this case the pk will be 1500 bytes which exceeds the max length for a InnoDB primary key. Is there a spec. which stipulates that containernameDataType and subscriptionIdDataType should be VARCHAR(250)? Could these be changed to say VARCHAR(128) or some such so that the pk on that table will fall within the 1024 byte limit? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-465) deadlock when using VM transport and Jencks...
[ http://jira.activemq.org/jira//browse/AMQ-465?page=all ] Hiram Chirino resolved AMQ-465: --- Resolution: Fixed The asyncDispatch setting configured on the connection was not being honored by the connectionConsumers. Fixed so now the default should be to do async dispatch so the deadlock should not occur with the default configuration anymore. deadlock when using VM transport and Jencks... -- Key: AMQ-465 URL: http://jira.activemq.org/jira//browse/AMQ-465 Project: ActiveMQ Type: Bug Versions: 4.0 M4 Reporter: james strachan Assignee: Hiram Chirino Fix For: 4.1 Background here: http://forums.logicblaze.com/posts/list/146.page It seems to be VM protocol specific -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (AMQ-465) deadlock when using VM transport and Jencks...
[ http://jira.activemq.org/jira//browse/AMQ-465?page=all ] Hiram Chirino reopened AMQ-465: --- forgot to update fix for version. deadlock when using VM transport and Jencks... -- Key: AMQ-465 URL: http://jira.activemq.org/jira//browse/AMQ-465 Project: ActiveMQ Type: Bug Versions: 4.0 M4 Reporter: james strachan Assignee: Hiram Chirino Fix For: 4.0 M5 Background here: http://forums.logicblaze.com/posts/list/146.page It seems to be VM protocol specific -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-465) deadlock when using VM transport and Jencks...
[ http://jira.activemq.org/jira//browse/AMQ-465?page=all ] Hiram Chirino resolved AMQ-465: --- Resolution: Fixed Fix Version: (was: 4.1) 4.0 M5 deadlock when using VM transport and Jencks... -- Key: AMQ-465 URL: http://jira.activemq.org/jira//browse/AMQ-465 Project: ActiveMQ Type: Bug Versions: 4.0 M4 Reporter: james strachan Assignee: Hiram Chirino Fix For: 4.0 M5 Background here: http://forums.logicblaze.com/posts/list/146.page It seems to be VM protocol specific -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-533) Unable to create ACTIVEMQ_ACK table
[ http://jira.activemq.org/jira//browse/AMQ-533?page=all ] Hiram Chirino resolved AMQ-533: --- Resolution: Fixed Fix Version: 4.0 M5 Unable to create ACTIVEMQ_ACK table --- Key: AMQ-533 URL: http://jira.activemq.org/jira//browse/AMQ-533 Project: ActiveMQ Type: Bug Components: Message Store Versions: 3.2.2 Environment: MySQL 4.1.11 (InnoDB engine, UTF-8 default characterset), MySQL 3.1.8 connector/J, Java 1.5.0_06, Windows XP SP2, ActiveMQ 3.2.2 Reporter: N W Priority: Blocker Fix For: 4.0 M5 I received the following error when trying to run ActiveMQ for the first time in the above environment: Specified key was too long; max key length is 1024 bytes... when ActiveMQ tries to create the ACTIVEMQ_ACKS table. It looks like the pk for that table involves two columns which are defined in DefaultStatementProvider.java as being VARCHAR(250)s. In in UTF-8 characterset each char is composed of 3 bytes such that in this case the pk will be 1500 bytes which exceeds the max length for a InnoDB primary key. Is there a spec. which stipulates that containernameDataType and subscriptionIdDataType should be VARCHAR(250)? Could these be changed to say VARCHAR(128) or some such so that the pk on that table will fall within the 1024 byte limit? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-573) add ability to redelivery messages that have been sent to a DLQ to the original queue
[ http://jira.activemq.org/jira//browse/AMQ-573?page=all ] Hiram Chirino resolved AMQ-573: --- Resolution: Fixed Fix Version: (was: 4.1) 4.0 M5 The JMX QueueView now has a copy and delete methods that can be used to do the requested task add ability to redelivery messages that have been sent to a DLQ to the original queue - Key: AMQ-573 URL: http://jira.activemq.org/jira//browse/AMQ-573 Project: ActiveMQ Type: New Feature Reporter: james strachan Assignee: Hiram Chirino Fix For: 4.0 M5 can we know from a message on a DLQ where it should go - if so some method like... redeliverFromDLQ() would do the trick (which would be a no-op for non-DLQs) or failing that a method moveToQueue(String destination name) moveToTopic(String destination name) which works like purge, but moves to a new destination rather than deleting -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-507) java.sql.SQLException: Failed to remove a message during load testing
[ http://jira.activemq.org/jira//browse/AMQ-507?page=all ] Hiram Chirino reassigned AMQ-507: - Assign To: Jonas Lim (was: Hiram Chirino) Have you been able to consistently reproduce this? java.sql.SQLException: Failed to remove a message during load testing -- Key: AMQ-507 URL: http://jira.activemq.org/jira//browse/AMQ-507 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 M4 Reporter: Jonas Lim Assignee: Jonas Lim Priority: Blocker Fix For: 4.0 RC1 please refer to http://forums.activemq.org/posts/list/111.page -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-643) maxInactivityDuration does not seem to work properly
[ http://jira.activemq.org/jira//browse/AMQ-643?page=comments#action_35845 ] Hiram Chirino commented on AMQ-643: --- Hi Kevin, The maxInactivityDuration setting has to match on both sides of the connection. If they do then there is no need to make KeepAlives request a reply since the other side will send a KeepAlive if his side of the connection remains idle for too long. Could you attache the broker configuration scripts you using? Thanks! maxInactivityDuration does not seem to work properly Key: AMQ-643 URL: http://jira.activemq.org/jira//browse/AMQ-643 Project: ActiveMQ Type: Bug Components: Connector Versions: 4.0 RC1 Environment: AMQ 4 03/17/2006 SNAPSHOT Solaris 8, 10 Reporter: Kevin Yaussy Assignee: Hiram Chirino Fix For: 4.0 RC1 AMQ 4 03/17/2006 SNAPSHOT Using maxInactivityDuration causes a connection to automatically break after the inactivity duration, even though nothing is wrong with either side of the connection. Tracing it through, it looks like the KeepAliveInfo command does not require a response. This means that the KeepAlive sent never results in receive activity. So, if both processes are perfectly fine, just not sending any data, the connection breaks due to InactivityMonitor.readCheck. I've changed KeepAliveInfo.java to return true for isResponseRequired. This seems to fix the problem, from a client perspective, anyway. However, if this is used for broker-to-broker connections, and you force a problem with one of the brokers (like doing pstop on Solaris), major problems will happen: 1) The broker that is left alone seems to break the connection. But, it continues to attempt to send messages to the failed broker. It was mentioned in the forum at one point you were going to have the broker unregister subscriptions so it would not attempt to send messages to the failed broker. Doesn't seem like this is in place. 2) If you reawaken the pstopped broker, the two brokers never really recover properly. Connections continue to get broken, over and over again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-643) maxInactivityDuration does not seem to work properly
[ http://jira.activemq.org/jira//browse/AMQ-643?page=comments#action_35852 ] Hiram Chirino commented on AMQ-643: --- Hi Kevin, Yeah, I agree, making sure everybody is using the same setting is a bit of a problem. I working on a change right now that will allow the setting to be negociated by the 2 sides of the connection when it's initialy established. If the server setting is x and the client setting is y, then the inactivity duration for the established connection will be calculated at min(x,y). This way the client and server do not have to have their configs match up exactly. I'll update the issue once the change is commited. Regards, Hiram maxInactivityDuration does not seem to work properly Key: AMQ-643 URL: http://jira.activemq.org/jira//browse/AMQ-643 Project: ActiveMQ Type: Bug Components: Connector Versions: 4.0 RC1 Environment: AMQ 4 03/17/2006 SNAPSHOT Solaris 8, 10 Reporter: Kevin Yaussy Assignee: Hiram Chirino Fix For: 4.0 RC1 Attachments: amq1.xml, amq2.xml AMQ 4 03/17/2006 SNAPSHOT Using maxInactivityDuration causes a connection to automatically break after the inactivity duration, even though nothing is wrong with either side of the connection. Tracing it through, it looks like the KeepAliveInfo command does not require a response. This means that the KeepAlive sent never results in receive activity. So, if both processes are perfectly fine, just not sending any data, the connection breaks due to InactivityMonitor.readCheck. I've changed KeepAliveInfo.java to return true for isResponseRequired. This seems to fix the problem, from a client perspective, anyway. However, if this is used for broker-to-broker connections, and you force a problem with one of the brokers (like doing pstop on Solaris), major problems will happen: 1) The broker that is left alone seems to break the connection. But, it continues to attempt to send messages to the failed broker. It was mentioned in the forum at one point you were going to have the broker unregister subscriptions so it would not attempt to send messages to the failed broker. Doesn't seem like this is in place. 2) If you reawaken the pstopped broker, the two brokers never really recover properly. Connections continue to get broken, over and over again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-531) XBean has a runtime issue with Spring 2.0M2
[ http://jira.activemq.org/jira//browse/AMQ-531?page=all ] Hiram Chirino reassigned AMQ-531: - Assign To: james strachan Looks like we can close this one out. XBean has a runtime issue with Spring 2.0M2 --- Key: AMQ-531 URL: http://jira.activemq.org/jira//browse/AMQ-531 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 M4 Environment: Spring 2.0M2 Reporter: Ben Hale Assignee: james strachan Fix For: 4.0 RC1 Apparently there is an issue with XBean now that Spring 2.0 (starting with M2) is compiled against a Java 5 compiler (http://jira.codehaus.org/browse/XB-7). It's probably worth investigating how long before XBean releases a fix and postponing the 4.0 release until they do. If not, at least documenting in a known issues list that ActiveMQ 4.0 can't working with 2.0M2 and later until a later release where they do fix it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
