[jira] Resolved: (AMQ-735) Possible 4.0 consumer client memory leak?
[ https://issues.apache.org/activemq/browse/AMQ-735?page=all ] james strachan resolved AMQ-735: Resolution: Cannot Reproduce Assign To: james strachan I'm not yet convinced there is any memory leak. If you can find some leak we can always reopen this issue. As I said on the mail list, to reduce RAM overhead try use optimizeAcknowledge=false and reduce the prefetch value. Possible 4.0 consumer client memory leak? - Key: AMQ-735 URL: https://issues.apache.org/activemq/browse/AMQ-735 Project: ActiveMQ Type: Bug Components: JMS client Versions: 4.0 Environment: windows xp pro, jdk 1.5, AMQ 4.0 (incubator) Reporter: Karthik Sethuraman Assignee: james strachan Priority: Critical Fix For: 4.0.1 Attachments: activemq_735.zip, instance.zip, jmsmon.zip On running the attached test programs (one producer on a topic, one consumer on a topic), the consumer eventually encounters OutOfMemoryError after receiving around 64 MB of messages). Default JVM heap size is used (64 MB). The problem does not happen with RC2 build. The test programs allows specification of message payloads of different sizes and different message rates, as well number of producer/consumer threads/instances., topics and topic connection factories, via user environment variables. http://www.nabble.com/4.0+Consumer+OutOfMemoryError+bug--t1707655.html#a4660556 -- 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-735) Possible 4.0 consumer client memory leak?
[ https://issues.apache.org/activemq/browse/AMQ-735?page=all ] james strachan reopened AMQ-735: Possible 4.0 consumer client memory leak? - Key: AMQ-735 URL: https://issues.apache.org/activemq/browse/AMQ-735 Project: ActiveMQ Type: Bug Components: JMS client Versions: 4.0 Environment: windows xp pro, jdk 1.5, AMQ 4.0 (incubator) Reporter: Karthik Sethuraman Assignee: james strachan Priority: Critical Fix For: 4.0.1 Attachments: activemq_735.zip, instance.zip, jmsmon.zip On running the attached test programs (one producer on a topic, one consumer on a topic), the consumer eventually encounters OutOfMemoryError after receiving around 64 MB of messages). Default JVM heap size is used (64 MB). The problem does not happen with RC2 build. The test programs allows specification of message payloads of different sizes and different message rates, as well number of producer/consumer threads/instances., topics and topic connection factories, via user environment variables. http://www.nabble.com/4.0+Consumer+OutOfMemoryError+bug--t1707655.html#a4660556 -- 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
heads up on working with trunk and branches
I've just updated the wiki page on the source repository to explain how to use the trunk and activemq-4.0 branch and how to backport bug fixes to 4.0.1 from 4.1-SNAPSHOT etc. http://activemq.org/site/source.html -- James --- http://radio.weblogs.com/0112098/
RE: STOMP and connect/connected handshake
There is already a correlation-id header defined in the AMQ extensions: http://www.activemq.org/site/stomp.html - I was trying to reuse this header for the connect handshake. I don't feel that strongly one way or the other. The name response-id is fine - we'd just have to add another header to our list of extensions (we'd have to do that for the command-id header anyway). Nate -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Monday, June 12, 2006 10:05 AM To: activemq-dev@geronimo.apache.org; [EMAIL PROTECTED] Subject: Re: STOMP and connect/connected handshake Cross posting to the stomp mailing list too since someone there might have some input on this. I like the idea about supporting a command-id header. I might prefer the correlation header to be called response-id instead of correlation-id. -- Forwarded message -- From: Nathan Mittler [EMAIL PROTECTED] Date: Jun 12, 2006 6:13 AM Subject: STOMP and connect/connected handshake To: activemq-dev@geronimo.apache.org For the new activemq-cpp library, we need to extend the STOMP connect/connected handshake so that we get back a correlation-id for our response correlator. To do this, we need to send something in the connect request that contains a client-defined command-id. My first thought was to just reuse the message-id header, but that is typically reserved for cases when a client is expecting to acknowledge a message. So rather than risk breaking that paradigm, I created a new header command-id that is just used on the connect message. When the broker receives a connect request with a command-id header, it creates a connected response with a correlation-id set to the command-id of the original request. This way the client can treat the handshake as a true request/response. Does anyone see any problems with adding this to the broker? Regards, Nate -- Regards, Hiram
RE: [stomp-dev] RE: STOMP and connect/connected handshake
Agreed. So let's go with a new set of headers. I propose the following: request-id (goes in any STOMP client-broker request command ... currently only CONNECT) response-id (goes in any STOMP client-broker response command ... currently only CONNECTED) I've changed command-id to request-id so that it's clearer that the two headers are related. How does this sound? Nate -Original Message- From: James Strachan [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 10:28 AM To: [EMAIL PROTECTED] Subject: Re: [stomp-dev] RE: STOMP and connect/connected handshake FWIW the correlation-id currently maps to JMSCorrelationID - but is only used on JMS messages rather than on commands like CONNECT etc. Though the JMSCorrelationID is often an out of band correlation; rather than correlating a request stomp command to a stomp response; so maybe another header name would avoid confusion? On 6/12/06, Mittler, Nathan [EMAIL PROTECTED] wrote: There is already a correlation-id header defined in the AMQ extensions: http://www.activemq.org/site/stomp.html - I was trying to reuse this header for the connect handshake. I don't feel that strongly one way or the other. The name response-id is fine - we'd just have to add another header to our list of extensions (we'd have to do that for the command-id header anyway). Nate -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Monday, June 12, 2006 10:05 AM To: activemq-dev@geronimo.apache.org; [EMAIL PROTECTED] Subject: Re: STOMP and connect/connected handshake Cross posting to the stomp mailing list too since someone there might have some input on this. I like the idea about supporting a command-id header. I might prefer the correlation header to be called response-id instead of correlation-id. -- Forwarded message -- From: Nathan Mittler [EMAIL PROTECTED] Date: Jun 12, 2006 6:13 AM Subject: STOMP and connect/connected handshake To: activemq-dev@geronimo.apache.org For the new activemq-cpp library, we need to extend the STOMP connect/connected handshake so that we get back a correlation-id for our response correlator. To do this, we need to send something in the connect request that contains a client-defined command-id. My first thought was to just reuse the message-id header, but that is typically reserved for cases when a client is expecting to acknowledge a message. So rather than risk breaking that paradigm, I created a new header command-id that is just used on the connect message. When the broker receives a connect request with a command-id header, it creates a connected response with a correlation-id set to the command-id of the original request. This way the client can treat the handshake as a true request/response. Does anyone see any problems with adding this to the broker? Regards, Nate -- Regards, Hiram - To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email -- James --- http://radio.weblogs.com/0112098/ - To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
[jira] Reopened: (AMQ-732) Infinite recovery loop.
[ https://issues.apache.org/activemq/browse/AMQ-732?page=all ]
Maxim Fateev reopened AMQ-732:
--
Thanks for quick fix.
Could you provide more info on the root cause? It would be nice to include such
information as well as check in number every time you close an issue.
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.1
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]
Incoming File from SendThisFile(sm)
SendThisFile ® - by Layer-Z, Inc. From: [EMAIL PROTECTED] Subject: Incoming File from SendThisFile(sm) Expires: The file will be removed in 3 days Hi, I added failover support to the existing openwire c++ client, and fixed some memory leaks along the way, but there is still one memory leak about tcp transport. I didn't add a unit test, I just modified existing ones and did my testings, and it may not build on unix. Also I think currently openwire c++ client has some threading issues, e.g. the maps or lists in the connection, session etc. objects are simple STL types. I am going to look at it later on. Any comments or suggestions, please let me know. Thanks. Erin Click the following link(s) to retrieve your file(s): openwire-cpp.zip http://www2.sendthisfile.com/d.jsp?t=HkQP5Y8imR1P2wrZ7kjwJEXB If the link isn't clickable, copy and paste the link into a browser to download your file. Free Accounts at SendThisFile Easily register for a free account and send files to anyone in minutes. http://www.SendThisFile.com Notice: By downloading this file you are agreeing to the Terms of Service which can be viewed from the www.sendthisfile.com home page. Copyright 2003-2006 - Layer-Z, Inc.
[jira] Created: (AMQ-748) Add request-id and response-id headers to STOMP connect/connected handshake
Add request-id and response-id headers to STOMP connect/connected handshake --- Key: AMQ-748 URL: https://issues.apache.org/activemq/browse/AMQ-748 Project: ActiveMQ Type: New Feature Components: Transport Reporter: Nathan Mittler Assigned to: Nathan Mittler Priority: Minor For the new activemq-cpp library, we need to extend the STOMP connect/connected handshake so that we get back a response-id for our response correlator. To do this, we need to send something in the connect request that contains a client-defined request-id. My first thought was to just reuse the message-id header, but that is typically reserved for cases when a client is expecting to acknowledge a message. So rather than risk breaking that paradigm, I propose a new header request-id that is just used on the connect message. When the broker receives a connect request with a request-id header, it creates a connected response with a response-id set to the request-id of the original request. This way the client can treat the handshake as a true request/response. -- 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-733) Minor renaming of kaha module
[ https://issues.apache.org/activemq/browse/AMQ-733?page=all ] Hiram Chirino updated AMQ-733: -- Fix Version: 4.1 Version: 4.0 (was: 4.0.1) just make the changes to trunk. don't worry about 4.0.1 Minor renaming of kaha module - Key: AMQ-733 URL: https://issues.apache.org/activemq/browse/AMQ-733 Project: ActiveMQ Type: Wish Components: Message Store Versions: 4.0 Reporter: Adrian Co Assignee: Adrian Co Priority: Trivial Fix For: 4.1 I was wondering if we can rename KahaPersistentAdaptor to KahaPersistenceAdapter just to be consistent with the rest of the persistence adapters. Also, should the package kahadaptor be kahaadapter or just plain kaha? :) Assign the jira to me if you're ok with the changes, I don't mind doing the renaming. Thanks! :) -- 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-751) Extend ExceptionListener mechanism by creating a custom AMQ exception which would provide more detail about the exception
[ https://issues.apache.org/activemq/browse/AMQ-751?page=all ] Hiram Chirino updated AMQ-751: -- Fix Version: 4.1 Priority: Minor (was: Major) Sounds like a good idea. Lets try to get it in for 4.1 Extend ExceptionListener mechanism by creating a custom AMQ exception which would provide more detail about the exception - Key: AMQ-751 URL: https://issues.apache.org/activemq/browse/AMQ-751 Project: ActiveMQ Type: Improvement Components: JMS client, Broker Reporter: Massive Boisson Priority: Minor Fix For: 4.1 To quote James: I wonder if we could add a neater non-JMS extension to ActiveMQ to make it easier to be notified asynchronously of which Message objects could not be sent? I guess we could just use the ExceptionListener and use a custom type of Exception which contained the Message object? I think this would greatly increase the usefulness of async sends. -- 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-720) Use the Apache Commons CLI to parse the command line
[ https://issues.apache.org/activemq/browse/AMQ-720?page=all ] Hiram Chirino updated AMQ-720: -- Fix Version: 4.1 Use the Apache Commons CLI to parse the command line Key: AMQ-720 URL: https://issues.apache.org/activemq/browse/AMQ-720 Project: ActiveMQ Type: Improvement Versions: 4.1 Reporter: Adrian Co Assignee: Adrian Co Fix For: 4.1 Change the current way of parsing command line to use the apache commons cli for a more standard format. -- 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-719) OpenWire ActiveMQTextMessage not sharable between JMS client and dotNet client
[ https://issues.apache.org/activemq/browse/AMQ-719?page=all ] Hiram Chirino updated AMQ-719: -- Fix Version: 4.0.1 4.1 Setting fix version so that issue shows up on roadmap 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.1 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] Resolved: (AMQ-684) Fatal bug: JMS Send message will be blocked,when two or more recive client reciving one queue destation.
[ https://issues.apache.org/activemq/browse/AMQ-684?page=all ] Hiram Chirino resolved AMQ-684: --- Fix Version: 4.0 Resolution: Fixed I think this was resolved against 4.0, please retest against that version. If the problem still exists, please reopen. Attaching a test case to the issue usually help the developers find the problem quicker. Fatal bug: JMS Send message will be blocked,when two or more recive client reciving one queue destation. Key: AMQ-684 URL: https://issues.apache.org/activemq/browse/AMQ-684 Project: ActiveMQ Type: Bug Versions: 4.0 RC2 Environment: Suse Linux 9.0 and winxp Java 5.0 Reporter: tao Fix For: 4.0 RC1 not have this bug. -- 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-702) `bstat --help` should display something useful
[ https://issues.apache.org/activemq/browse/AMQ-702?page=all ]
Hiram Chirino updated AMQ-702:
--
Fix Version: 4.0.1
4.1
Adrian,
Do you known when you will get around to fixing this?
`bstat --help` should display something useful
--
Key: AMQ-702
URL: https://issues.apache.org/activemq/browse/AMQ-702
Project: ActiveMQ
Type: Improvement
Versions: 4.0 RC3
Reporter: Jason Dillon
Assignee: Adrian Co
Fix For: 4.1, 4.0.1
`bstat --help` should display something useful. Right now using a
non-standard connectorPort for the managementContext I get this:
{noformat}
[EMAIL PROTECTED]:...bator-activemq-4.0-RC3/bin./bstat --help
ACTIVEMQ_HOME:
/Users/jason/ws/paybytouch/ea/activemq/node1/incubator-activemq-4.0-RC3
ERROR: java.lang.RuntimeException: Failed to execute query task. Reason:
java.io.IOException: Failed to retrieve RMIServer stub:
javax.naming.ServiceUnavailableException [Root exception is
java.rmi.ConnectException: Connection refused to host: localhost; nested
exception is:
java.net.ConnectException: Connection refused]
ERROR: java.lang.Exception: java.io.IOException: Failed to retrieve RMIServer
stub: javax.naming.ServiceUnavailableException [Root exception is
java.rmi.ConnectException: Connection refused to host: localhost; nested
exception is:
java.net.ConnectException: Connection refused]
{noformat}
`bstat localhost --help` works, showing that this is really calling `query`.
Anyways, not very helpful when the JMX URL is changed from the default.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-750) multi-threaded issues with failover transport
[ https://issues.apache.org/activemq/browse/AMQ-750?page=all ]
Hiram Chirino updated AMQ-750:
--
Fix Version: (was: incubation)
Ning,
Could you supply a junit test case that shows the failaure? Mutithreading
issues are complex and hard to describe, a test case would make it very clear.
multi-threaded issues with failover transport
-
Key: AMQ-750
URL: https://issues.apache.org/activemq/browse/AMQ-750
Project: ActiveMQ
Type: Bug
Components: Transport
Versions: 4.0
Environment: Got the June 6 code using svn, and test is run on Windows
Reporter: Ning Li
Priority: Minor
Modified ProducerTool.java into multi-threaded test code:
This is the peudo code:
For ( thread 1 to 30 )
{
Connection connection = createConnection();
Session session = createSession(connection);
Producer producer = createProducer(session);
sendMessages(producer, 10); //each thread send 10 messages to broker,
using url = failover:tcp://localhost:61616
}
Please turn on Debug info for log4j, otherwise you will hit other threading
issue before this one, when client shutting down, this exception will be
thrown:
Thread-13 Sending total message: 10 Total time: 203 DONE !!!
[ Thread-13] FailoverTransport DEBUG Stopped.
[cp://localhost/127.0.0.1:61616] FailoverTransport DEBUG
Transport failed, starting up reconnect task
java.net.SocketException: socket closed
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at
org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:48)
at
org.apache.activemq.transport.tcp.TcpBufferedInputStream.read(TcpBufferedInputStream.java:55)
at java.io.DataInputStream.readInt(DataInputStream.java:353)
at
org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:274)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:142)
at java.lang.Thread.run(Thread.java:595)
[ActiveMQ Scheduler] InactivityMonitor DEBUG Message
sent since last write check, resetting flag
[cp://localhost/127.0.0.1:61616] FailoverTransport DEBUG
Transport failed, starting up reconnect task
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:168)
at
org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:48)
at
org.apache.activemq.transport.tcp.TcpBufferedInputStream.read(TcpBufferedInputStream.java:55)
at java.io.DataInputStream.readInt(DataInputStream.java:353)
at
org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:274)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:142)
at java.lang.Thread.run(Thread.java:595)
[ ActiveMQ Task] FailoverTransport DEBUG
Attempting connect to: tcp://localhost:61616
Thread-17 Sending total message: 10 Total time: 109 DONE !!!
[ Thread-17] FailoverTransport DEBUG Stopped.
[cp://localhost/127.0.0.1:61616] FailoverTransport DEBUG
Transport failed, starting up reconnect task
java.net.SocketException: socket closed
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at
org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:48)
at
org.apache.activemq.transport.tcp.TcpBufferedInputStream.read(TcpBufferedInputStream.java:55)
at java.io.DataInputStream.readInt(DataInputStream.java:353)
at
org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:274)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:142)
at java.lang.Thread.run(Thread.java:595)
Thread-14 Sending total message: 10 Total time: 328 DONE !!!
[cp://localhost/127.0.0.1:61616] FailoverTransport DEBUG
Transport failed, starting up reconnect task
java.net.SocketException: socket closed
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at
org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:48)
at
org.apache.activemq.transport.tcp.TcpBufferedInputStream.read(TcpBufferedInputStream.java:55)
at java.io.DataInputStream.readInt(DataInputStream.java:353)
at
org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:274)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:142)
at java.lang.Thread.run(Thread.java:595)
--
[jira] Updated: (AMQ-122) add support for priority message ordering
[ https://issues.apache.org/activemq/browse/AMQ-122?page=all ] Hiram Chirino updated AMQ-122: -- Fix Version: 3.2.4 (was: 3.1) add support for priority message ordering - Key: AMQ-122 URL: https://issues.apache.org/activemq/browse/AMQ-122 Project: ActiveMQ Type: New Feature Components: JMS client Versions: 4.0 Environment: Solaris 8, Linux, Windows , Java 1.4.2 Reporter: Etienne Araya Assignee: Ramzi Saba Fix For: 3.2.4 Original Estimate: 8 hours Remaining: 8 hours messages with higher priority is not consumed first ActiveMQ doesn't yet support priorities. messages with greater priority are not consumed first but that are consumed in the arrival order. -- 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-275) Could not enqueue message and Too many open files
[ https://issues.apache.org/activemq/browse/AMQ-275?page=all ]
Hiram Chirino updated AMQ-275:
--
Fix Version: 3.2.4
(was: 3.1)
Could not enqueue message and Too many open files
-
Key: AMQ-275
URL: https://issues.apache.org/activemq/browse/AMQ-275
Project: ActiveMQ
Type: Bug
Components: Broker
Versions: 3.0
Environment: Windows 2000/XP SP2
Reporter: Glen Klyuzner
Fix For: 3.2.4
Attachments: patchfile.txt
Relaited to slow consumer condition.
WARN 2005-06-22 12:55:44,135 - Queue is full, waiting for it to be dequeued.
2005-06-22 11:51:09,678 [ocalport=61616]] WARN BrokerClientImpl
- Connection: ID:ny-cap-33-2024-1119453996333-6:0 is a slow consumer
2005-06-22 11:51:09,678 [ocalport=61616]] WARN BrokerClientImpl
- Connection: ID:ny-cap-33-2024-1119453996333-6:0 is a slow consumer
2005-06-22 11:51:09,694 [ocalport=61616]] INFO DataContainer
- making directory for temporary spooled data: ActiveMQTemp
2005-06-22 11:51:11,069 [ocalport=61616]] WARN BrokerClientImpl
- Connection: ID:ny-cap-33-2005-1119453893347-6:0 is a slow consumer
2005-06-22 11:51:11,069 [ocalport=61616]] WARN BrokerClientImpl
- Connection: ID:ny-cap-33-2005-1119453893347-6:0 is a slow consumer
2005-06-22 11:51:17,288 [ocalport=61616]] DEBUG
ientTopicBoundedMessageManager - Adding consumer: CONSUMER_INFO: id = 336
ConsumerInfo{ browser = false, destination =
ActiveMQ.Advisory.TempDestinations.temp-queue.TemporaryQueue-{TD{ID:ny-cap-33-2150-1119455437835-16:0}TD}ID:ny-cap-33-2150-1119455437835-23:0,
consumerIdentifier = 'ID:ny-cap-33-2024-1119453996333-16:0.27.53' , clientId
= 'ID:ny-cap-33-2024-1119453996333-16:0' , sessionId = '27' , consumerName =
'' , selector = '' , startTime = 1119455477008, started = true, consumerNo =
53, noLocal = false, prefetchNumber = 1000, consumerKey =
'[ID:ny-cap-33-2024-1119453996333-16:0:]' }
2005-06-22 11:51:54,773 [ocalport=61616]] ERROR BrokerClientImpl
- Could not enqueue message ACTIVEMQ_OBJECT_MESSAGE: id = 0 ActiveMQMessage{
, jmsMessageID = ID:ny-cap-33-2005-1119453893347-68:121589, bodyAsBytes =
[EMAIL PROTECTED], readOnlyMessage = false, jmsClientID =
'ID:ny-cap-33-2005-1119453893347-6:0' , jmsCorrelationID = 'null' ,
jmsDestination = Topic.sds.PropertyTemplatePublisher, jmsReplyTo = null,
jmsDeliveryMode = 2, jmsRedelivered = false, jmsType = 'null' , jmsExpiration
= 1119455573508, jmsPriority = 4, jmsTimestamp = 1119455513508, properties =
null, readOnlyProperties = false, entryBrokerName =
'ID:nyotc023-2882-1119382254093-0:0' , entryClusterName = 'default' ,
consumerNos = [EMAIL PROTECTED], transactionId = 'null' , xaTransacted =
false, consumerIdentifer = 'null' , messageConsumed = false,
transientConsumed = false, sequenceNumber = 121589, deliveryCount = 1,
dispatchedFromDLQ = false, messageAcknowledge = null, jmsMessageIdentity =
null, producerKey = ID:ny-cap-33-2005-1119453893347-68: }
ActiveMQObjectMessage{ object = null } to SpooledBoundedQueue for this slow
consumer
javax.jms.JMSException: enqueNoBlock failed: Too many open files
at
org.activemq.io.util.SpooledBoundedActiveMQMessageQueue.enqueueNoBlock(SpooledBoundedActiveMQMessageQueue.java:121)
at
org.activemq.io.util.SpooledBoundedActiveMQMessageQueue.enqueue(SpooledBoundedActiveMQMessageQueue.java:91)
at
org.activemq.broker.impl.BrokerClientImpl.dispatch(BrokerClientImpl.java:198)
at
org.activemq.service.boundedvm.TransientTopicBoundedMessageContainer.dispatchToQueue(TransientTopicBoundedMessageContainer.java:223)
at
org.activemq.service.boundedvm.TransientTopicBoundedMessageContainer.targetAndDispatch(TransientTopicBoundedMessageContainer.java:155)
at
org.activemq.service.boundedvm.TransientTopicBoundedMessageManager.doSendMessage(TransientTopicBoundedMessageManager.java:225)
at
org.activemq.service.boundedvm.TransientTopicBoundedMessageManager.sendMessage(TransientTopicBoundedMessageManager.java:204)
at
org.activemq.broker.impl.DefaultBroker.doMessageSend(DefaultBroker.java:563)
at
org.activemq.broker.impl.DefaultBroker.sendMessage(DefaultBroker.java:305)
at
org.activemq.broker.impl.BrokerContainerImpl.sendMessage(BrokerContainerImpl.java:462)
at
org.activemq.broker.impl.BrokerConnectorImpl.sendMessage(BrokerConnectorImpl.java:271)
at
org.activemq.broker.impl.BrokerClientImpl.consumeActiveMQMessage(BrokerClientImpl.java:706)
at
org.activemq.broker.impl.BrokerClientImpl.consume(BrokerClientImpl.java:310)
at
org.activemq.transport.TransportChannelSupport.doConsumePacket(TransportChannelSupport.java:374)
at
[jira] Updated: (AMQ-367) Axis/JMS/ActiveMQ demo
[ https://issues.apache.org/activemq/browse/AMQ-367?page=all ] Hiram Chirino updated AMQ-367: -- Fix Version: 3.2.4 (was: 3.1) Axis/JMS/ActiveMQ demo -- Key: AMQ-367 URL: https://issues.apache.org/activemq/browse/AMQ-367 Project: ActiveMQ Type: New Feature Versions: 3.1 Reporter: Chris Berry Fix For: 3.2.4 Attachments: axis-jms-demo.zip I have created a self-contained demo of using Axis/JMS/ActiveMQ James suggested that I pass it along for possible inclusion in the examples All of the code is in the enclosed ZIP Cheers, -- Chris -- 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
Re: STOMP transport unit testing
Hi Nate, The more tests the merrier :) On 6/12/06, Mittler, Nathan [EMAIL PROTECTED] wrote: I'm going to be testing out a few tweaks to the STOMP transport. Some of the changes are only noticeable when you have a stomp client talking to a JMS client. Do we have a unit test class for cross-transport communication? If not, is there any objection to sticking this into the StompTest suite? Thanks, Nate -- Regards, Hiram
[jira] Commented: (AMQ-739) STOMP transport handles JMS type improperly
[ https://issues.apache.org/activemq/browse/AMQ-739?page=comments#action_36315 ] Nathan Mittler commented on AMQ-739: It isn't possible to reuse the type header (JMSType) for the purpose of sending through the information as to what type of message it is (text or bytes). So this means that we need to add another activemq extension header. I propose amq-msg-type. STOMP transport handles JMS type improperly --- Key: AMQ-739 URL: https://issues.apache.org/activemq/browse/AMQ-739 Project: ActiveMQ Type: Bug Components: Transport Environment: sending from STOMP to JMS Reporter: Nathan Mittler Assignee: Nathan Mittler Priority: Minor Fix For: 4.1 Original Estimate: 1 week Remaining: 1 week Sending a text message from a stomp client with a content-length results in a bytes message on JMS. Suggest doing the following ... 1) The stomp transport should always add the content-length header to out-going messages, regardless of content-type or whether or not a content-length was provided on the incoming message. 2) The stomp transport should handle in-coming messages with a content-type header, and should pass that through. 3) If a message comes in without a content-length or a content-type, it should just be assumed a TextMessage. This way we can use the terminating null character as the delimiter. -- 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
