[jira] [Commented] (AMQ-4917) LevelDB store can fail when using durable subs
[ https://issues.apache.org/jira/browse/AMQ-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839951#comment-13839951 ] Tenzin giatso commented on AMQ-4917: Hi, thank you for your help. i'll try the snapshot right now. I'll keep you in touch. LevelDB store can fail when using durable subs -- Key: AMQ-4917 URL: https://issues.apache.org/jira/browse/AMQ-4917 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.9.0 Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 5.10.0 Tenzin giatso original reported this issue in AMQ-4837 : The broker stopped 3 times this night after about 6h50min, then 6h50 min then 50min. The error sounds to be the saùme (except the line number in class) but the broker restart automaticly with the snapshot. 2013-11-19 05:27:43,671 | INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException | org.apache.activemq.util.DefaultIOExceptionHandler | LevelDB IOException handler. java.io.IOException at org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39) at org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:554) at org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:1021) at org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1320) at org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1244) at org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708) at org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recover(LevelDBStore.scala:747) at org.apache.activemq.broker.region.Topic.doBrowse(Topic.java:588) at org.apache.activemq.broker.region.Topic.access$100(Topic.java:65) at org.apache.activemq.broker.region.Topic$6.run(Topic.java:721) at org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:33) at java.util.TimerThread.mainLoop(Unknown Source) at java.util.TimerThread.run(Unknown Source) Caused by: java.lang.NullPointerException at org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1248) It's not easy to reproduce. It's better with the snapshot but i can't say that no messages are lost with leveldb. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (AMQ-4887) ActiveMQBytesMessage will lost content if message's property was set before copy
[
https://issues.apache.org/jira/browse/AMQ-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Earls updated AMQ-4887:
-
Attachment: AMQ-4887.patch
This is a slightly modified version of the original patch. Tim, can you review
this?
I have also added a test, AMQ4887Test.java to activemq-unit-tests
ActiveMQBytesMessage will lost content if message's property was set before
copy
-
Key: AMQ-4887
URL: https://issues.apache.org/jira/browse/AMQ-4887
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.9.0
Reporter: caoyunfei
Assignee: Kevin Earls
Attachments: AMQ-4887.patch, ActiveMQBytesMessage.java.patch,
ActiveMQBytesMessageTest.java, Consumer.java, Producer.java
Original Estimate: 24h
Remaining Estimate: 24h
ActiveMQBytesMessage will lost content if message's property was set before
copy. Here is the test code:
Producer:
MessageProducer producer;
//initialize Connection, Session, MessageProducer
byte[] bs = bytes message.getBytes();
BytesMessage message = session.createBytesMessage();
message.writeBytes(bs); //write bytes to message 1
for(int i=0; i 0; i++){
// then set message's propery 2
message.setLongProperty(sendTime, System.currentTimeMillis());
try{
producer.send(message);
}catch(){
e.printStackTrace();
}
}
Consumer:
MessageConsumer consumer
//initailize Connection, Session, MessageConsumer
for(int i=0; i10; i++){
ActiveMQBytesMessage msg =
(ActiveMQBytesMessage)consumer.receive(60*1000);
long sendTime = message.getLongProperty(sendTime);
System.out.println(sendtime: + sendTime);
ByteSequence bs = message.getMessage().getContent();
System.out.println(bytes data: + new String(bs.getData()));
}
Expected result:
consumer gets bytes data in all received messages
Actual result:
only the fisrt message has bytes data, all other messages lost bytes data,
while long property value is not lost;
Analysization:
message gets copied when send, it will call storeContent() before copy,
DataOutputStream dataOut will be closed and the data in dataOut will be set
to conent. This works correctly if there are no property was set.
when setLongProperty was called, it will call setObjectProperty() then will
call initializeWriting(), here DataOutputStream dataOut will be create
AGAIN.
So when message was copied in second time, DataOutputStream dataOut is NOT
null, but EMPTY, it will clear the value in content.
suggestion:
restore the content data to DataOutputStream dataOut when nitializeWriting()
my fix:
ActiveMQBytesMessage :
private void initializeWriting() throws JMSException {
669The original code
..
701
//fix code
if(this.content !=null this.content.length 0){
try{
this.dataOut.write(this.content.getData());
}catch(IOException ioe){
throw JMSExceptionSupport.create(ioe);
}
}
702}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (AMQ-4920) AmqpErrorException occurs with multiple concurrent amqp topic consumers
Kevin Earls created AMQ-4920:
Summary: AmqpErrorException occurs with multiple concurrent amqp
topic consumers
Key: AMQ-4920
URL: https://issues.apache.org/jira/browse/AMQ-4920
Project: ActiveMQ
Issue Type: Bug
Reporter: Kevin Earls
Assignee: Kevin Earls
I'll add a test to reproduce this. There are currently 2 problems. The more
frequent one looks like: org.apache.qpid.amqp_1_0.type.AmqpErrorException
at
org.apache.qpid.amqp_1_0.codec.ValueHandler.readConstructor(ValueHandler.java:99)
at
org.apache.qpid.amqp_1_0.codec.ValueHandler.parse(ValueHandler.java:90)
at
org.apache.qpid.amqp_1_0.codec.ValueHandler.readConstructor(ValueHandler.java:105)
at
org.apache.qpid.amqp_1_0.codec.ValueHandler.parse(ValueHandler.java:90)
… repeated many times
at
org.apache.qpid.amqp_1_0.codec.ValueHandler.readConstructor(ValueHandler.java:105)
at
org.apache.qpid.amqp_1_0.codec.ValueHandler.parse(ValueHandler.java:90)
at
org.apache.qpid.amqp_1_0.messaging.SectionDecoderImpl.parseAll(SectionDecoderImpl.java:49)
at org.apache.qpid.amqp_1_0.client.Receiver.receive(Receiver.java:280)
at
org.apache.qpid.amqp_1_0.jms.impl.MessageConsumerImpl.receive0(MessageConsumerImpl.java:286)
at
org.apache.qpid.amqp_1_0.jms.impl.MessageConsumerImpl.receiveImpl(MessageConsumerImpl.java:255)
at
org.apache.qpid.amqp_1_0.jms.impl.MessageConsumerImpl.receive(MessageConsumerImpl.java:238)
at
org.apache.qpid.amqp_1_0.jms.impl.MessageConsumerImpl.receive(MessageConsumerImpl.java:56)
at
org.apache.activemq.transport.amqp.ENTMQ466ConsumerThread.run(ENTMQ466Test.java:123)
This occurs at the line final EncodedMessage amqp =
outboundTransformer.transform(jms); in the ConsumerContext.pumpOutbound()
method of AmqpProtocolConverter(). This call sometimes returns with its content
(amqp.getArray()) set to all zeros.
On those messages this line
LOG.info(In pumpOutbound, setting currentBuffer to offset {} length {} content
[{}], amqp.getArrayOffset(), amqp.getLength(), amqp.getArray());
returns:
2013-11-26 17:19:16,680 [calhost] Task-3] - INFO AmqpProtocolConverter - In
pumpOutbound, setting currentBuffer to offset 0 length 162 content [[0, 0, 0,
0, 0, \
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,\
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0\
, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]]
At the root of this, outboundTransformer is a (proton) AutoOutboundTransformer.
It calls AMQPNativeOutboundTransformer.transform(), which calls
msg.readBytes(data), which sometimes writes all 0s to data. Here msg is an
ActiveMQBytesMessage.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (AMQ-4887) ActiveMQBytesMessage will lost content if message's property was set before copy
[
https://issues.apache.org/jira/browse/AMQ-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13840030#comment-13840030
]
Timothy Bish commented on AMQ-4887:
---
I'll review in a bit
ActiveMQBytesMessage will lost content if message's property was set before
copy
-
Key: AMQ-4887
URL: https://issues.apache.org/jira/browse/AMQ-4887
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.9.0
Reporter: caoyunfei
Assignee: Timothy Bish
Attachments: AMQ-4887.patch, ActiveMQBytesMessage.java.patch,
ActiveMQBytesMessageTest.java, Consumer.java, Producer.java
Original Estimate: 24h
Remaining Estimate: 24h
ActiveMQBytesMessage will lost content if message's property was set before
copy. Here is the test code:
Producer:
MessageProducer producer;
//initialize Connection, Session, MessageProducer
byte[] bs = bytes message.getBytes();
BytesMessage message = session.createBytesMessage();
message.writeBytes(bs); //write bytes to message 1
for(int i=0; i 0; i++){
// then set message's propery 2
message.setLongProperty(sendTime, System.currentTimeMillis());
try{
producer.send(message);
}catch(){
e.printStackTrace();
}
}
Consumer:
MessageConsumer consumer
//initailize Connection, Session, MessageConsumer
for(int i=0; i10; i++){
ActiveMQBytesMessage msg =
(ActiveMQBytesMessage)consumer.receive(60*1000);
long sendTime = message.getLongProperty(sendTime);
System.out.println(sendtime: + sendTime);
ByteSequence bs = message.getMessage().getContent();
System.out.println(bytes data: + new String(bs.getData()));
}
Expected result:
consumer gets bytes data in all received messages
Actual result:
only the fisrt message has bytes data, all other messages lost bytes data,
while long property value is not lost;
Analysization:
message gets copied when send, it will call storeContent() before copy,
DataOutputStream dataOut will be closed and the data in dataOut will be set
to conent. This works correctly if there are no property was set.
when setLongProperty was called, it will call setObjectProperty() then will
call initializeWriting(), here DataOutputStream dataOut will be create
AGAIN.
So when message was copied in second time, DataOutputStream dataOut is NOT
null, but EMPTY, it will clear the value in content.
suggestion:
restore the content data to DataOutputStream dataOut when nitializeWriting()
my fix:
ActiveMQBytesMessage :
private void initializeWriting() throws JMSException {
669The original code
..
701
//fix code
if(this.content !=null this.content.length 0){
try{
this.dataOut.write(this.content.getData());
}catch(IOException ioe){
throw JMSExceptionSupport.create(ioe);
}
}
702}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Assigned] (AMQ-4887) ActiveMQBytesMessage will lost content if message's property was set before copy
[
https://issues.apache.org/jira/browse/AMQ-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish reassigned AMQ-4887:
-
Assignee: Timothy Bish (was: Kevin Earls)
ActiveMQBytesMessage will lost content if message's property was set before
copy
-
Key: AMQ-4887
URL: https://issues.apache.org/jira/browse/AMQ-4887
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.9.0
Reporter: caoyunfei
Assignee: Timothy Bish
Attachments: AMQ-4887.patch, ActiveMQBytesMessage.java.patch,
ActiveMQBytesMessageTest.java, Consumer.java, Producer.java
Original Estimate: 24h
Remaining Estimate: 24h
ActiveMQBytesMessage will lost content if message's property was set before
copy. Here is the test code:
Producer:
MessageProducer producer;
//initialize Connection, Session, MessageProducer
byte[] bs = bytes message.getBytes();
BytesMessage message = session.createBytesMessage();
message.writeBytes(bs); //write bytes to message 1
for(int i=0; i 0; i++){
// then set message's propery 2
message.setLongProperty(sendTime, System.currentTimeMillis());
try{
producer.send(message);
}catch(){
e.printStackTrace();
}
}
Consumer:
MessageConsumer consumer
//initailize Connection, Session, MessageConsumer
for(int i=0; i10; i++){
ActiveMQBytesMessage msg =
(ActiveMQBytesMessage)consumer.receive(60*1000);
long sendTime = message.getLongProperty(sendTime);
System.out.println(sendtime: + sendTime);
ByteSequence bs = message.getMessage().getContent();
System.out.println(bytes data: + new String(bs.getData()));
}
Expected result:
consumer gets bytes data in all received messages
Actual result:
only the fisrt message has bytes data, all other messages lost bytes data,
while long property value is not lost;
Analysization:
message gets copied when send, it will call storeContent() before copy,
DataOutputStream dataOut will be closed and the data in dataOut will be set
to conent. This works correctly if there are no property was set.
when setLongProperty was called, it will call setObjectProperty() then will
call initializeWriting(), here DataOutputStream dataOut will be create
AGAIN.
So when message was copied in second time, DataOutputStream dataOut is NOT
null, but EMPTY, it will clear the value in content.
suggestion:
restore the content data to DataOutputStream dataOut when nitializeWriting()
my fix:
ActiveMQBytesMessage :
private void initializeWriting() throws JMSException {
669The original code
..
701
//fix code
if(this.content !=null this.content.length 0){
try{
this.dataOut.write(this.content.getData());
}catch(IOException ioe){
throw JMSExceptionSupport.create(ioe);
}
}
702}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
Re: [VOTE] Release ActiveMQ-CPP v3.8.2 #2
+1 On Wed, Dec 4, 2013 at 8:40 PM, Timothy Bish tabish...@gmail.com wrote: Vote open for ActiveMQ-CPP v3.8.2 This is a small patch release that addresses some bugs found since the v3.8.1 release. The source bundles for this release can be found here: http://people.apache.org/~tabish/cms-3.8.x/ The Wiki page for the release is here: http://activemq.apache.org/cms/activemq-cpp-382-release.html The list of issues fixed in this release is available here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311207styleName=Htmlversion=12325248 Please cast your votes: [ ] +1 Release the source as Apache ActiveMQ-CPP 3.8.2 [ ] -1 Veto the release (provide specific comments) Here is my +1 -- Tim Bish Sr Software Engineer | RedHat Inc. tim.b...@redhat.com | www.fusesource.com | www.redhat.com skype: tabish121 | twitter: @tabish121 blog: http://timbish.blogspot.com/ -- Claus Ibsen - Red Hat, Inc. Email: cib...@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
Re: [VOTE] Release ActiveMQ-CPP v3.8.2 #2
+1 On Thu, Dec 5, 2013 at 8:20 AM, Claus Ibsen claus.ib...@gmail.com wrote: +1 On Wed, Dec 4, 2013 at 8:40 PM, Timothy Bish tabish...@gmail.com wrote: Vote open for ActiveMQ-CPP v3.8.2 This is a small patch release that addresses some bugs found since the v3.8.1 release. The source bundles for this release can be found here: http://people.apache.org/~tabish/cms-3.8.x/ The Wiki page for the release is here: http://activemq.apache.org/cms/activemq-cpp-382-release.html The list of issues fixed in this release is available here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311207styleName=Htmlversion=12325248 Please cast your votes: [ ] +1 Release the source as Apache ActiveMQ-CPP 3.8.2 [ ] -1 Veto the release (provide specific comments) Here is my +1 -- Tim Bish Sr Software Engineer | RedHat Inc. tim.b...@redhat.com | www.fusesource.com | www.redhat.com skype: tabish121 | twitter: @tabish121 blog: http://timbish.blogspot.com/ -- Claus Ibsen - Red Hat, Inc. Email: cib...@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen -- Christian Posta http://www.christianposta.com/blog twitter: @christianposta
[jira] [Commented] (AMQ-4887) ActiveMQBytesMessage will lost content if message's property was set before copy
[
https://issues.apache.org/jira/browse/AMQ-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13840214#comment-13840214
]
Timothy Bish commented on AMQ-4887:
---
The fix seems reasonable but I think there's still a problem here if the
content is stored compressed. If you simply rewrite the contents into the
output stream and message compression is enabled you'd be writing compressed
data with an output stream that's doing compression again so that's not good,
plus you be adding new data onto already compressed content if you use any of
the write methods so you are doubly corrupted.
ActiveMQBytesMessage will lost content if message's property was set before
copy
-
Key: AMQ-4887
URL: https://issues.apache.org/jira/browse/AMQ-4887
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.9.0
Reporter: caoyunfei
Assignee: Timothy Bish
Attachments: AMQ-4887.patch, ActiveMQBytesMessage.java.patch,
ActiveMQBytesMessageTest.java, Consumer.java, Producer.java
Original Estimate: 24h
Remaining Estimate: 24h
ActiveMQBytesMessage will lost content if message's property was set before
copy. Here is the test code:
Producer:
MessageProducer producer;
//initialize Connection, Session, MessageProducer
byte[] bs = bytes message.getBytes();
BytesMessage message = session.createBytesMessage();
message.writeBytes(bs); //write bytes to message 1
for(int i=0; i 0; i++){
// then set message's propery 2
message.setLongProperty(sendTime, System.currentTimeMillis());
try{
producer.send(message);
}catch(){
e.printStackTrace();
}
}
Consumer:
MessageConsumer consumer
//initailize Connection, Session, MessageConsumer
for(int i=0; i10; i++){
ActiveMQBytesMessage msg =
(ActiveMQBytesMessage)consumer.receive(60*1000);
long sendTime = message.getLongProperty(sendTime);
System.out.println(sendtime: + sendTime);
ByteSequence bs = message.getMessage().getContent();
System.out.println(bytes data: + new String(bs.getData()));
}
Expected result:
consumer gets bytes data in all received messages
Actual result:
only the fisrt message has bytes data, all other messages lost bytes data,
while long property value is not lost;
Analysization:
message gets copied when send, it will call storeContent() before copy,
DataOutputStream dataOut will be closed and the data in dataOut will be set
to conent. This works correctly if there are no property was set.
when setLongProperty was called, it will call setObjectProperty() then will
call initializeWriting(), here DataOutputStream dataOut will be create
AGAIN.
So when message was copied in second time, DataOutputStream dataOut is NOT
null, but EMPTY, it will clear the value in content.
suggestion:
restore the content data to DataOutputStream dataOut when nitializeWriting()
my fix:
ActiveMQBytesMessage :
private void initializeWriting() throws JMSException {
669The original code
..
701
//fix code
if(this.content !=null this.content.length 0){
try{
this.dataOut.write(this.content.getData());
}catch(IOException ioe){
throw JMSExceptionSupport.create(ioe);
}
}
702}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (AMQ-4887) ActiveMQBytesMessage will lost content if message's property was set before copy
[
https://issues.apache.org/jira/browse/AMQ-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13840219#comment-13840219
]
Timothy Bish commented on AMQ-4887:
---
I'm also going to guess that the StreamMessage implementation suffers from the
same problem and the test should be expanded to check that message too, as well
as the compressed case.
ActiveMQBytesMessage will lost content if message's property was set before
copy
-
Key: AMQ-4887
URL: https://issues.apache.org/jira/browse/AMQ-4887
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.9.0
Reporter: caoyunfei
Assignee: Timothy Bish
Attachments: AMQ-4887.patch, ActiveMQBytesMessage.java.patch,
ActiveMQBytesMessageTest.java, Consumer.java, Producer.java
Original Estimate: 24h
Remaining Estimate: 24h
ActiveMQBytesMessage will lost content if message's property was set before
copy. Here is the test code:
Producer:
MessageProducer producer;
//initialize Connection, Session, MessageProducer
byte[] bs = bytes message.getBytes();
BytesMessage message = session.createBytesMessage();
message.writeBytes(bs); //write bytes to message 1
for(int i=0; i 0; i++){
// then set message's propery 2
message.setLongProperty(sendTime, System.currentTimeMillis());
try{
producer.send(message);
}catch(){
e.printStackTrace();
}
}
Consumer:
MessageConsumer consumer
//initailize Connection, Session, MessageConsumer
for(int i=0; i10; i++){
ActiveMQBytesMessage msg =
(ActiveMQBytesMessage)consumer.receive(60*1000);
long sendTime = message.getLongProperty(sendTime);
System.out.println(sendtime: + sendTime);
ByteSequence bs = message.getMessage().getContent();
System.out.println(bytes data: + new String(bs.getData()));
}
Expected result:
consumer gets bytes data in all received messages
Actual result:
only the fisrt message has bytes data, all other messages lost bytes data,
while long property value is not lost;
Analysization:
message gets copied when send, it will call storeContent() before copy,
DataOutputStream dataOut will be closed and the data in dataOut will be set
to conent. This works correctly if there are no property was set.
when setLongProperty was called, it will call setObjectProperty() then will
call initializeWriting(), here DataOutputStream dataOut will be create
AGAIN.
So when message was copied in second time, DataOutputStream dataOut is NOT
null, but EMPTY, it will clear the value in content.
suggestion:
restore the content data to DataOutputStream dataOut when nitializeWriting()
my fix:
ActiveMQBytesMessage :
private void initializeWriting() throws JMSException {
669The original code
..
701
//fix code
if(this.content !=null this.content.length 0){
try{
this.dataOut.write(this.content.getData());
}catch(IOException ioe){
throw JMSExceptionSupport.create(ioe);
}
}
702}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (AMQ-4910) Windows batch script doesn't like spaces in installation path
[
https://issues.apache.org/jira/browse/AMQ-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13840229#comment-13840229
]
Sam Yi commented on AMQ-4910:
-
Seems like this is caused by one of the new java arguments from commit
981c8e247f11871265a20a48e463096028188f36; I was able to work around this by
putting double quotes around the path in the following line:
{code}wrapper.java.additional.15=-Djava.security.auth.login.config=%ACTIVEMQ_CONF%/login.config{code}
Windows batch script doesn't like spaces in installation path
-
Key: AMQ-4910
URL: https://issues.apache.org/jira/browse/AMQ-4910
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.9.0
Environment: Windows 7
Reporter: Matt Kusnierz
Priority: Minor
If you unzip the binary distribution to C:\Program
Files\apache-active-mq-5.9.0 or any directory that contains a space in it,
the bin\activemq.bat file fails to start. With the error message:
Error: Could not find or load main class
Files\apache-activemq-5.9.0\bin\..\conf\login.config
Work-around - either unzip to a directory with no spaces, or set the
ACTIVEMQ_HOME environment variable to the short version of the path, e.g.
set ACTIVEMQ_HOME=c:\Progra~1\apache-activemq-5.9.0
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (AMQ-4921) Setting JMSReplyTo with a topic destination does not work
Martin Lichtin created AMQ-4921: --- Summary: Setting JMSReplyTo with a topic destination does not work Key: AMQ-4921 URL: https://issues.apache.org/jira/browse/AMQ-4921 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.7.0 Reporter: Martin Lichtin The use case is about communicating with the StatisticsPlugin: Sending a message and setting JMSReplyTo with a destination for the response message(s). Doing (via Camel) in.setHeader(JMSReplyTo, topic://mydest); results in the broker producing messages to the mydest queue. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQ-4921) Setting JMSReplyTo with a topic destination does not work
[ https://issues.apache.org/jira/browse/AMQ-4921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13840260#comment-13840260 ] Timothy Bish commented on AMQ-4921: --- Do you have a unit test? Have you tested against v5.9.0? Setting JMSReplyTo with a topic destination does not work - Key: AMQ-4921 URL: https://issues.apache.org/jira/browse/AMQ-4921 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.7.0 Reporter: Martin Lichtin The use case is about communicating with the StatisticsPlugin: Sending a message and setting JMSReplyTo with a destination for the response message(s). Doing (via Camel) in.setHeader(JMSReplyTo, topic://mydest); results in the broker producing messages to the mydest queue. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (AMQ-4910) Windows batch script doesn't like spaces in installation path
[ https://issues.apache.org/jira/browse/AMQ-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQ-4910. --- Resolution: Fixed Fix Version/s: 5.10.0 Update the wrapper.conf files with quotes around the new login config file definition. Windows batch script doesn't like spaces in installation path - Key: AMQ-4910 URL: https://issues.apache.org/jira/browse/AMQ-4910 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.9.0 Environment: Windows 7 Reporter: Matt Kusnierz Priority: Minor Fix For: 5.10.0 If you unzip the binary distribution to C:\Program Files\apache-active-mq-5.9.0 or any directory that contains a space in it, the bin\activemq.bat file fails to start. With the error message: Error: Could not find or load main class Files\apache-activemq-5.9.0\bin\..\conf\login.config Work-around - either unzip to a directory with no spaces, or set the ACTIVEMQ_HOME environment variable to the short version of the path, e.g. set ACTIVEMQ_HOME=c:\Progra~1\apache-activemq-5.9.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (AMQ-4922) BrokerService.addConnector(URI bindAddress) binds the port before starting the broker.
Hiram Chirino created AMQ-4922: -- Summary: BrokerService.addConnector(URI bindAddress) binds the port before starting the broker. Key: AMQ-4922 URL: https://issues.apache.org/jira/browse/AMQ-4922 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.9.0 Reporter: Hiram Chirino -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQ-4922) BrokerService.addConnector(URI bindAddress) binds the port before starting the broker.
[ https://issues.apache.org/jira/browse/AMQ-4922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13840289#comment-13840289 ] Hiram Chirino commented on AMQ-4922: I've got fix started at: https://github.com/chirino/activemq/tree/AMQ-4922 There might be some tests remaining that try to get the local port before starting the broker. Need to find and fix those tests before merging into trunk. BrokerService.addConnector(URI bindAddress) binds the port before starting the broker. -- Key: AMQ-4922 URL: https://issues.apache.org/jira/browse/AMQ-4922 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.9.0 Reporter: Hiram Chirino -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: [VOTE] Release ActiveMQ-CPP v3.8.2 #2
+1 On Wed, Dec 4, 2013 at 2:40 PM, Timothy Bish tabish...@gmail.com wrote: Vote open for ActiveMQ-CPP v3.8.2 This is a small patch release that addresses some bugs found since the v3.8.1 release. The source bundles for this release can be found here: http://people.apache.org/~tabish/cms-3.8.x/ The Wiki page for the release is here: http://activemq.apache.org/cms/activemq-cpp-382-release.html The list of issues fixed in this release is available here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311207styleName=Htmlversion=12325248 Please cast your votes: [ ] +1 Release the source as Apache ActiveMQ-CPP 3.8.2 [ ] -1 Veto the release (provide specific comments) Here is my +1 -- Tim Bish Sr Software Engineer | RedHat Inc. tim.b...@redhat.com | www.fusesource.com | www.redhat.com skype: tabish121 | twitter: @tabish121 blog: http://timbish.blogspot.com/ -- Hiram Chirino Engineering | Red Hat, Inc. hchir...@redhat.com | fusesource.com | redhat.com skype: hiramchirino | twitter: @hiramchirino blog: Hiram Chirino's Bit Mojo
[jira] [Created] (AMQ-4923) Replicated LevelDB: Loss of broker Quorum fails to fully stop the master
Hiram Chirino created AMQ-4923: -- Summary: Replicated LevelDB: Loss of broker Quorum fails to fully stop the master Key: AMQ-4923 URL: https://issues.apache.org/jira/browse/AMQ-4923 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.9.0 Reporter: Hiram Chirino Assignee: Hiram Chirino Master keeps reporting: INFO | The connection to 'tcp://10.64.132.143:55732' is taking a long time to shutdown. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (AMQ-4923) Replicated LevelDB: Loss of broker Quorum fails to fully stop the master
[ https://issues.apache.org/jira/browse/AMQ-4923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino resolved AMQ-4923. Resolution: Fixed Fix Version/s: 5.10.0 Fixed. Replicated LevelDB: Loss of broker Quorum fails to fully stop the master Key: AMQ-4923 URL: https://issues.apache.org/jira/browse/AMQ-4923 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.9.0 Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 5.10.0 Master keeps reporting: INFO | The connection to 'tcp://10.64.132.143:55732' is taking a long time to shutdown. -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: 回复： Is it all right to reduce the timeout as a walkaround for AMQNET-338?
It's hard to say what the worst-case would be, since it's application
specific. I think an orderly shutdown would be to disconnect all producers
and consumers first, and then close the connection.
On Thu, Dec 5, 2013 at 4:19 AM, 汤・吉诃德 hellkni...@foxmail.com wrote:
Hi Jim, thanks for your quick and detailed reply. Actually , I want to
call connection.Close() when the user close the client program (such as
click the close button of program window), not wait for GC to clean up the
connection object. Is it still OK to reduce the timeout ? What is the worst
case scenario of forcefully abort readerThread after a shorter timeout ?
-- 原始邮件 --
*发件人:* Jim Gomes;jgo...@apache.org;
*发送时间:* 2013年12月5日(星期四) 中午11:03
*收件人:* 汤・吉诃德hellkni...@foxmail.com; ActiveMQ Dev
dev@activemq.apache.org;
*主题:* Re: Is it all right to reduce the timeout as a walkaround for
AMQNET-338?
The 30 second time-out was meant to give the reader thread a reasonable
time to finish what it is doing and shut itself down gracefully. Once it
times out, then it is forcefully shutdown as a last resort. Normally, the
graceful shutdown should occur very rapidly. If you are just letting the
garbage collector clean things up on program termination, then your app
probably isn't doing any meaningful work so it should be fine to
forcefully shut it down after a shorter timeout.
On Tue, Dec 3, 2013 at 10:28 PM, 汤・吉诃德 hellkni...@foxmail.com wrote:
Hi Jim, I want to use the temporary walkaround mentioned by the issue
reporter, to reduce the timeout in the following code from 30 seconds to 2
seconds:
if(null != readThread)
{
if(Thread.CurrentThread != readThread readThread.IsAlive)
{
if(!readThread.Join((int) MAX_THREAD_WAIT.TotalMilliseconds))
{
readThread.Abort();
}
}
readThread = null;
}
However, I am worried about my walkaround : Could there be any harm if I
reduce the timeout ? By default, the code wait as long as 30 seconds for
readThread to join. What is the purpose of such a behaviour ?What could
keep readThread alive for 30 seconds while closing connection ? Is it OK to
wait for a shorter timespan?
Jenkins build is back to stable : ActiveMQ » ActiveMQ :: MQTT Protocol #1429
See https://builds.apache.org/job/ActiveMQ/org.apache.activemq$activemq-mqtt/1429/
[jira] [Commented] (AMQNET-454) Add Apache Qpid provider to NMS
[ https://issues.apache.org/jira/browse/AMQNET-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13840555#comment-13840555 ] Chuck Rolke commented on AMQNET-454: I have an initial commit for Apache.NMS.AMQP for your review. Please see: h3. Apache.QPID vendor library files * Available at [https://github.com/ChugR/Apache.NMS-vendor.Apache.QPID] * Includes net-2.0 and net-4.0 binaries build with Visual Studios 2008 and 2010 respectively. * Fits naturally into vendor/Apache.Qpid * Code version 0.27.0.16034 is a snapshot of Qpid trunk (0.27) and Proton trunk (0.5+) as of 2013-11-25 (unix day 16034). A natural update to this would happen with the release of stable versions of Qpid 0.26 and Proton 0.6. * Includes binary dll files only. h3. Apache.NMS.AMQP provider source tree * Sources available at [https://github.com/ChugR/Apache.NMS.AMQP] * Includes nant code to build net-2.0 and net-4.0 versions. * This code is a shell. It will create an AMQP connection but not provide any other services for NMS. It is a framework for further contributions. This code set supports both AMQP 0-10 and AMQP 1.0 Regards, Chuck Add Apache Qpid provider to NMS --- Key: AMQNET-454 URL: https://issues.apache.org/jira/browse/AMQNET-454 Project: ActiveMQ .Net Issue Type: New Feature Components: NMS Affects Versions: 1.6.0 Reporter: Chuck Rolke Assignee: Jim Gomes NMS includes various providers ActiveMQ, STOMP, MSMQ, EMS, and WCF. This issue proposes to add [Apache Qpid|http://qpid.apache.org/index.html] as another provider. Qpid has a [Messaging .NET Binding|http://qpid.apache.org/releases/qpid-0.24/programming/book/ch05.html] that is layered on top of the native C++ Qpid Messaging client. The Qpid .NET binding is attractive as the hook for tying in Qpid as an NMS provider. The proposed NMS provider supports [AMQP 1.0|http://qpid.apache.org/amqp.html] by including [Qpid Proton|http://qpid.apache.org/proton/index.html] libraries. From a high level this addition to Active.NMS would consist of two parts * Add Qpid as a vendor kit. This includes both the Qpid .NET Binding and Qpid Proton in a single kit. * Add the new provider with code linking NMS to Qpid -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQ-4887) ActiveMQBytesMessage will lost content if message's property was set before copy
[
https://issues.apache.org/jira/browse/AMQ-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13840559#comment-13840559
]
Timothy Bish commented on AMQ-4887:
---
[~kearls] Updated the test case to show the other bits that are broken. I
patched the bytes message and started Stream Message. Thought you might want
to take a crack at addressing the compressed case in StreamMessage and seeing
if there's anything else needed.
ActiveMQBytesMessage will lost content if message's property was set before
copy
-
Key: AMQ-4887
URL: https://issues.apache.org/jira/browse/AMQ-4887
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.9.0
Reporter: caoyunfei
Assignee: Timothy Bish
Attachments: AMQ-4887.patch, ActiveMQBytesMessage.java.patch,
ActiveMQBytesMessageTest.java, Consumer.java, Producer.java
Original Estimate: 24h
Remaining Estimate: 24h
ActiveMQBytesMessage will lost content if message's property was set before
copy. Here is the test code:
Producer:
MessageProducer producer;
//initialize Connection, Session, MessageProducer
byte[] bs = bytes message.getBytes();
BytesMessage message = session.createBytesMessage();
message.writeBytes(bs); //write bytes to message 1
for(int i=0; i 0; i++){
// then set message's propery 2
message.setLongProperty(sendTime, System.currentTimeMillis());
try{
producer.send(message);
}catch(){
e.printStackTrace();
}
}
Consumer:
MessageConsumer consumer
//initailize Connection, Session, MessageConsumer
for(int i=0; i10; i++){
ActiveMQBytesMessage msg =
(ActiveMQBytesMessage)consumer.receive(60*1000);
long sendTime = message.getLongProperty(sendTime);
System.out.println(sendtime: + sendTime);
ByteSequence bs = message.getMessage().getContent();
System.out.println(bytes data: + new String(bs.getData()));
}
Expected result:
consumer gets bytes data in all received messages
Actual result:
only the fisrt message has bytes data, all other messages lost bytes data,
while long property value is not lost;
Analysization:
message gets copied when send, it will call storeContent() before copy,
DataOutputStream dataOut will be closed and the data in dataOut will be set
to conent. This works correctly if there are no property was set.
when setLongProperty was called, it will call setObjectProperty() then will
call initializeWriting(), here DataOutputStream dataOut will be create
AGAIN.
So when message was copied in second time, DataOutputStream dataOut is NOT
null, but EMPTY, it will clear the value in content.
suggestion:
restore the content data to DataOutputStream dataOut when nitializeWriting()
my fix:
ActiveMQBytesMessage :
private void initializeWriting() throws JMSException {
669The original code
..
701
//fix code
if(this.content !=null this.content.length 0){
try{
this.dataOut.write(this.content.getData());
}catch(IOException ioe){
throw JMSExceptionSupport.create(ioe);
}
}
702}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (AMQ-4887) ActiveMQBytesMessage will lost content if message's property was set before copy
[
https://issues.apache.org/jira/browse/AMQ-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish updated AMQ-4887:
--
Attachment: AMQ-4887.patch
Updated patch that fixes bytes message and the uncompressed case in stream
message.
ActiveMQBytesMessage will lost content if message's property was set before
copy
-
Key: AMQ-4887
URL: https://issues.apache.org/jira/browse/AMQ-4887
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.9.0
Reporter: caoyunfei
Assignee: Timothy Bish
Attachments: AMQ-4887.patch, AMQ-4887.patch,
ActiveMQBytesMessage.java.patch, ActiveMQBytesMessageTest.java,
Consumer.java, Producer.java
Original Estimate: 24h
Remaining Estimate: 24h
ActiveMQBytesMessage will lost content if message's property was set before
copy. Here is the test code:
Producer:
MessageProducer producer;
//initialize Connection, Session, MessageProducer
byte[] bs = bytes message.getBytes();
BytesMessage message = session.createBytesMessage();
message.writeBytes(bs); //write bytes to message 1
for(int i=0; i 0; i++){
// then set message's propery 2
message.setLongProperty(sendTime, System.currentTimeMillis());
try{
producer.send(message);
}catch(){
e.printStackTrace();
}
}
Consumer:
MessageConsumer consumer
//initailize Connection, Session, MessageConsumer
for(int i=0; i10; i++){
ActiveMQBytesMessage msg =
(ActiveMQBytesMessage)consumer.receive(60*1000);
long sendTime = message.getLongProperty(sendTime);
System.out.println(sendtime: + sendTime);
ByteSequence bs = message.getMessage().getContent();
System.out.println(bytes data: + new String(bs.getData()));
}
Expected result:
consumer gets bytes data in all received messages
Actual result:
only the fisrt message has bytes data, all other messages lost bytes data,
while long property value is not lost;
Analysization:
message gets copied when send, it will call storeContent() before copy,
DataOutputStream dataOut will be closed and the data in dataOut will be set
to conent. This works correctly if there are no property was set.
when setLongProperty was called, it will call setObjectProperty() then will
call initializeWriting(), here DataOutputStream dataOut will be create
AGAIN.
So when message was copied in second time, DataOutputStream dataOut is NOT
null, but EMPTY, it will clear the value in content.
suggestion:
restore the content data to DataOutputStream dataOut when nitializeWriting()
my fix:
ActiveMQBytesMessage :
private void initializeWriting() throws JMSException {
669The original code
..
701
//fix code
if(this.content !=null this.content.length 0){
try{
this.dataOut.write(this.content.getData());
}catch(IOException ioe){
throw JMSExceptionSupport.create(ioe);
}
}
702}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
