[java] transaction handling
I've recently been wrestling with transaction handling in the java broker in the context of 0-9-1 compliance. We're currently not strictly spec compliant with 0-9-1 as we will resend messages that have been rolled back. 0-9 and 0-8 are... ambiguous... on this matter, and I've been trying to retain current behaviour for them. However, it's a) a massive PITA and b) probably Not What You Want. If you're rolling back a consume it's almost certainly because you can't cope with the message. If you think b) I'd like to float the idea of 0.8 being the "we are breaking backwards compatibility" release so we can fix the conf file, the command line etc. Thoughts? - Aidan -- 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: Unresolved issues but marked 0.6
On Tue, Mar 30, 2010 at 4:28 PM, Marnie McCormack wrote: > That's corect - they will have done. I've been reviewing them when time > permits, but happy for other devs to review too to aid progress. Hoping > we'll have more time for review in the 0.8 cycle. This is essentially inevitable with CTR. Somehow there's never enough time to get around to all the reviews, but I've never seen a patch not go in due to lack of review time with RTC. - Aidan -- 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: svn commit: r926829 - /qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client/message/JMSDestinationTest.java
On Wed, Mar 31, 2010 at 7:56 PM, Rajith Attapattu wrote: > We could temporarily exclude until the issue is fixed. > If you are going to check in a fix soon, I'd say don't bother. I'm not entirely clear on what the issue with this is at this stage. Is the problem that the java broker doesn't auto-declare exchanges on first use? AFAICT ritchiem's commits in December should have resolved the problem with the header itself. In any case I think it'd be clearer if the test did an explicit exchange declare. - Aidan -- 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: Performance measurement clients using the new API.
On 03/31/2010 02:22 PM, Rafael Schloming wrote: Gordon Sim wrote: On 03/31/2010 05:41 PM, Alan Conway wrote: I think we can extend qpid_send and qpid_recv to do most of the things that perftest and latencytest do. Interested in any ideas on the topic. I like the approach. +1 Here's what I propose: Additional qpid_send options: --report=Y/N: report sender throughput on exit. --report-interval=SECS: print throughput report every N seconds. FYI qpid-bench does this based on # of messages as opposed to time (not sure which is preferred or if both make sense in some scenarios). --timestamp=Y/N: timestamp each message. --rate=MSGS/SEC: send at this rate, 0 means fast as possible. --padding=BYTES: add this much padding to messages. --time-limit=SECS: stop after this time, 0 means no limit. --max-noreply=N: don't send more than N messages without receiving a reply. Creates a reply queue and sets reply_to on every N/2 messages. In addition you'd need to configure things like sender/receiver capacity, sync/async, etc. Indeed, some if this is already there in qpid_send the options mentioned above are additions to whats there now. qpid_send currently reads in message content from std::in. This can be very useful for ad-hoc tests or scripting different types of test. However for performance you would most likely want to avoid any extra overhead and have the message content generated by the tool itself. Additional qpid_recv options: --report=Y/N: report latency and throughput statistics on exit. Latency is only calculated for messages with a timestamp. --report-interval=SECS: print latency and throughput statistics every N seconds. New qpid_recv behavior: if reply-to is set, echo the message to that address. I could see two different types of useful behaviour here. One as above, where you echo the message. Another would simply be to send an empty message correlated by correlation-id. E.g. for the case where the original message is very large and you only wish the response to indicate that it was received (could have received message sie in the response message in some way). Of course keeping it simple to begin with is also fine! If we want the flexibility I would suggest putting some sort of opcode in the original message that would instruct the receiver how to respond, e.g. echo the original message, send an empty (but correlated) message, or even send a message with the receiver's current stats in it. qpid_recv also prints out each message to std::out and again this would need to be optional to avoid impacting perf numbers. The python drain example has a nice feature where you can specify what aspect of each message gets printed. Adding that to qpid_recv would be valuable. The --max-noreply=N option is a simple form of end-to-end throughput. The sender sets reply-to on every N/2 messages. It won't send more than N messages beyond the last message that was replied to. The receiver replies whenever reply-to is set. Multiple instances of sender & receiver can be mixed and matched however you want, to measure e.g. shared queue, pub-sub etc. scenarios. I'm deliberately avoiding the do-everything swiss army knife approach of perftest, that results in an overly complex test that is not as flexible as the separate sender/receiver approach. One thing that would be useful is to have multiple sessions per connection for send/recv. This would be useful even for performance testing, though it does complicate the reporting a little. Overall I'm not sure we should try to cram too much into qpid-send and qpid-recv. I think it might make sense to have two sets of utilities with the difference being based on whether the utilities themselves generate the messages, or whether they're simply used to send/recv messages generated outside the utilities. I think the use cases around these two scenarios are fairly different. The things that generate/consume their own content are more oriented towards diagnostics/testing/benchmarking, and I would expect to have options around frequency, size, type of content, etc, whereas the things that send/recv existing content would have more options around reading in messages from various formats, writing them out, etc. I propose thinking in terms of qpid-send/qpid-recv which are basically command line versions of the API used to send/recv message content generated outside the utility (that content could come by file, command-line args, stdin, etc), and then qpid-source/qpid-sink which are used as artificial sources/sinks for messages and more oriented towards testing/diagnostics/performance. I'm not sure I see the benefit of this distinction. I would be inclined to think of qpid-send/receive as tools that send messages generated in various ways: 2 of which being read from stdin and generated internally, we could add more as needed. --Rafael - Apache Qpid - AMQP Messaging Implementation Pr
RE: svn commit: r926829 - /qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client/message/JMSDestinationTest.java
I don't have any current plans to look at it, so ill exclude it tomorrow
(can't be bothered firing up the dev env just now, enough of this computer
lark for tonight... time for Lost :P)
Robbie
> -Original Message-
> From: Rajith Attapattu [mailto:rajit...@gmail.com]
> Sent: 31 March 2010 19:57
> To: dev@qpid.apache.org
> Subject: Re: svn commit: r926829 -
> /qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/clien
> t/message/JMSDestinationTest.java
>
> We could temporarily exclude until the issue is fixed.
> If you are going to check in a fix soon, I'd say don't bother.
>
> Rajith
>
> On Wed, Mar 31, 2010 at 2:54 PM, Robbie Gemmell
> wrote:
> > This new test fails on all the Java test profiles other than
> java.0.10. Is it ok to exclude it from these?
> >
> > Regards,
> > Robbie
> >
> >> -Original Message-
> >> From: raj...@apache.org [mailto:raj...@apache.org]
> >> Sent: 23 March 2010 22:48
> >> To: comm...@qpid.apache.org
> >> Subject: svn commit: r926829 -
> >>
> /qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/clien
> >> t/message/JMSDestinationTest.java
> >>
> >> Author: rajith
> >> Date: Tue Mar 23 22:48:23 2010
> >> New Revision: 926829
> >>
> >> URL: http://svn.apache.org/viewvc?rev=926829&view=rev
> >> Log:
> >> Added test case for QPID-2242 using a custom exchange to verify the
> >> fix.
> >>
> >> Modified:
> >>
> >>
> qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client
> >> /message/JMSDestinationTest.java
> >>
> >> Modified:
> >>
> qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client
> >> /message/JMSDestinationTest.java
> >> URL:
> >>
> http://svn.apache.org/viewvc/qpid/trunk/qpid/java/systests/src/main/jav
> >>
> a/org/apache/qpid/test/client/message/JMSDestinationTest.java?rev=92682
> >> 9&r1=926828&r2=926829&view=diff
> >>
> ===
> >> ===
> >> ---
> >>
> qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client
> >> /message/JMSDestinationTest.java (original)
> >> +++
> >>
> qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client
> >> /message/JMSDestinationTest.java Tue Mar 23 22:48:23 2010
> >> @@ -21,9 +21,11 @@
> >> package org.apache.qpid.test.client.message;
> >>
> >> import org.apache.qpid.configuration.ClientProperties;
> >> +import org.apache.qpid.client.AMQAnyDestination;
> >> import org.apache.qpid.client.AMQDestination;
> >> import org.apache.qpid.client.AMQTopic;
> >> import org.apache.qpid.client.CustomJMSXProperty;
> >> +import org.apache.qpid.framing.AMQShortString;
> >> import org.apache.qpid.management.common.mbeans.ManagedQueue;
> >> import org.apache.qpid.test.utils.JMXTestUtils;
> >> import org.apache.qpid.test.utils.QpidTestCase;
> >> @@ -327,4 +329,45 @@ public class JMSDestinationTest extends
> >>
> >> }
> >>
> >> + /**
> >> + * Send a message to a custom exchange and then verify
> >> + * the message received has the proper destination set
> >> + *
> >> + * @throws Exception
> >> + */
> >> + public void testGetDestinationWithCustomExchange() throws
> >> Exception
> >> + {
> >> +
> >> + AMQDestination dest = new AMQAnyDestination(new
> >> AMQShortString("my-exchange"),
> >> + new
> >> AMQShortString("direct"),
> >> + new
> >> AMQShortString("test"),
> >> + false,
> >> + false,
> >> + new
> >> AMQShortString("test"),
> >> + false,
> >> + new
> >> AMQShortString[]{new AMQShortString("test")});
> >> +
> >> + // to force the creation of my-exchange.
> >> + sendMessage(_session, dest, 1);
> >> +
> >> + MessageProducer prod = _session.createProducer(dest);
> >> +
> >> + MessageConsumer consumer = _session.createConsumer(dest);
> >> +
> >> + _connection.start();
> >> +
> >> + sendMessage(_session, dest, 1);
> >> +
> >> + Message message = consumer.receive(1);
> >> +
> >> + assertNotNull("Message should not be null", message);
> >> +
> >> + Destination destination = message.getJMSDestination();
> >> +
> >> + assertNotNull("JMSDestination should not be null",
> >> destination);
> >> +
> >> + assertEquals("Incorrect Destination name", "my-exchange",
> >> dest.getExchangeName().asString());
> >> + assertEquals("Incorrect Destination type", "direct",
> >> dest.getExchangeClass().asString());
> >> + assertEquals("Incorrect Routing Key", "test",
> >> dest.getRoutingKey().asString());
> >> + }
> >> }
> >>
> >>
> >>
> >>
> -
> >>
Re: svn commit: r926829 - /qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client/message/JMSDestinationTest.java
We could temporarily exclude until the issue is fixed.
If you are going to check in a fix soon, I'd say don't bother.
Rajith
On Wed, Mar 31, 2010 at 2:54 PM, Robbie Gemmell
wrote:
> This new test fails on all the Java test profiles other than java.0.10. Is it
> ok to exclude it from these?
>
> Regards,
> Robbie
>
>> -Original Message-
>> From: raj...@apache.org [mailto:raj...@apache.org]
>> Sent: 23 March 2010 22:48
>> To: comm...@qpid.apache.org
>> Subject: svn commit: r926829 -
>> /qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/clien
>> t/message/JMSDestinationTest.java
>>
>> Author: rajith
>> Date: Tue Mar 23 22:48:23 2010
>> New Revision: 926829
>>
>> URL: http://svn.apache.org/viewvc?rev=926829&view=rev
>> Log:
>> Added test case for QPID-2242 using a custom exchange to verify the
>> fix.
>>
>> Modified:
>>
>> qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client
>> /message/JMSDestinationTest.java
>>
>> Modified:
>> qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client
>> /message/JMSDestinationTest.java
>> URL:
>> http://svn.apache.org/viewvc/qpid/trunk/qpid/java/systests/src/main/jav
>> a/org/apache/qpid/test/client/message/JMSDestinationTest.java?rev=92682
>> 9&r1=926828&r2=926829&view=diff
>> ===
>> ===
>> ---
>> qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client
>> /message/JMSDestinationTest.java (original)
>> +++
>> qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client
>> /message/JMSDestinationTest.java Tue Mar 23 22:48:23 2010
>> @@ -21,9 +21,11 @@
>> package org.apache.qpid.test.client.message;
>>
>> import org.apache.qpid.configuration.ClientProperties;
>> +import org.apache.qpid.client.AMQAnyDestination;
>> import org.apache.qpid.client.AMQDestination;
>> import org.apache.qpid.client.AMQTopic;
>> import org.apache.qpid.client.CustomJMSXProperty;
>> +import org.apache.qpid.framing.AMQShortString;
>> import org.apache.qpid.management.common.mbeans.ManagedQueue;
>> import org.apache.qpid.test.utils.JMXTestUtils;
>> import org.apache.qpid.test.utils.QpidTestCase;
>> @@ -327,4 +329,45 @@ public class JMSDestinationTest extends
>>
>> }
>>
>> + /**
>> + * Send a message to a custom exchange and then verify
>> + * the message received has the proper destination set
>> + *
>> + * @throws Exception
>> + */
>> + public void testGetDestinationWithCustomExchange() throws
>> Exception
>> + {
>> +
>> + AMQDestination dest = new AMQAnyDestination(new
>> AMQShortString("my-exchange"),
>> + new
>> AMQShortString("direct"),
>> + new
>> AMQShortString("test"),
>> + false,
>> + false,
>> + new
>> AMQShortString("test"),
>> + false,
>> + new
>> AMQShortString[]{new AMQShortString("test")});
>> +
>> + // to force the creation of my-exchange.
>> + sendMessage(_session, dest, 1);
>> +
>> + MessageProducer prod = _session.createProducer(dest);
>> +
>> + MessageConsumer consumer = _session.createConsumer(dest);
>> +
>> + _connection.start();
>> +
>> + sendMessage(_session, dest, 1);
>> +
>> + Message message = consumer.receive(1);
>> +
>> + assertNotNull("Message should not be null", message);
>> +
>> + Destination destination = message.getJMSDestination();
>> +
>> + assertNotNull("JMSDestination should not be null",
>> destination);
>> +
>> + assertEquals("Incorrect Destination name", "my-exchange",
>> dest.getExchangeName().asString());
>> + assertEquals("Incorrect Destination type", "direct",
>> dest.getExchangeClass().asString());
>> + assertEquals("Incorrect Routing Key", "test",
>> dest.getRoutingKey().asString());
>> + }
>> }
>>
>>
>>
>> -
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:commits-subscr...@qpid.apache.org
>
>
>
> -
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2418) Existing durable subscription with selector is not unsubscribed during change to new subscription
[ https://issues.apache.org/jira/browse/QPID-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852046#action_12852046 ] Rajith Attapattu commented on QPID-2418: Interesting, the queue declare with the new selector merely updates the the selector on the queue? The AMQP spec doesn't really define the behaviour if a queue declare is sent with the same name but different args (in this case the selector). So I wouldn't argue that the Java broker is wrong. The c++ client merely ignores the queue declare. IMO I think both brokers are wrong as this can lead to subtle errors that can go undetected - but thats separate topic all together. So on the C++ side, the queue is not deleted due to the java client bug. So the message is there and gets sent to the client who now has a new selector (with 0-10 client side selectors) which matches and the message is delivered. Anyways once we fix the Java client to issue a queue this should be taken care of. Always a good idea to run the default java and c++ profiles before an update. > Existing durable subscription with selector is not unsubscribed during > change to new subscription > -- > > Key: QPID-2418 > URL: https://issues.apache.org/jira/browse/QPID-2418 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: M4, 0.5, 0.6 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.7 > > Attachments: 0001-QPID-2418-branch.patch, 0001-QPID-2418-trunk.patch > > > AMQSession.createDurableSubscriber(topic, name, messageSelector, noLocal) > does not unsubscribe existing durable subscriptions. Whilst it does check for > existing durable subscriptions in use by the client with the same name, it > instead simply closes the subscriptions then creates a new one. As a result > of not unsubscribing, the queue backing the subscription is not deleted > before being used by the updated subscription as it should be (and as happens > in the 0_8 and 0_10 subclasses when using durable subscriptions without > selectors). -- 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: svn commit: r926829 - /qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client/message/JMSDestinationTest.java
This new test fails on all the Java test profiles other than java.0.10. Is it
ok to exclude it from these?
Regards,
Robbie
> -Original Message-
> From: raj...@apache.org [mailto:raj...@apache.org]
> Sent: 23 March 2010 22:48
> To: comm...@qpid.apache.org
> Subject: svn commit: r926829 -
> /qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/clien
> t/message/JMSDestinationTest.java
>
> Author: rajith
> Date: Tue Mar 23 22:48:23 2010
> New Revision: 926829
>
> URL: http://svn.apache.org/viewvc?rev=926829&view=rev
> Log:
> Added test case for QPID-2242 using a custom exchange to verify the
> fix.
>
> Modified:
>
> qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client
> /message/JMSDestinationTest.java
>
> Modified:
> qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client
> /message/JMSDestinationTest.java
> URL:
> http://svn.apache.org/viewvc/qpid/trunk/qpid/java/systests/src/main/jav
> a/org/apache/qpid/test/client/message/JMSDestinationTest.java?rev=92682
> 9&r1=926828&r2=926829&view=diff
> ===
> ===
> ---
> qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client
> /message/JMSDestinationTest.java (original)
> +++
> qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client
> /message/JMSDestinationTest.java Tue Mar 23 22:48:23 2010
> @@ -21,9 +21,11 @@
> package org.apache.qpid.test.client.message;
>
> import org.apache.qpid.configuration.ClientProperties;
> +import org.apache.qpid.client.AMQAnyDestination;
> import org.apache.qpid.client.AMQDestination;
> import org.apache.qpid.client.AMQTopic;
> import org.apache.qpid.client.CustomJMSXProperty;
> +import org.apache.qpid.framing.AMQShortString;
> import org.apache.qpid.management.common.mbeans.ManagedQueue;
> import org.apache.qpid.test.utils.JMXTestUtils;
> import org.apache.qpid.test.utils.QpidTestCase;
> @@ -327,4 +329,45 @@ public class JMSDestinationTest extends
>
> }
>
> +/**
> + * Send a message to a custom exchange and then verify
> + * the message received has the proper destination set
> + *
> + * @throws Exception
> + */
> +public void testGetDestinationWithCustomExchange() throws
> Exception
> +{
> +
> +AMQDestination dest = new AMQAnyDestination(new
> AMQShortString("my-exchange"),
> +new
> AMQShortString("direct"),
> +new
> AMQShortString("test"),
> +false,
> +false,
> +new
> AMQShortString("test"),
> +false,
> +new
> AMQShortString[]{new AMQShortString("test")});
> +
> +// to force the creation of my-exchange.
> +sendMessage(_session, dest, 1);
> +
> +MessageProducer prod = _session.createProducer(dest);
> +
> +MessageConsumer consumer = _session.createConsumer(dest);
> +
> +_connection.start();
> +
> +sendMessage(_session, dest, 1);
> +
> +Message message = consumer.receive(1);
> +
> +assertNotNull("Message should not be null", message);
> +
> +Destination destination = message.getJMSDestination();
> +
> +assertNotNull("JMSDestination should not be null",
> destination);
> +
> +assertEquals("Incorrect Destination name", "my-exchange",
> dest.getExchangeName().asString());
> +assertEquals("Incorrect Destination type", "direct",
> dest.getExchangeClass().asString());
> +assertEquals("Incorrect Routing Key", "test",
> dest.getRoutingKey().asString());
> +}
> }
>
>
>
> -
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:commits-subscr...@qpid.apache.org
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Performance measurement clients using the new API.
On Wed, 31 Mar 2010, Rafael Schloming wrote: Overall I'm not sure we should try to cram too much into qpid-send and qpid-recv. I think it might make sense to have two sets of utilities with the difference being based on whether the utilities themselves generate the messages, or whether they're simply used to send/recv messages generated outside the utilities. I think the use cases around these two scenarios are fairly different. The things that generate/consume their own content are more oriented towards diagnostics/testing/benchmarking, and I would expect to have options around frequency, size, type of content, etc, whereas the things that send/recv existing content would have more options around reading in messages from various formats, writing them out, etc. I propose thinking in terms of qpid-send/qpid-recv which are basically command line versions of the API used to send/recv message content generated outside the utility (that content could come by file, command-line args, stdin, etc), and then qpid-source/qpid-sink which are used as artificial sources/sinks for messages and more oriented towards testing/diagnostics/performance. (Watch out! Naming talk.) Generally speaking, names in user-facing tools should identity match their equivalents in other contexts (the API modulo stemming, language in documentation, etc). Variation is useful to the user when it stands for a difference, and it's detrimental when it doesn't. Since "recv" doesn't appear in the API or elsewhere in qpid messaging, it shouldn't appear in the tool's name either. "recv" may seem nice because it's shorter, but it's one more variant for the user to remember. So, I'd vote for qpid-receive instead. Justin - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: svn commit: r929095 - in /qpid/trunk/qpid/java: systests/src/main/java/org/apache/qpid/test/unit/ct/ systests/src/main/java/org/apache/qpid/test/unit/topic/ test-profiles/
The changes made to DurableSubscriptionTest were not intended to yet expose
this bug any more than it was, and were deliberately kept short so that they
wouldnt (the comment is innacurate youll note, as it isnt doing what it was
originally and I forgot to update that). The new test added in
DurableSubscriberTest that absolutely would expose it was excluded until it
is fixed so that automated builds wouldnt be been broken.
What I didnt do was run the test using the C++ broker as I didnt think I was
changing anything of any particular note, but I failed to consider that it
could behave slightly differently due to use of client side selectors rather
than the server side selectors used by the Java broker. The broker doesnt
create a new queue, but it does change the filters used to select messages
meaning that messages never get onto the queue which will on the C++ broker,
which I imagine is where the test now fails. I'll take that into account
when updating it.
Robbie
> -Original Message-
> From: Rajith Attapattu [mailto:rajit...@gmail.com]
> Sent: 31 March 2010 19:20
> To: dev@qpid.apache.org; robbie.gemm...@gmail.com
> Subject: Re: svn commit: r929095 - in /qpid/trunk/qpid/java:
> systests/src/main/java/org/apache/qpid/test/unit/ct/
> systests/src/main/java/org/apache/qpid/test/unit/topic/ test-profiles/
>
> Robbie,
>
> The change to the test case is causing the test to fail when run
> against the c++ (which should be expected as we have a bug in the Java
> client).
> However it's passing against the Java broker, so perhaps better to
> investigate this.
> I suspect the broker is creating a new queue bcos the args list is
> different (the selector being different)?
>
> Also I think we shouldn't change any tests before a fix is made.
> Currently our automated builds are failing due to this.
> I hope andrew gets a chance to check in his fix soon.
>
> Regards,
>
> Rajith
>
> On Tue, Mar 30, 2010 at 7:50 AM, wrote:
> > Author: robbie
> > Date: Tue Mar 30 11:50:18 2010
> > New Revision: 929095
> >
> > URL: http://svn.apache.org/viewvc?rev=929095&view=rev
> > Log:
> > QPID-2417 , QPID-2418 , QPID-2449 : expand topic testing,
> specifically around the change and unsubscription of durable
> subscriptions
> >
> > Modified:
> >
> qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/unit/
> ct/DurableSubscriberTest.java
> >
> qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/unit/
> topic/DurableSubscriptionTest.java
> > qpid/trunk/qpid/java/test-profiles/Excludes
> > qpid/trunk/qpid/java/test-profiles/JavaExcludes
> >
> > Modified:
> qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/unit/c
> t/DurableSubscriberTest.java
> > URL:
> http://svn.apache.org/viewvc/qpid/trunk/qpid/java/systests/src/main/jav
> a/org/apache/qpid/test/unit/ct/DurableSubscriberTest.java?rev=929095&r1
> =929094&r2=929095&view=diff
> >
> ===
> ===
> > ---
> qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/unit/c
> t/DurableSubscriberTest.java (original)
> > +++
> qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/unit/c
> t/DurableSubscriberTest.java Tue Mar 30 11:50:18 2010
> > @@ -19,6 +19,10 @@ package org.apache.qpid.test.unit.ct;
> >
> > import javax.jms.*;
> >
> > +import org.apache.qpid.client.AMQConnection;
> > +import org.apache.qpid.client.AMQQueue;
> > +import org.apache.qpid.client.AMQSession;
> > +import org.apache.qpid.client.AMQTopic;
> > import org.apache.qpid.test.utils.QpidTestCase;
> >
> > /**
> > @@ -163,5 +167,301 @@ public class DurableSubscriberTest exten
> > durConnection2.close();
> > }
> > }
> > +
> > + /**
> > + * create and register a durable subscriber without a message
> selector and then unsubscribe it
> > + * create and register a durable subscriber with a message
> selector and then close it
> > + * restart the broker
> > + * send matching and non matching messages
> > + * recreate and register the durable subscriber with a message
> selector
> > + * verify only the matching messages are received
> > + */
> > + public void testDurSubChangedToHaveSelectorThenRestart() throws
> Exception
> > + {
> > + if (! isBrokerStorePersistent())
> > + {
> > + _logger.warn("Test skipped due to requirement of a
> persistent store");
> > + return;
> > + }
> > +
> > + final String SUB_NAME=getTestQueueName();
> > +
> > + TopicConnectionFactory factory = getConnectionFactory();
> > + Topic topic = (Topic)
> getInitialContext().lookup(_topicName);
> > +
> > + //create and register a durable subscriber then unsubscribe
> it
> > + TopicConnection durConnection =
> factory.createTopicConnection("guest", "guest");
> > + TopicSession durSession =
> durConnection.createTopicSession(false, Session.AUTO_ACKNOWLEDGE);
> > +
[jira] Commented: (QPID-2418) Existing durable subscription with selector is not unsubscribed during change to new subscription
[ https://issues.apache.org/jira/browse/QPID-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852032#action_12852032 ] Robbie Gemmell commented on QPID-2418: -- The changes made to DurableSubscriptionTest were not intended to yet expose this bug any more than it was, and were deliberately kept short so that they wouldnt (the comment is innacurate youll note, as it isnt doing what it was originally and I forgot to update that). The new test added in DurableSubscriberTest that absolutely would expose it was excluded until it is fixed so that automated builds wouldnt be been broken. What I didnt do was run the test using the C++ broker as I didnt think I was changing anything of any particular note, but I failed to consider that it could behave slightly differently due to use of client side selectors rather than the server side selectors used by the Java broker. The broker doenst create a new queue, but it does change the filters used to select messages meaning that messges never get onto the queue which will on the C++ broker, which I imagine is where the test now fails. I'll take that into account when updating it. > Existing durable subscription with selector is not unsubscribed during > change to new subscription > -- > > Key: QPID-2418 > URL: https://issues.apache.org/jira/browse/QPID-2418 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: M4, 0.5, 0.6 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.7 > > Attachments: 0001-QPID-2418-branch.patch, 0001-QPID-2418-trunk.patch > > > AMQSession.createDurableSubscriber(topic, name, messageSelector, noLocal) > does not unsubscribe existing durable subscriptions. Whilst it does check for > existing durable subscriptions in use by the client with the same name, it > instead simply closes the subscriptions then creates a new one. As a result > of not unsubscribing, the queue backing the subscription is not deleted > before being used by the updated subscription as it should be (and as happens > in the 0_8 and 0_10 subclasses when using durable subscriptions without > selectors). -- 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: Performance measurement clients using the new API.
Gordon Sim wrote: On 03/31/2010 05:41 PM, Alan Conway wrote: I think we can extend qpid_send and qpid_recv to do most of the things that perftest and latencytest do. Interested in any ideas on the topic. I like the approach. +1 Here's what I propose: Additional qpid_send options: --report=Y/N: report sender throughput on exit. --report-interval=SECS: print throughput report every N seconds. FYI qpid-bench does this based on # of messages as opposed to time (not sure which is preferred or if both make sense in some scenarios). --timestamp=Y/N: timestamp each message. --rate=MSGS/SEC: send at this rate, 0 means fast as possible. --padding=BYTES: add this much padding to messages. --time-limit=SECS: stop after this time, 0 means no limit. --max-noreply=N: don't send more than N messages without receiving a reply. Creates a reply queue and sets reply_to on every N/2 messages. In addition you'd need to configure things like sender/receiver capacity, sync/async, etc. qpid_send currently reads in message content from std::in. This can be very useful for ad-hoc tests or scripting different types of test. However for performance you would most likely want to avoid any extra overhead and have the message content generated by the tool itself. Additional qpid_recv options: --report=Y/N: report latency and throughput statistics on exit. Latency is only calculated for messages with a timestamp. --report-interval=SECS: print latency and throughput statistics every N seconds. New qpid_recv behavior: if reply-to is set, echo the message to that address. I could see two different types of useful behaviour here. One as above, where you echo the message. Another would simply be to send an empty message correlated by correlation-id. E.g. for the case where the original message is very large and you only wish the response to indicate that it was received (could have received message sie in the response message in some way). Of course keeping it simple to begin with is also fine! If we want the flexibility I would suggest putting some sort of opcode in the original message that would instruct the receiver how to respond, e.g. echo the original message, send an empty (but correlated) message, or even send a message with the receiver's current stats in it. qpid_recv also prints out each message to std::out and again this would need to be optional to avoid impacting perf numbers. The python drain example has a nice feature where you can specify what aspect of each message gets printed. Adding that to qpid_recv would be valuable. The --max-noreply=N option is a simple form of end-to-end throughput. The sender sets reply-to on every N/2 messages. It won't send more than N messages beyond the last message that was replied to. The receiver replies whenever reply-to is set. Multiple instances of sender & receiver can be mixed and matched however you want, to measure e.g. shared queue, pub-sub etc. scenarios. I'm deliberately avoiding the do-everything swiss army knife approach of perftest, that results in an overly complex test that is not as flexible as the separate sender/receiver approach. One thing that would be useful is to have multiple sessions per connection for send/recv. This would be useful even for performance testing, though it does complicate the reporting a little. Overall I'm not sure we should try to cram too much into qpid-send and qpid-recv. I think it might make sense to have two sets of utilities with the difference being based on whether the utilities themselves generate the messages, or whether they're simply used to send/recv messages generated outside the utilities. I think the use cases around these two scenarios are fairly different. The things that generate/consume their own content are more oriented towards diagnostics/testing/benchmarking, and I would expect to have options around frequency, size, type of content, etc, whereas the things that send/recv existing content would have more options around reading in messages from various formats, writing them out, etc. I propose thinking in terms of qpid-send/qpid-recv which are basically command line versions of the API used to send/recv message content generated outside the utility (that content could come by file, command-line args, stdin, etc), and then qpid-source/qpid-sink which are used as artificial sources/sinks for messages and more oriented towards testing/diagnostics/performance. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: svn commit: r929095 - in /qpid/trunk/qpid/java: systests/src/main/java/org/apache/qpid/test/unit/ct/ systests/src/main/java/org/apache/qpid/test/unit/topic/ test-profiles/
Robbie,
The change to the test case is causing the test to fail when run
against the c++ (which should be expected as we have a bug in the Java
client).
However it's passing against the Java broker, so perhaps better to
investigate this.
I suspect the broker is creating a new queue bcos the args list is
different (the selector being different)?
Also I think we shouldn't change any tests before a fix is made.
Currently our automated builds are failing due to this.
I hope andrew gets a chance to check in his fix soon.
Regards,
Rajith
On Tue, Mar 30, 2010 at 7:50 AM, wrote:
> Author: robbie
> Date: Tue Mar 30 11:50:18 2010
> New Revision: 929095
>
> URL: http://svn.apache.org/viewvc?rev=929095&view=rev
> Log:
> QPID-2417 , QPID-2418 , QPID-2449 : expand topic testing, specifically around
> the change and unsubscription of durable subscriptions
>
> Modified:
>
> qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/unit/ct/DurableSubscriberTest.java
>
> qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/unit/topic/DurableSubscriptionTest.java
> qpid/trunk/qpid/java/test-profiles/Excludes
> qpid/trunk/qpid/java/test-profiles/JavaExcludes
>
> Modified:
> qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/unit/ct/DurableSubscriberTest.java
> URL:
> http://svn.apache.org/viewvc/qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/unit/ct/DurableSubscriberTest.java?rev=929095&r1=929094&r2=929095&view=diff
> ==
> ---
> qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/unit/ct/DurableSubscriberTest.java
> (original)
> +++
> qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/unit/ct/DurableSubscriberTest.java
> Tue Mar 30 11:50:18 2010
> @@ -19,6 +19,10 @@ package org.apache.qpid.test.unit.ct;
>
> import javax.jms.*;
>
> +import org.apache.qpid.client.AMQConnection;
> +import org.apache.qpid.client.AMQQueue;
> +import org.apache.qpid.client.AMQSession;
> +import org.apache.qpid.client.AMQTopic;
> import org.apache.qpid.test.utils.QpidTestCase;
>
> /**
> @@ -163,5 +167,301 @@ public class DurableSubscriberTest exten
> durConnection2.close();
> }
> }
> +
> + /**
> + * create and register a durable subscriber without a message selector
> and then unsubscribe it
> + * create and register a durable subscriber with a message selector and
> then close it
> + * restart the broker
> + * send matching and non matching messages
> + * recreate and register the durable subscriber with a message selector
> + * verify only the matching messages are received
> + */
> + public void testDurSubChangedToHaveSelectorThenRestart() throws Exception
> + {
> + if (! isBrokerStorePersistent())
> + {
> + _logger.warn("Test skipped due to requirement of a persistent
> store");
> + return;
> + }
> +
> + final String SUB_NAME=getTestQueueName();
> +
> + TopicConnectionFactory factory = getConnectionFactory();
> + Topic topic = (Topic) getInitialContext().lookup(_topicName);
> +
> + //create and register a durable subscriber then unsubscribe it
> + TopicConnection durConnection =
> factory.createTopicConnection("guest", "guest");
> + TopicSession durSession = durConnection.createTopicSession(false,
> Session.AUTO_ACKNOWLEDGE);
> + TopicSubscriber durSub1 = durSession.createDurableSubscriber(topic,
> SUB_NAME);
> + durConnection.start();
> + durSub1.close();
> + durSession.unsubscribe(SUB_NAME);
> + durSession.close();
> + durConnection.close();
> +
> + //create and register a durable subscriber with a message selector
> and then close it
> + TopicConnection durConnection2 =
> factory.createTopicConnection("guest", "guest");
> + TopicSession durSession2 = durConnection2.createTopicSession(false,
> Session.AUTO_ACKNOWLEDGE);
> + TopicSubscriber durSub2 = durSession2.createDurableSubscriber(topic,
> SUB_NAME, "testprop='true'", false);
> + durConnection2.start();
> + durSub2.close();
> + durSession2.close();
> + durConnection2.close();
> +
> + //now restart the server
> + try
> + {
> + restartBroker();
> + }
> + catch (Exception e)
> + {
> + _logger.error("problems restarting broker: " + e);
> + throw e;
> + }
> +
> + //send messages matching and not matching the selector
> + TopicConnection pubConnection =
> factory.createTopicConnection("guest", "guest");
> + TopicSession pubSession = pubConnection.createTopicSession(false,
> Session.AUTO_ACKNOWLEDGE);
> + TopicPublisher publisher = pubSession.createPublisher(topic);
> + for (int i = 0; i < 5; i++)
> + {
> + Message message = pubSes
Mina version
Could someone enlighten me about the Mina version currently used in Qpid please? I searched through the messages of the list back to 2006 and found this: http://mail-archives.apache.org/mod_mbox/qpid-dev/200612.mbox/%3cc5e632550612010029j3c0beec6p4eeff0aab1d36...@mail.gmail.com%3e That is, Qpid uses a snapshot version build from the revision 463149 at http://svn.apache.org/repos/asf/mina/trunk. However I also found mention of performance patches that were necessary for Qpid. Are they also included in the revision above or were they applied separately? Thank you, Emmanuel Bourg - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2418) Existing durable subscription with selector is not unsubscribed during change to new subscription
[ https://issues.apache.org/jira/browse/QPID-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851997#action_12851997 ] Rajith Attapattu commented on QPID-2418: When investigating the test failure for "testResubscribeWithChangedSelector" in the DurableSubscriptionTest, I was a bit shocked to see the amount of code duplication. This may have been due to a merge, but we definitely need to fix this. So thx for taking care of this. I haven't had chance to have a closer look at the patches, but please make sure tests pass against both the C++ and Java Broker before committing it. Also the change made in rev 929095 to the DurableSubscriptionTest.java (method testResubscribeWithChangedSelector) is somehow passing for the Java broker. Bcos we have the bug mentioned in this bug, it should be failing in both brokers. I am not so happy about checking in the change to the test case before a fix is committed as this has broken our automated builds. Perhaps the Java broker is creating a new queue as the arguments list is different (the selector being different) ? Isn't that a bug? Perhaps worthwhile investigating this. > Existing durable subscription with selector is not unsubscribed during > change to new subscription > -- > > Key: QPID-2418 > URL: https://issues.apache.org/jira/browse/QPID-2418 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: M4, 0.5, 0.6 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.7 > > Attachments: 0001-QPID-2418-branch.patch, 0001-QPID-2418-trunk.patch > > > AMQSession.createDurableSubscriber(topic, name, messageSelector, noLocal) > does not unsubscribe existing durable subscriptions. Whilst it does check for > existing durable subscriptions in use by the client with the same name, it > instead simply closes the subscriptions then creates a new one. As a result > of not unsubscribing, the queue backing the subscription is not deleted > before being used by the updated subscription as it should be (and as happens > in the 0_8 and 0_10 subclasses when using durable subscriptions without > selectors). -- 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: Many Mb of doc related tools checked in
Rajith Attapattu a écrit : I am sorry sir, but Maven is a big no due to the well documented reasons. You are paying a big price for that convenience :). I understand you had some troubles in the past with Maven, and considering the complexity of the Qpid project I'm not surprised. But for the specific purpose of building the documentation I don't think the "well documented reasons" apply. Even if you download it manually it's a one time job. I don't know why folks are so worried about it. Because it's a waste of time for anyone interested in building the documentation. Because one has to reinstall most of the tool chain on every checkout of the project (the Ant build assumes the stylesheets are copied in qpid/doc/book/docbook-xsl, and not outside the project tree). You do it once on your desktop computer, then once on your laptop, and then every time you checkout a different branch. That's definitely not a one time job. Emmanuel Bourg - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Performance measurement clients using the new API.
On 03/31/2010 05:41 PM, Alan Conway wrote: I think we can extend qpid_send and qpid_recv to do most of the things that perftest and latencytest do. Interested in any ideas on the topic. I like the approach. Here's what I propose: Additional qpid_send options: --report=Y/N: report sender throughput on exit. --report-interval=SECS: print throughput report every N seconds. --timestamp=Y/N: timestamp each message. --rate=MSGS/SEC: send at this rate, 0 means fast as possible. --padding=BYTES: add this much padding to messages. --time-limit=SECS: stop after this time, 0 means no limit. --max-noreply=N: don't send more than N messages without receiving a reply. Creates a reply queue and sets reply_to on every N/2 messages. qpid_send currently reads in message content from std::in. This can be very useful for ad-hoc tests or scripting different types of test. However for performance you would most likely want to avoid any extra overhead and have the message content generated by the tool itself. Additional qpid_recv options: --report=Y/N: report latency and throughput statistics on exit. Latency is only calculated for messages with a timestamp. --report-interval=SECS: print latency and throughput statistics every N seconds. New qpid_recv behavior: if reply-to is set, echo the message to that address. I could see two different types of useful behaviour here. One as above, where you echo the message. Another would simply be to send an empty message correlated by correlation-id. E.g. for the case where the original message is very large and you only wish the response to indicate that it was received (could have received message sie in the response message in some way). Of course keeping it simple to begin with is also fine! qpid_recv also prints out each message to std::out and again this would need to be optional to avoid impacting perf numbers. The python drain example has a nice feature where you can specify what aspect of each message gets printed. Adding that to qpid_recv would be valuable. The --max-noreply=N option is a simple form of end-to-end throughput. The sender sets reply-to on every N/2 messages. It won't send more than N messages beyond the last message that was replied to. The receiver replies whenever reply-to is set. Multiple instances of sender & receiver can be mixed and matched however you want, to measure e.g. shared queue, pub-sub etc. scenarios. I'm deliberately avoiding the do-everything swiss army knife approach of perftest, that results in an overly complex test that is not as flexible as the separate sender/receiver approach. One thing that would be useful is to have multiple sessions per connection for send/recv. This would be useful even for performance testing, though it does complicate the reporting a little. - 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-2477) std::cout in agent not used anymore
[ https://issues.apache.org/jira/browse/QPID-2477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved QPID-2477. -- Resolution: Fixed > std::cout in agent not used anymore > --- > > Key: QPID-2477 > URL: https://issues.apache.org/jira/browse/QPID-2477 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: 0.7 > Environment: Fedora Rawhide, Linux 2.6.34 x86_64, ... not important > here >Reporter: Jan Sarenik >Priority: Trivial > Fix For: 0.7 > > Attachments: qpid-agent-cout.diff > > > See attached one-liner. It removes the obsolete line. > (All cout calls were removed from C++ agent in r727265) -- 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: Many Mb of doc related tools checked in
On Wed, Mar 31, 2010 at 12:53 PM, Emmanuel Bourg wrote: > Jonathan Robie a écrit : > >> I think Maven is out, because people have been pretty loud about not >> wanting Yet Another Build System. > > In this case Maven isn't used as a build system, it's just a convenient tool > to build the documentation on any platform. I am sorry sir, but Maven is a big no due to the well documented reasons. You are paying a big price for that convenience :). > >> P.S. Did you run into problems trying to build on Windows using the tools >> mentioned in README.txt? > > Certainly, yum doesn't work on Windows ;) Installing the tool chain manually > is really a pain, I didn't try since I knew a simpler alternative. Even if you download it manually it's a one time job. I don't know why folks are so worried about it. The price you pay for the simple alternative is way too much :). > I don't want to disrupt your habits, keep the make file as the main way to > build the documentation. I would just suggest adding a simple alternative > for the developers that aren't using the reference system. > > Emmanuel Bourg > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Many Mb of doc related tools checked in
Jonathan Robie a écrit : I think Maven is out, because people have been pretty loud about not wanting Yet Another Build System. In this case Maven isn't used as a build system, it's just a convenient tool to build the documentation on any platform. P.S. Did you run into problems trying to build on Windows using the tools mentioned in README.txt? Certainly, yum doesn't work on Windows ;) Installing the tool chain manually is really a pain, I didn't try since I knew a simpler alternative. I don't want to disrupt your habits, keep the make file as the main way to build the documentation. I would just suggest adding a simple alternative for the developers that aren't using the reference system. Emmanuel Bourg - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Size of the Java client
would expect a message queue client to be not bigger than ~500KB (dependencies included and fully compressed with pack200+lzma) 500KB would be nice. Some of my "science experiments" target Java-based platforms with 1MB of Flash and 1MB of RAM. For now I open sockets to a server, and the server in turn does any queue manaement things as needed. http://www.maxim-ic.com/products/microcontrollers/tini/ Cheers, -JK - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Performance measurement clients using the new API.
I think we can extend qpid_send and qpid_recv to do most of the things that perftest and latencytest do. Interested in any ideas on the topic. Here's what I propose: Additional qpid_send options: --report=Y/N: report sender throughput on exit. --report-interval=SECS: print throughput report every N seconds. --timestamp=Y/N: timestamp each message. --rate=MSGS/SEC: send at this rate, 0 means fast as possible. --padding=BYTES: add this much padding to messages. --time-limit=SECS: stop after this time, 0 means no limit. --max-noreply=N: don't send more than N messages without receiving a reply. Creates a reply queue and sets reply_to on every N/2 messages. Additional qpid_recv options: --report=Y/N: report latency and throughput statistics on exit. Latency is only calculated for messages with a timestamp. --report-interval=SECS: print latency and throughput statistics every N seconds. New qpid_recv behavior: if reply-to is set, echo the message to that address. The --max-noreply=N option is a simple form of end-to-end throughput. The sender sets reply-to on every N/2 messages. It won't send more than N messages beyond the last message that was replied to. The receiver replies whenever reply-to is set. Multiple instances of sender & receiver can be mixed and matched however you want, to measure e.g. shared queue, pub-sub etc. scenarios. I'm deliberately avoiding the do-everything swiss army knife approach of perftest, that results in an overly complex test that is not as flexible as the separate sender/receiver approach. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Many Mb of doc related tools checked in
On 03/31/2010 12:18 PM, Emmanuel Bourg wrote: That's still better than installing the tool chain manually, but that sounds like a lot of troubles for something that is already done with a short Maven file. I'm more than happy to do what the group wants if (1) the group can all want the same thing, and (2) it's reasonably simple. I think Maven is out, because people have been pretty loud about not wanting Yet Another Build System. Jonathan P.S. Did you run into problems trying to build on Windows using the tools mentioned in README.txt? - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Many Mb of doc related tools checked in
On 03/31/2010 12:13 PM, Steve Huston wrote: I should probably go look at what's checked in first, but... Is there a defined set of tools for building the docs? Is there a reason you can't put a README there with a list of what's needed, and let people get it whatever way works best? The README is here: https://svn.apache.org/repos/asf/qpid/trunk/qpid/doc/book/README.txt The tools at least allegedly all work on Windows, I have not tried them on Windows (I don't have a Windows box). Perhaps you could have a go and see if there are issues with this tool chain on Windows? Jonathan - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Many Mb of doc related tools checked in
Jonathan Robie a écrit : We could move back to the earlier tool chain (ant, Saxon, Xerces, DocBook DTDs, DocBook stylesheets. Instead of checking these things into subdirectories, I could put them in a zip file in my people.apache.org account, and create an ant task that retrieves them and unzips them into the right subdirectories. For people like Rafi who do not want multiple copies on their system, I could write a shell script that creates symbolic links to the standard installed locations. People can modify this as needed if they have these things installed elsewhere. That's the best I've thought of so far. Thoughts? Jonathan That's still better than installing the tool chain manually, but that sounds like a lot of troubles for something that is already done with a short Maven file. Emmanuel Bourg - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: Many Mb of doc related tools checked in
Hi Jonathan, > We could move back to the earlier tool chain (ant, Saxon, Xerces, > DocBook DTDs, DocBook stylesheets. I'm hoping you can help me out here... When I see documentation sources checked in and mention of a way to build them, I think there must be some defined tools that build the docs. Analogous to a C++ compiler, linker, etc. And since I don't need to worry about downloading or committing a C++ compiler to svn, I'm confused about why this issue keeps coming up. > Instead of checking these things into subdirectories, I could > put them > in a zip file in my people.apache.org account, and create an ant task > that retrieves them and unzips them into the right subdirectories. > > For people like Rafi who do not want multiple copies on their > system, I > could write a shell script that creates symbolic links to the > standard > installed locations. People can modify this as needed if they > have these > things installed elsewhere. > > That's the best I've thought of so far. > > Thoughts? I should probably go look at what's checked in first, but... Is there a defined set of tools for building the docs? Is there a reason you can't put a README there with a list of what's needed, and let people get it whatever way works best? I would like to be able to work on the documentation at some point, so I am interested in getting this worked out. Thanks, -Steve - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Many Mb of doc related tools checked in
We could move back to the earlier tool chain (ant, Saxon, Xerces, DocBook DTDs, DocBook stylesheets. Instead of checking these things into subdirectories, I could put them in a zip file in my people.apache.org account, and create an ant task that retrieves them and unzips them into the right subdirectories. For people like Rafi who do not want multiple copies on their system, I could write a shell script that creates symbolic links to the standard installed locations. People can modify this as needed if they have these things installed elsewhere. That's the best I've thought of so far. Thoughts? Jonathan - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2418) Existing durable subscription with selector is not unsubscribed during change to new subscription
[ https://issues.apache.org/jira/browse/QPID-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2418: - Attachment: 0001-QPID-2418-trunk.patch 0001-QPID-2418-branch.patch > Existing durable subscription with selector is not unsubscribed during > change to new subscription > -- > > Key: QPID-2418 > URL: https://issues.apache.org/jira/browse/QPID-2418 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: M4, 0.5, 0.6 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.7 > > Attachments: 0001-QPID-2418-branch.patch, 0001-QPID-2418-trunk.patch > > > AMQSession.createDurableSubscriber(topic, name, messageSelector, noLocal) > does not unsubscribe existing durable subscriptions. Whilst it does check for > existing durable subscriptions in use by the client with the same name, it > instead simply closes the subscriptions then creates a new one. As a result > of not unsubscribing, the queue backing the subscription is not deleted > before being used by the updated subscription as it should be (and as happens > in the 0_8 and 0_10 subclasses when using durable subscriptions without > selectors). -- 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] Commented: (QPID-2476) Complete ACL implementation for 0-10 code path
[ https://issues.apache.org/jira/browse/QPID-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851860#action_12851860 ] Rajith Attapattu commented on QPID-2476: Andrew, Great to see you working on the ACL stuff. In view of keeping functionality/behaviour the same btw C++ and Java Broker, I would appreciate if the above items are discussed on the mailing list. I am also planning to work on some of the items listed above. I look forward to discussing these items on the list with you. Regards, Rajith > Complete ACL implementation for 0-10 code path > -- > > Key: QPID-2476 > URL: https://issues.apache.org/jira/browse/QPID-2476 > Project: Qpid > Issue Type: New Feature > Components: Java Broker >Affects Versions: 0.7 >Reporter: Andrew Kennedy > Fix For: 0.7 > > Original Estimate: 336h > Remaining Estimate: 336h > > Complete ACL implementation for 0-10 code path, providing an ACLv2 > implementation that covers the following features/requirements: > - Best practice security design > - Support for roles/groups > - Appropriate for standard stores for authorisation credentials (e.g. LDAP, > Kerberos) > - Expressable as XML > - Easy to store/backup/extract ACL config > - Exception handling catching at point of ACL application and return to > client via Connection ExceptionListener with correct error code, log failure > in broker > - No significant performance cost on publish, permissions to be cached > - Security handled at correct level of abstraction internally > - Interoperability with existing ACLv2 -- 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] Updated: (QPID-2418) Existing durable subscription with selector is not unsubscribed during change to new subscription
[ https://issues.apache.org/jira/browse/QPID-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2418: - Attachment: (was: 0001-QPID-2418-trunk.patch) > Existing durable subscription with selector is not unsubscribed during > change to new subscription > -- > > Key: QPID-2418 > URL: https://issues.apache.org/jira/browse/QPID-2418 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: M4, 0.5, 0.6 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.7 > > > AMQSession.createDurableSubscriber(topic, name, messageSelector, noLocal) > does not unsubscribe existing durable subscriptions. Whilst it does check for > existing durable subscriptions in use by the client with the same name, it > instead simply closes the subscriptions then creates a new one. As a result > of not unsubscribing, the queue backing the subscription is not deleted > before being used by the updated subscription as it should be (and as happens > in the 0_8 and 0_10 subclasses when using durable subscriptions without > selectors). -- 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] Updated: (QPID-2418) Existing durable subscription with selector is not unsubscribed during change to new subscription
[ https://issues.apache.org/jira/browse/QPID-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2418: - Attachment: (was: 0001-QPID-2418-branch.patch) > Existing durable subscription with selector is not unsubscribed during > change to new subscription > -- > > Key: QPID-2418 > URL: https://issues.apache.org/jira/browse/QPID-2418 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: M4, 0.5, 0.6 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.7 > > Attachments: 0001-QPID-2418-trunk.patch > > > AMQSession.createDurableSubscriber(topic, name, messageSelector, noLocal) > does not unsubscribe existing durable subscriptions. Whilst it does check for > existing durable subscriptions in use by the client with the same name, it > instead simply closes the subscriptions then creates a new one. As a result > of not unsubscribing, the queue backing the subscription is not deleted > before being used by the updated subscription as it should be (and as happens > in the 0_8 and 0_10 subclasses when using durable subscriptions without > selectors). -- 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] Commented: (QPID-2418) Existing durable subscription with selector is not unsubscribed during change to new subscription
[
https://issues.apache.org/jira/browse/QPID-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851830#action_12851830
]
Robbie Gemmell commented on QPID-2418:
--
On line 1086 (after patching) this code segment needs updated:
if (_subscriptionTopics.containsKey(name) &&
_subscriptionSelectors.containsKey(name))
{
if (!_subscriptionTopics.get(name).equals(topic) ||
!_subscriptionSelectors.get(name).equals(messageSelector))
{
_logger.info("Unsubscribing from topic " + topic + " with
subscription exchange " + name
+ " and selector " + messageSelector);
unsubscribe(name);
}
}
If the subscription name has been seen before but used without a selector, then
in the outer if statement the first test will success but the second will fail,
causing the inner if statement to detect subscription change not to be
evaluated. However, if the new subscription with reused name happens to be
adding a selector then this should be classified as a selector change (from no
selector) and cause unsubscription before proceeding.
Also, there is possibility of deadlock when creation of a new durable
subscriber occurs with the same subscription name as an existing open
subscriber, which will cause unsubscribe+closure of the old subscriber. The
create method will hold the new lock added, but closing the subscription will
contact the broker, which will reply and then a different thread will execute
the returned BasicCancelOK method and try to aquire the lock in
deregisterConsumer() in order to complete the closure, causing the first thread
executing the close to timeout and throw an exception. Looking at the map
usages it seems there is actually no need to acquire the same lock in
deregisterConsumer(), only a need to govern access to the subscriptions and
reverseSubscriptionMaps, which could be achieved using a second lock that
doesnt encompass the subscriber.close() operation.
> Existing durable subscription with selector is not unsubscribed during
> change to new subscription
> --
>
> Key: QPID-2418
> URL: https://issues.apache.org/jira/browse/QPID-2418
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Affects Versions: M4, 0.5, 0.6
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.7
>
> Attachments: 0001-QPID-2418-branch.patch, 0001-QPID-2418-trunk.patch
>
>
> AMQSession.createDurableSubscriber(topic, name, messageSelector, noLocal)
> does not unsubscribe existing durable subscriptions. Whilst it does check for
> existing durable subscriptions in use by the client with the same name, it
> instead simply closes the subscriptions then creates a new one. As a result
> of not unsubscribing, the queue backing the subscription is not deleted
> before being used by the updated subscription as it should be (and as happens
> in the 0_8 and 0_10 subclasses when using durable subscriptions without
> selectors).
--
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] Updated: (QPID-2477) std::cout in agent not used anymore
[ https://issues.apache.org/jira/browse/QPID-2477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Sarenik updated QPID-2477: -- Description: See attached one-liner. It removes the obsolete line. (All cout calls were removed from C++ agent in r727265) was: See attached patch. It removes the obsolete line. (All cout calls were removed from C++ agent in r727265) > std::cout in agent not used anymore > --- > > Key: QPID-2477 > URL: https://issues.apache.org/jira/browse/QPID-2477 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: 0.7 > Environment: Fedora Rawhide, Linux 2.6.34 x86_64, ... not important > here >Reporter: Jan Sarenik >Priority: Trivial > Fix For: 0.7 > > Attachments: qpid-agent-cout.diff > > > See attached one-liner. It removes the obsolete line. > (All cout calls were removed from C++ agent in r727265) -- 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] Updated: (QPID-2477) std::cout in agent not used anymore
[ https://issues.apache.org/jira/browse/QPID-2477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Sarenik updated QPID-2477: -- Attachment: qpid-agent-cout.diff > std::cout in agent not used anymore > --- > > Key: QPID-2477 > URL: https://issues.apache.org/jira/browse/QPID-2477 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: 0.7 > Environment: Fedora Rawhide, Linux 2.6.34 x86_64, ... not important > here >Reporter: Jan Sarenik >Priority: Trivial > Fix For: 0.7 > > Attachments: qpid-agent-cout.diff > > > See attached patch. It removes the obsolete line. > (All cout calls were removed from C++ agent in r727265) -- 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] Created: (QPID-2477) std::cout in agent not used anymore
std::cout in agent not used anymore --- Key: QPID-2477 URL: https://issues.apache.org/jira/browse/QPID-2477 Project: Qpid Issue Type: Improvement Components: C++ Broker Affects Versions: 0.7 Environment: Fedora Rawhide, Linux 2.6.34 x86_64, ... not important here Reporter: Jan Sarenik Priority: Trivial Fix For: 0.7 Attachments: qpid-agent-cout.diff See attached patch. It removes the obsolete line. (All cout calls were removed from C++ agent in r727265) -- 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] Commented: (QPID-2360) declaring virtualhost level firewall configuration in virtualhosts.xml leads to NPE on startup
[ https://issues.apache.org/jira/browse/QPID-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851798#action_12851798 ] Robbie Gemmell commented on QPID-2360: -- Patches were commited in revisions 929136 and 929138. The commit log statement was incorrect at the time, but has since been updated with the correct issue numbers. > declaring virtualhost level firewall configuration in virtualhosts.xml leads > to NPE on startup > -- > > Key: QPID-2360 > URL: https://issues.apache.org/jira/browse/QPID-2360 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.6 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.7 > > Attachments: 0001-QPID-2630-QPID-2631-branch.patch, > 0001-QPID-2630-QPID-2631-trunk.patch > > > Declaring virtualhost level firewall configuration in virtualhosts.xml leads > to NPE on startup. > After moving the same configuration into config.xml the broker then loads ok > and the configuration works as expected. -- 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] Updated: (QPID-2418) Existing durable subscription with selector is not unsubscribed during change to new subscription
[ https://issues.apache.org/jira/browse/QPID-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2418: - Attachment: 0001-QPID-2418-trunk.patch 0001-QPID-2418-branch.patch > Existing durable subscription with selector is not unsubscribed during > change to new subscription > -- > > Key: QPID-2418 > URL: https://issues.apache.org/jira/browse/QPID-2418 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: M4, 0.5, 0.6 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.7 > > Attachments: 0001-QPID-2418-branch.patch, 0001-QPID-2418-trunk.patch > > > AMQSession.createDurableSubscriber(topic, name, messageSelector, noLocal) > does not unsubscribe existing durable subscriptions. Whilst it does check for > existing durable subscriptions in use by the client with the same name, it > instead simply closes the subscriptions then creates a new one. As a result > of not unsubscribing, the queue backing the subscription is not deleted > before being used by the updated subscription as it should be (and as happens > in the 0_8 and 0_10 subclasses when using durable subscriptions without > selectors). -- 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] Updated: (QPID-2418) Existing durable subscription with selector is not unsubscribed during change to new subscription
[ https://issues.apache.org/jira/browse/QPID-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2418: - Attachment: (was: 0001-QPID-2418-trunk.patch) > Existing durable subscription with selector is not unsubscribed during > change to new subscription > -- > > Key: QPID-2418 > URL: https://issues.apache.org/jira/browse/QPID-2418 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: M4, 0.5, 0.6 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.7 > > > AMQSession.createDurableSubscriber(topic, name, messageSelector, noLocal) > does not unsubscribe existing durable subscriptions. Whilst it does check for > existing durable subscriptions in use by the client with the same name, it > instead simply closes the subscriptions then creates a new one. As a result > of not unsubscribing, the queue backing the subscription is not deleted > before being used by the updated subscription as it should be (and as happens > in the 0_8 and 0_10 subclasses when using durable subscriptions without > selectors). -- 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] Commented: (QPID-2473) current libraries: new options needed to link with
[ https://issues.apache.org/jira/browse/QPID-2473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851784#action_12851784 ] Jan Sarenik commented on QPID-2473: --- Building with CMake does not help either... [ 79%] Built target ssl [ 79%] Built target sslconnector [ 80%] Built target watchdog [ 80%] Building CXX object src/CMakeFiles/xml.dir/qpid/xml/XmlExchange.o /var/tmp/jasan/qpid-20100330/cpp/src/qpid/xml/XmlExchange.cpp: In member function 'bool qpid::broker::XmlExchange::matches(boost::shared_ptr&, qpid::broker::Deliverable&, const qpid::framing::FieldTable*, bool)': /var/tmp/jasan/qpid-20100330/cpp/src/qpid/xml/XmlExchange.cpp:192: error: 'class ResultImpl' has no member named 'getEffectiveBooleanValue' make[2]: *** [src/CMakeFiles/xml.dir/qpid/xml/XmlExchange.o] Error 1 make[1]: *** [src/CMakeFiles/xml.dir/all] Error 2 make: *** [all] Error 2 cmake-2.8.1-0.2.rc5.fc14.x86_64 xqilla-devel-2.2.3-7.fc14.x86_64 xerces-c-devel-3.0.1-16.fc13.x86_64 > current libraries: new options needed to link with > -- > > Key: QPID-2473 > URL: https://issues.apache.org/jira/browse/QPID-2473 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.7 > Environment: Linux slanina.virtual 2.6.34-0.16.rc2.git0.fc14.x86_64 > #1 SMP Tue Mar 23 02:02:52 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux > fedora-release-14-0.4.noarch (Rawhide x86_64) > glibc-2.11.90-16.x86_64 > gcc-4.4.3-13.fc14.x86_64 > gcc-c++-4.4.3-13.fc14.x86_64 > boost-1.41.0-7.fc13.x86_64 >Reporter: Jan Sarenik >Assignee: Gordon Sim > Attachments: qpid-rawhide.diff > > > The little attached patch is vital to make current trunk > (r928701) compile on Fedora Rawhide with Boost 1.41.0. > The other line adds libpthread linking option. It works > but you may want to add it elsewhere if you choose > to do so. -- 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] Commented: (QPID-2473) current libraries: new options needed to link with
[ https://issues.apache.org/jira/browse/QPID-2473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851785#action_12851785 ] Jan Sarenik commented on QPID-2473: --- And when I uninstall xqilla and xerces, I am getting this: [ 99%] Building CXX object src/tests/CMakeFiles/cluster_test.dir/PartialFailure.o Linking CXX executable unit_test [100%] Building CXX object src/tests/CMakeFiles/cluster_test.dir/ClusterFailover.o [100%] Built target unit_test [100%] Building CXX object src/tests/CMakeFiles/cluster_test.dir/InitialStatusMap.o [100%] Building CXX object src/tests/CMakeFiles/cluster_test.dir/StoreStatus.o Linking CXX executable cluster_test /usr/bin/ld: CMakeFiles/cluster_test.dir/StoreStatus.o: undefined reference to symbol 'boost::system::get_system_category()' /usr/bin/ld: note: 'boost::system::get_system_category()' is defined in DSO /usr/lib64/libboost_system-mt.so.1.41.0 so try adding it to the linker command line /usr/lib64/libboost_system-mt.so.1.41.0: could not read symbols: Invalid operation collect2: ld returned 1 exit status make[2]: *** [src/tests/cluster_test] Error 1 make[1]: *** [src/tests/CMakeFiles/cluster_test.dir/all] Error 2 make: *** [all] Error 2 > current libraries: new options needed to link with > -- > > Key: QPID-2473 > URL: https://issues.apache.org/jira/browse/QPID-2473 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.7 > Environment: Linux slanina.virtual 2.6.34-0.16.rc2.git0.fc14.x86_64 > #1 SMP Tue Mar 23 02:02:52 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux > fedora-release-14-0.4.noarch (Rawhide x86_64) > glibc-2.11.90-16.x86_64 > gcc-4.4.3-13.fc14.x86_64 > gcc-c++-4.4.3-13.fc14.x86_64 > boost-1.41.0-7.fc13.x86_64 >Reporter: Jan Sarenik >Assignee: Gordon Sim > Attachments: qpid-rawhide.diff > > > The little attached patch is vital to make current trunk > (r928701) compile on Fedora Rawhide with Boost 1.41.0. > The other line adds libpthread linking option. It works > but you may want to add it elsewhere if you choose > to do so. -- 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] Created: (QPID-2476) Complete ACL implementation for 0-10 code path
Complete ACL implementation for 0-10 code path -- Key: QPID-2476 URL: https://issues.apache.org/jira/browse/QPID-2476 Project: Qpid Issue Type: New Feature Components: Java Broker Affects Versions: 0.7 Reporter: Andrew Kennedy Fix For: 0.7 Complete ACL implementation for 0-10 code path, providing an ACLv2 implementation that covers the following features/requirements: - Best practice security design - Support for roles/groups - Appropriate for standard stores for authorisation credentials (e.g. LDAP, Kerberos) - Expressable as XML - Easy to store/backup/extract ACL config - Exception handling catching at point of ACL application and return to client via Connection ExceptionListener with correct error code, log failure in broker - No significant performance cost on publish, permissions to be cached - Security handled at correct level of abstraction internally - Interoperability with existing ACLv2 -- 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
