[java] RFC: moving persistent messages, queue durability
While looking into QPID-1941 (moved messages remaining in the JMX
viewMessages() results for the old queue, but not being considered
still on the queue) for GSoC I have noticed an inconsistency between
the recovery behaviour of persistent messages which are moved, and
those handled only by the normal message delivery path.
if (message.isPersistent() toQueue.isDurable())
{
store.enqueueMessage(storeContext, toQueue, message.getMessageId());
}
The above check in the SimpleAMQQueue moveMessagesToAnotherQueue
method means that persistent messages are not moved in the message
store unless the destination queue is durable. As a result, if the
broker is restarted while using a persistence store any persistent
messages which have been moved to a non-durable queue are lost.
However, any persistent messages delivered directly to the same
non-durable queue are currently recovered at startup as the broker
places no such restriction on messages in the normal delivery path, eg
in IncomingMessage:
if (persistent)
{
.
.
.
store.enqueueMessage(.)
I am not particularly bothered either way by the 'should persistent
messages should be recovered from non durable queues' argument, but I
do think they should be treated equally whether they have been moved
or not. It means changing the previous behaviour of the section, but I
think it should be entirely consistent one way or the other, so...any
objections to me removing the durability check from the move method?
Robbie
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-1935) FailoverTest and QueueBrowser*Test fail on persistent builds
[ https://issues.apache.org/jira/browse/QPID-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12728279#action_12728279 ] Rafael H. Schloming commented on QPID-1935: --- I'm reverting the fix for this as it breaks the normal cpp profile. FailoverTest and QueueBrowser*Test fail on persistent builds Key: QPID-1935 URL: https://issues.apache.org/jira/browse/QPID-1935 Project: Qpid Issue Type: Bug Components: Java Tests Affects Versions: 0.6 Reporter: Aidan Skinner Assignee: Aidan Skinner Fix For: 0.6 The failover and queuebrowser tests do weird things that cause them to fail when run persistently. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [java] RFC: moving persistent messages, queue durability
Removing that check seems like the right thing to do to me. There's a
couple of other oddities like that elsewhere in the stores though. We
should really make a decision about how to treat them, but IMO the
right thing to do is to persist if *either* the queue or the message
is marked as durable.
On 7/7/09, Robbie Gemmell robbie.gemm...@gmail.com wrote:
While looking into QPID-1941 (moved messages remaining in the JMX
viewMessages() results for the old queue, but not being considered
still on the queue) for GSoC I have noticed an inconsistency between
the recovery behaviour of persistent messages which are moved, and
those handled only by the normal message delivery path.
if (message.isPersistent() toQueue.isDurable())
{
store.enqueueMessage(storeContext, toQueue, message.getMessageId());
}
The above check in the SimpleAMQQueue moveMessagesToAnotherQueue
method means that persistent messages are not moved in the message
store unless the destination queue is durable. As a result, if the
broker is restarted while using a persistence store any persistent
messages which have been moved to a non-durable queue are lost.
However, any persistent messages delivered directly to the same
non-durable queue are currently recovered at startup as the broker
places no such restriction on messages in the normal delivery path, eg
in IncomingMessage:
if (persistent)
{
.
.
.
store.enqueueMessage(.)
I am not particularly bothered either way by the 'should persistent
messages should be recovered from non durable queues' argument, but I
do think they should be treated equally whether they have been moved
or not. It means changing the previous behaviour of the section, but I
think it should be entirely consistent one way or the other, so...any
objections to me removing the durability check from the move method?
Robbie
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
--
Sent from Google Mail for mobile | mobile.google.com
Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
A witty saying proves nothing - Voltaire
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [RFC][java] Additional Broker Logging
Martin Ritchie wrote: Java Broker Users, I have been working on designs for improving the logging from the Java Broker. The current logging is more aimed at developers so providing more operational focused log messages would be good. The design is up on the wiki here: http://cwiki.apache.org/confluence/display/qpid/Java+Broker+Design+-+Operational+Logging and will be proceeding under JIRA : https://issues.apache.org/jira/browse/QPID-1970 Comments greatly appreciated. At this stage I'm looking to get the ability to perform this type of logging started with some simple status updates. Refinement of the messages and other details will come later. I like the high level overview. How exactly do you see protocol level logging fitting into things? Also, have you considered finer grained control of logging? It might be useful to be able to enable or disable finer grained logging for a specific connection. Regarding the detailed design notes, I'm struggling a bit to understand the purpose of the various interfaces you describe. Based on the high level overview, I would have imagined something simpler, e.g. Channel.log(...), and Connection.log(...). --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [java] RFC: moving persistent messages, queue durability
2009/7/7 Aidan Skinner ai...@apache.org:
Removing that check seems like the right thing to do to me. There's a
couple of other oddities like that elsewhere in the stores though. We
should really make a decision about how to treat them, but IMO the
right thing to do is to persist if *either* the queue or the message
is marked as durable.
Definitely not an *either* thing (transient messages on a durable
queue should certainly not be persisted). In practice we currently
put persistent messages in the store regardless of the durability of
the queue (e.g. even if the queue is a temporary queue). This is
wrong really, but because of the messed up way our configuration is,
people may be depending on it so we would need to make it clear before
changing.
I would leave as is for the moment - IMHO we should JIRA the whole
durable message on transient queue thing (if it isn't already) and
solve that properly as a separate task.
-- Rob
On 7/7/09, Robbie Gemmell robbie.gemm...@gmail.com wrote:
While looking into QPID-1941 (moved messages remaining in the JMX
viewMessages() results for the old queue, but not being considered
still on the queue) for GSoC I have noticed an inconsistency between
the recovery behaviour of persistent messages which are moved, and
those handled only by the normal message delivery path.
if (message.isPersistent() toQueue.isDurable())
{
store.enqueueMessage(storeContext, toQueue, message.getMessageId());
}
The above check in the SimpleAMQQueue moveMessagesToAnotherQueue
method means that persistent messages are not moved in the message
store unless the destination queue is durable. As a result, if the
broker is restarted while using a persistence store any persistent
messages which have been moved to a non-durable queue are lost.
However, any persistent messages delivered directly to the same
non-durable queue are currently recovered at startup as the broker
places no such restriction on messages in the normal delivery path, eg
in IncomingMessage:
if (persistent)
{
.
.
.
store.enqueueMessage(.)
I am not particularly bothered either way by the 'should persistent
messages should be recovered from non durable queues' argument, but I
do think they should be treated equally whether they have been moved
or not. It means changing the previous behaviour of the section, but I
think it should be entirely consistent one way or the other, so...any
objections to me removing the durability check from the move method?
Robbie
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
--
Sent from Google Mail for mobile | mobile.google.com
Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
A witty saying proves nothing - Voltaire
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-1952) C++: client request memory leak on windows
[ https://issues.apache.org/jira/browse/QPID-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Huston resolved QPID-1952. Resolution: Fixed Fix Version/s: 0.6 Assignee: Steve Huston I tested the patch here with Purify - no more leak. Fix is in r791997. C++: client request memory leak on windows -- Key: QPID-1952 URL: https://issues.apache.org/jira/browse/QPID-1952 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.5 Environment: Windows XP Pro w/SP3 Reporter: David Rennalls Assignee: Steve Huston Fix For: 0.6 Attachments: AsynchIO.cpp.diff, Connector_memory_leak.patch, Main2.cpp I'm experiencing a memory leak when using the client library on Windows (0.5 release) when sending a single request. From what debugging I've done so far it looks like the The AsynchIO object used by the TCPConnector is not being deleted. When the connection is being closed aio-queueForDeletion() is called from TCPConnector::closeInternal().. However in AsynchIO::queueForDeletion() aio.opsInProgress 0 so the 'delete this' branch is not done. There are no more queueForDeletion() calls made on the aio object (after opsInProgress is 0) and so it never gets deleted. The ConnectionImpl object involved is not cleaned up either, the shared_ptr to it has a non-zero ref count but I'm guessing it's related to the AsynchIO object not being cleaned up. There used to be some code in AsynchIO::completion() that seems like it would do the necessary delete (see below). It was removed with code changes in https://issues.apache.org/jira/browse/QPID-1550 because 'It fixed a memory corruption on the broker side by deleting too early' (from Steve H.) -// Lock released; ok to delete if all is done. -if (opsInProgress == 0 queuedDelete) -delete this; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-1973) Calling session.objects fails to return objects in certain cases
[ https://issues.apache.org/jira/browse/QPID-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned QPID-1973: -- Assignee: Ted Ross Calling session.objects fails to return objects in certain cases Key: QPID-1973 URL: https://issues.apache.org/jira/browse/QPID-1973 Project: Qpid Issue Type: Bug Components: Ruby Client Environment: Fedora 11, Qpid svn trunk revision 787286 Reporter: Arjun Roy Assignee: Ted Ross Original Estimate: 72h Remaining Estimate: 72h Suppose we have a simple schema consisting of class A and class B, where A is the parent of class B. Suppose also that we have a simple ruby console program that, upon having the obj_props callback called by the broker, ignores all objects not of class A. For any objects of class A, it prints out the instance (of class A) and all corresponding child instances (of class B). In the case where managed_connections is enabled in the session, if the agent connected to the broker before the console, then the session.objects method fails to return any objects. The agent can be running for a large length of time before the console connects, and other consoles that connected can see all the published qmf objects, but the console that connected after the agent cannot see the objects. Finally, I tried writing a simple console that extended debug console that queried for objects on user input to try debugging when session.objects() fails. It appears that the console picks up the qmf objects in the schema written by the user before picking up any of the org.apache.* schemas, and that after the console picks up the org.apache.* schemas, then session.objects() works normally. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
