[jira] Commented: (QPID-1956) FailoverExchangeMethod getNextBrokerDetails() loops infinitely after a total cluster failure or if the inital connect node is down

[Rajith Attapattu (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758107#action_12758107
 ] 

Rajith Attapattu commented on QPID-1956:


A fix for this is committed at rev 817487 on qpid trunk.
I will leave the JIRA open until I added a test case for this.

> FailoverExchangeMethod getNextBrokerDetails() loops infinitely after a total 
> cluster failure or if the inital connect node is down
> --
>
> Key: QPID-1956
> URL: https://issues.apache.org/jira/browse/QPID-1956
> Project: Qpid
>  Issue Type: Bug
>Affects Versions: 0.6
>Reporter: Rajith Attapattu
>Assignee: Rajith Attapattu
> Fix For: M4
>
>
> FailoverExchangeMethod getNextBrokerDetails() loops infinitely after a total 
> cluster failure or if the inital node (given in the URL) is down.

-- 
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] Issue Comment Edited: (QPID-1766) Implemention of selector using Xquery

[chenta lee (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758105#action_12758105
 ] 

chenta lee edited comment on QPID-1766 at 9/21/09 8:08 PM:
---

I forgot to add the header files before creating the new patch.

Actually I didn't use any new algorithm, I just follow the original algorithm 
(the one before apply the selector patch), and change a little implemetation 
detail. So I think it won't be a problem.
What do you mean by wrap-around the sequence number? It will be helpful if you 
could provide an example.

If I update the position property of consumer, it will be troublesome to 
requeue the message. 

  was (Author: chenta):
I forgot the add the header files before creating the new patch.

Actually I didn't use any new algorithm, I just follow the original algorithm 
(the one before apply the selector patch), and change a little implemetation 
detail. So I think it won't be a problem.
What do you mean by wrap-around the sequence number? It will be helpful if you 
could provide an example.

If I update the position property of consumer, it will be troublesome to 
requeue the message. 
  
> Implemention of selector using Xquery
> -
>
> Key: QPID-1766
> URL: https://issues.apache.org/jira/browse/QPID-1766
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Broker, C++ Client
> Environment: Linux
>Reporter: chenta lee
> Attachments: chenta.diff, Makefile.patch, Makefile.patch, 
> message_selector_pytest.patch, prime_number.diff, selector.diff, 
> selector.diff, selector.patch, selector.patch, selector_broker.patch, 
> selector_client.patch, selector_client.patch, selector_example.zip, 
> selector_new.diff, selector_patch_20090922.diff, selector_pytest.diff
>
>
> I implemented the message selector for C++ broker and client using Xquery.
> I will attach an example later.

-- 
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-1766) Implemention of selector using Xquery

[chenta lee (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenta lee updated QPID-1766:
-

Attachment: selector_patch_20090922.diff

I forgot the add the header files before creating the new patch.

Actually I didn't use any new algorithm, I just follow the original algorithm 
(the one before apply the selector patch), and change a little implemetation 
detail. So I think it won't be a problem.
What do you mean by wrap-around the sequence number? It will be helpful if you 
could provide an example.

If I update the position property of consumer, it will be troublesome to 
requeue the message. 

> Implemention of selector using Xquery
> -
>
> Key: QPID-1766
> URL: https://issues.apache.org/jira/browse/QPID-1766
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Broker, C++ Client
> Environment: Linux
>Reporter: chenta lee
> Attachments: chenta.diff, Makefile.patch, Makefile.patch, 
> message_selector_pytest.patch, prime_number.diff, selector.diff, 
> selector.diff, selector.patch, selector.patch, selector_broker.patch, 
> selector_client.patch, selector_client.patch, selector_example.zip, 
> selector_new.diff, selector_patch_20090922.diff, selector_pytest.diff
>
>
> I implemented the message selector for C++ broker and client using Xquery.
> I will attach an example later.

-- 
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: Fwd: Requesting a project proposal for an Undergraduate 12 week project proposal

[Cliff Jansen (Interop Systems Inc)]

Hi Ishara,

> Hi Carl,
> Thanks a lot for your reply.I,m interested to contribute to the C# client.

That would be great.  I would be happy to give you any help to get
started.

Carl Trieloff wrote:
> - Cliff from Microsoft has submitted a C# client over the C++ client. 

This client is written in both C# (pure managed) and C++/CLI (mixed
mode), so the language choice may influence which tasks are attractive
to you.

>From qpid/wcf/ReadMe.txt:

  2. Planned features (not yet available)
  ===

  1.  Full AMQP type support, including maps and arrays
  2.  System.Transactions integration (local and distributed with dynamic 
escalation)
  3.  Prefetch window for inbound messages
  4.  Shared sessions
  5.  Connection failover with AMQP broker clusters
  6.  Temporary queues
  7.  Broker management
  8.  System logging and tracing
  9.  CMake build system support
  10. Transport and message based security

Carl's suggestion regarding QMF is a good one.  It requires #1 as a
prerequisite, but the two together should leave plenty of room for GUI
flourishes too.  It would be 90% C# and 10% C++/CLI (with simple
boiler plate mixed mode needs).

#4 is essentially straight forward, but exposes some of the nuanced
differences between AMQP and WCF.  Combined with #8 and some NUnit
tests, this could also be a reasonable selection (99% C#).

Broker management (#7), is a broader topic than QMF.  If you have an
interest in PowerShell programming or Management Console snap-ins,
there are additional options to look at in this area.

Brief notes about the others: #3 is already complete (QPID-2110).  #2
should have a first cut ready in a week or so, and I am also actively
working on #6.  #5 requires that you have access to a Linux cluster of
brokers.  #9 is all about build scripts and compiler/linker options.
#10 which is largely about completing missing bits in the native C++
client on Windows (SSL and SASL).

Cliff

-Original Message-
From: ishara karunarathna [mailto:isharaar...@gmail.com] 
Sent: Monday, September 21, 2009 9:06 AM
To: dev@qpid.apache.org; cctriel...@redhat.com
Subject: Re: Fwd: Requesting a project proposal for an Undergraduate 12 week 
project proposal

Hi Carl,
Thanks a lot for your reply.I,m interested to contribute to the C# client.
As I'm new to Apache Qpid I haven't proper idea on that, so can you suggest
me where I can find more information on that.

Regards
Ishara



>

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Resolved: (QPID-2114) The JMS Client does not default to the correct priority as specified in the spec

[Rajith Attapattu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajith Attapattu resolved QPID-2114.


Resolution: Fixed

A fixed has been committed to rev 817478 on qpid trunk.
I have also added a simple check for the default message priority in an 
existing test in JMSPropertiesTest.

> The JMS Client does not default to the correct priority as specified in the 
> spec
> 
>
> Key: QPID-2114
> URL: https://issues.apache.org/jira/browse/QPID-2114
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Affects Versions: 0.6
>Reporter: Rajith Attapattu
>Assignee: Rajith Attapattu
>Priority: Minor
> Fix For: 0.6
>
>
> The JMS Client does not default to the correct priority as specified in the 
> spec. 
> Currently it defaults to 0, but should be 4 (Message.DEFAULT_PRIORITY)

-- 
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-2114) The JMS Client does not default to the correct priority as specified in the spec

[Rajith Attapattu (JIRA)]

The JMS Client does not default to the correct priority as specified in the spec


 Key: QPID-2114
 URL: https://issues.apache.org/jira/browse/QPID-2114
 Project: Qpid
  Issue Type: Bug
  Components: Java Client
Affects Versions: 0.6
Reporter: Rajith Attapattu
Assignee: Rajith Attapattu
Priority: Minor
 Fix For: 0.6


The JMS Client does not default to the correct priority as specified in the 
spec. 
Currently it defaults to 0, but should be 4 (Message.DEFAULT_PRIORITY)


-- 
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] Resolved: (QPID-2113) JMS client's default logging level should be WARN not DEBUG

[Rajith Attapattu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajith Attapattu resolved QPID-2113.


Resolution: Fixed

A log4j.xml file for the client module was added in rev 817457 on qpid trunk.

I didn't meddle with the existing log4j.properties file present in the common 
module as it maybe used in the broker.
However a cursory glance at the etc directory revealed that the the broker too 
has a log4j.xml file.
So perhaps the log4j.properties files in the common module is not really needed.

(The settings given i the log4j.xml under the client module could be overridden 
by explicitly specifying a log4.xml file using -Dlog.configuration property)


> JMS client's default logging level should be WARN not DEBUG
> ---
>
> Key: QPID-2113
> URL: https://issues.apache.org/jira/browse/QPID-2113
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Affects Versions: 0.6
>Reporter: Rajith Attapattu
>Assignee: Rajith Attapattu
> Fix For: 0.6
>
>
> The way log4j works is as follows. 
> It will try to look for log4j.xml within the classpath.
> Failing which it will try to look for log4j.properties within the classpath.
> In our qpid-common-xx.jar we have a log4j.properties and the log level is 
> configured as follows.
> log4j.logger.org.apache.qpid=${amqj.logging.level}, console
> So unless the system property "amqj.logging.level" is set, it will default to 
> DEBUG. (log4j unfortunately defaults to DEBUG instead of WARN).
> This causes an issue as out of the box performance for the JMS client is slow 
> due to the excessive logging.

-- 
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-2113) JMS client's default logging level should be WARN not DEBUG

[Rajith Attapattu (JIRA)]

JMS client's default logging level should be WARN not DEBUG
---

 Key: QPID-2113
 URL: https://issues.apache.org/jira/browse/QPID-2113
 Project: Qpid
  Issue Type: Bug
  Components: Java Client
Affects Versions: 0.6
Reporter: Rajith Attapattu
Assignee: Rajith Attapattu
 Fix For: 0.6


The way log4j works is as follows. 
It will try to look for log4j.xml within the classpath.
Failing which it will try to look for log4j.properties within the classpath.

In our qpid-common-xx.jar we have a log4j.properties and the log level is 
configured as follows.

log4j.logger.org.apache.qpid=${amqj.logging.level}, console

So unless the system property "amqj.logging.level" is set, it will default to 
DEBUG. (log4j unfortunately defaults to DEBUG instead of WARN).

This causes an issue as out of the box performance for the JMS client is slow 
due to the excessive logging.

-- 
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

[FYI] Found project - JavaScript bindings for AMQP 0-10 (Kamaloka-js)

[Kim van der Riet]

Here is an interesting implementation of AMQP 0-10 in JavaScript. It
is called Kamaloka-js.

http://www.j5live.com/2009/09/03/introducing-kamaloka-js-amqp-javascript-bindings/

--- Begin Message ---
http://www.j5live.com/2009/09/03/introducing-kamaloka-js-amqp-javascript-bindings/


--- End Message ---

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: Fwd: Requesting a project proposal for an Undergraduate 12 week project proposal

[Carl Trieloff]

ishara karunarathna wrote:

Hi Carl,
Thanks a lot for your reply.I,m interested to contribute to the C# client.
As I'm new to Apache Qpid I haven't proper idea on that, so can you suggest
me where I can find more information on that.

Regards
Ishara



  

  


From *QPID-2065 *

These are the areas Cliff has marked that need work. The port of the C# 
QMF to new WCF is item 7. If you want to do this
one I can point you to it. tross can also do so. I'm sure that Cliff 
would not mind if you helped pick up any other item on the

list below also if you wanted.


2. Planned features (not yet available) --- for C# client.
===

1.  Full AMQP type support, including maps and arrays
2.  System.Transactions integration (local and distributed with dynamic 
escalation)

3.  Prefetch window for inbound messages
4.  Shared sessions
5.  Connection failover with AMQP broker clusters
6.  Temporary queues
7.  Broker management
8.  System logging and tracing
9.  CMake build system support
10. Transport and message based security


Cliff, please jump in...

regards
Carl.

Re: svn commit: r813825 [1/2] - in /qpid/trunk/qpid/cpp/src: ./ qpid/broker/ qpid/sys/ qpid/xml/ tests/

[Gordon Sim]

On 09/21/2009 08:24 PM, Kim van der Riet wrote:

On Mon, 2009-09-21 at 16:39 +0100, Gordon Sim wrote:

On 09/17/2009 06:21 PM, Gordon Sim wrote:

I don't mind how many Jiras we use to track the issues. I have created
two already, but don't mind if those get augmented or replaced,
providing we make the problems being solved clear.


Carl, Kim,

I have attached a candidate fix to QPID-2102 that also address
QPID-2101. Have a look and let me know what you think. If we are all
happy with this, I can commit it. Else we can keep seeking something
agreeable to all.

--Gordon


The code looks good.

One question, however:

I do not see isPersistent() in PersisbableMessage - this will be needed
for setting the transient flag correctly when enqueuing on the store.
Did you handle it another way (by casting, for example)?


I did not make that change. It sounds like a separate issue?

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: svn commit: r813825 [1/2] - in /qpid/trunk/qpid/cpp/src: ./ qpid/broker/ qpid/sys/ qpid/xml/ tests/

[Kim van der Riet]

On Mon, 2009-09-21 at 16:39 +0100, Gordon Sim wrote:
> On 09/17/2009 06:21 PM, Gordon Sim wrote:
> > I don't mind how many Jiras we use to track the issues. I have created
> > two already, but don't mind if those get augmented or replaced,
> > providing we make the problems being solved clear.
> 
> Carl, Kim,
> 
> I have attached a candidate fix to QPID-2102 that also address 
> QPID-2101. Have a look and let me know what you think. If we are all 
> happy with this, I can commit it. Else we can keep seeking something 
> agreeable to all.
> 
> --Gordon
> 
The code looks good.

One question, however:

I do not see isPersistent() in PersisbableMessage - this will be needed
for setting the transient flag correctly when enqueuing on the store.
Did you handle it another way (by casting, for example)?

I'll make a separate checkin of the exchange route() refactorisation
from the previous (subsequently rolled out) checkin 813825, which is a
helpful change, but it is no longer needed for this issue.

Kim


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Updated: (QPID-2112) C++ Client: Facility needed for app to extract the user-ID in use for a connection

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-2112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated QPID-2112:
---

Attachment: QPID-2112.patch

This patch implements the proposal.  Note that a hook has been provided for 
Windows (but not tested).


> C++ Client:  Facility needed for app to extract the user-ID in use for a 
> connection
> ---
>
> Key: QPID-2112
> URL: https://issues.apache.org/jira/browse/QPID-2112
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Client
>Affects Versions: 0.5
>Reporter: Ted Ross
>Priority: Minor
> Fix For: 0.6
>
> Attachments: QPID-2112.patch
>
>
> When using GSSAPI as the authentication mechanism, the client application 
> does not know the identity used for an AMQP connection.  This is because the 
> SASL library automatically gets the identity from a keytab file and uses it 
> to authenticate with the broker.
> If the application wishes to place the userID into the message properties for 
> a produced message, it needs to be able to get the information from 
> somewhere.  I propose that the information be copied into the "negotiated 
> settings" for a connection at the completion of the authentication exchange.  
> Then, the client can get the identity string be calling 
> "getNegotiatedSettings" on the connection.  This change does not affect the 
> API or ABI of the interface.  It only enhances the meaning of the "username" 
> field in negotiated settings.

-- 
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-2112) C++ Client: Facility needed for app to extract the user-ID in use for a connection

[Ted Ross (JIRA)]

C++ Client:  Facility needed for app to extract the user-ID in use for a 
connection
---

 Key: QPID-2112
 URL: https://issues.apache.org/jira/browse/QPID-2112
 Project: Qpid
  Issue Type: Improvement
  Components: C++ Client
Affects Versions: 0.5
Reporter: Ted Ross
Priority: Minor
 Fix For: 0.6


When using GSSAPI as the authentication mechanism, the client application does 
not know the identity used for an AMQP connection.  This is because the SASL 
library automatically gets the identity from a keytab file and uses it to 
authenticate with the broker.

If the application wishes to place the userID into the message properties for a 
produced message, it needs to be able to get the information from somewhere.  I 
propose that the information be copied into the "negotiated settings" for a 
connection at the completion of the authentication exchange.  Then, the client 
can get the identity string be calling "getNegotiatedSettings" on the 
connection.  This change does not affect the API or ABI of the interface.  It 
only enhances the meaning of the "username" field in negotiated settings.


-- 
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-1766) Implemention of selector using Xquery

[Gordon Sim (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12757977#action_12757977
 ] 

Gordon Sim commented on QPID-1766:
--

SelectorModule.h does not appear to be part of the latest patch. 

The use of a sequence number assigned from the position of the consumer that 
never gets updated for the consume case will be a problem for wrap-around of 
the sequence number I think.

> Implemention of selector using Xquery
> -
>
> Key: QPID-1766
> URL: https://issues.apache.org/jira/browse/QPID-1766
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Broker, C++ Client
> Environment: Linux
>Reporter: chenta lee
> Attachments: chenta.diff, Makefile.patch, Makefile.patch, 
> message_selector_pytest.patch, prime_number.diff, selector.diff, 
> selector.diff, selector.patch, selector.patch, selector_broker.patch, 
> selector_client.patch, selector_client.patch, selector_example.zip, 
> selector_new.diff, selector_pytest.diff
>
>
> I implemented the message selector for C++ broker and client using Xquery.
> I will attach an example later.

-- 
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: [QPID-1871] Java Client Dispatcher change proposal.

[Rafael Schloming]

Martin Ritchie wrote:

Hi Rafi,

I saw the syncDispatchQueue method but I don't think waiting for the
_queue to clear is not the right solution, IMO, for rollback, even on
0-10. When rollback is called you don't want the dispatcher to process
any more messages. Your client may have MessageListeners setup that
will take a long time to process, so the Dispatcher should stop
processing messages and perform the Rollback.

I've attached a new test for RollbackOrderTest that blocks because the
syncDispatchQueue waits for the Dispatcher to empty the _queue.
However, when called via the MessageListener.onMessage(), you end up
blocking the Dispatcher.


That's a good point, however won't this also be an issue in the design 
you're proposing? Regardless of which thread actually does the rollback 
processing, rollback needs to block until that processing is complete, 
and if you're waiting for the "ServiceRequest" to be processed from the 
thread that is supposed to process it then you have essentially the same 
deadlock you've attached below.



I think extracting the Dispatcher will make it clearer to show that
the message processing varies in each protocol and will allow the
Session classes to focus on the creation and control of
Consumer/Producers. This will allow Dispatchers for each protocol to
be cleaner and highlight the protocol differences at failover; A 0-8
Dispatcher that simply drops all pending messages compared to the 0-10
Dispatcher that attempts to process all the messages it has received.


I don't actually think any of this needs to be (or should be) protocol 
specific. AFAICT there's no relevant difference in the protocol 
semantics here, these issues are common to any protocol that does 
prefetch. For example, the choice of whether to drop or process pending 
messages in a given scenario could be made either way for any protocol 
version.



I think it is a significant change but I think it is worth it as it
will improve the readability of the Client code as well as improving
the testability. Currently AMQSession is not exactly easy to unit test
so splitting it in to more discrete components and unit testing them
will be beneficial.

The change boils down to:
- Extract Dispatcher Logic to Dispatcher_0_8 , Dispatcher_0_10
- Update AMQSession to use new Dispatcher
- Update Dispatcher to be able to stop processing the _queue of
messages and perform rollback.


I agree the client is badly in need of some improvements in 
maintainability and readability, however in this particular case I don't 
think moving the rollback processing from one thread to another actually 
improves the situation significantly. Fundamentally the rollback logic 
needs to be performed from at least two different threads, the 
dispatcher thread and the application thread. I suspect in order do this 
properly we really need to stop thinking in terms of code being 
associated with a given thread, and think instead about what locks we 
have, what data structures those locks protect, and which locks need to 
be held in order to execute a given piece of code.


In my experience the number one issue with the client is deadlocks and 
race conditions stemming from the large number of haphazardly defined 
locks/conditions that are littered throughout the client code. I think 
before we can safely and productively move large chunks of code around 
we really need to have some sort plan for documenting and simplifying 
the locking situation. Really we need to be able to articulate exactly 
what locks the client has, what data structure(s) each lock protects, 
and what order should be used to acquire multiple locks when necessary.


--Rafael

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: Fwd: Requesting a project proposal for an Undergraduate 12 week project proposal

[ishara karunarathna]

Hi Carl,
Thanks a lot for your reply.I,m interested to contribute to the C# client.
As I'm new to Apache Qpid I haven't proper idea on that, so can you suggest
me where I can find more information on that.

Regards
Ishara



>

[jira] Commented: (QPID-2111) SelectorTest is split into two and doesn't test runtime selector exceptions

[Martin Ritchie (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12757937#action_12757937
 ] 

Martin Ritchie commented on QPID-2111:
--

The java client does not behave in the same way when run with the CPP broker 
and java Broker. 
The java broker has server side filtering and closes the connection on the 
erroneous consume.
The cpp broker does no filtering but the client throws an exception that is 
never reported.

I don't think either are write. The consumer should not be penalised by the 
erroneous publisher, so the connection should stay open, but the client should 
receive an exception. Ideally the publisher should to but that is much harder!

> SelectorTest is split into two and doesn't test runtime selector exceptions
> ---
>
> Key: QPID-2111
> URL: https://issues.apache.org/jira/browse/QPID-2111
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Tests
>Affects Versions: 0.6
>Reporter: Aidan Skinner
>Assignee: Aidan Skinner
>Priority: Minor
> Fix For: 0.6
>
>
> SelectorTest exists in two places and only tests parse-time selector errors, 
> not if a runtime error occurs such as trying a mathmatical operation on a 
> string property. 

-- 
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: r813825 [1/2] - in /qpid/trunk/qpid/cpp/src: ./ qpid/broker/ qpid/sys/ qpid/xml/ tests/

[Gordon Sim]

On 09/17/2009 06:21 PM, Gordon Sim wrote:

I don't mind how many Jiras we use to track the issues. I have created
two already, but don't mind if those get augmented or replaced,
providing we make the problems being solved clear.


Carl, Kim,

I have attached a candidate fix to QPID-2102 that also address 
QPID-2101. Have a look and let me know what you think. If we are all 
happy with this, I can commit it. Else we can keep seeking something 
agreeable to all.


--Gordon

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Commented: (QPID-2101) flow-to-disk not handled correctly for persistent messages that are enqueued on both durable and non-durable queues

[Gordon Sim (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12757928#action_12757928
 ] 

Gordon Sim commented on QPID-2101:
--

See patch for QPID-2101 which addresses this issue also.

> flow-to-disk not handled correctly for persistent messages that are enqueued 
> on both durable and non-durable queues
> ---
>
> Key: QPID-2101
> URL: https://issues.apache.org/jira/browse/QPID-2101
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: 0.5
>Reporter: Gordon Sim
> Fix For: 0.6
>
>
> If a persistent message is published to an exchange that routes that message 
> to more than one queue, and if some of those queues are durable with 
> flow-to-disk as the active policy and some are not, then its possible that 
> the broker will release the content for the message due to exceeding the 
> limit configured for the flow to disk policy on one queue. This will mean 
> that delivery of the message from transient queues will fail as they are 
> unable to reload the content.

-- 
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-2102) Exceeding reject queue policy under a transaction causes broker crash

[Gordon Sim (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gordon Sim updated QPID-2102:
-

Attachment: QPID-2102.patch

Candidate fix, also addresses QPID-2101.

> Exceeding reject queue policy under a transaction causes broker crash 
> --
>
> Key: QPID-2102
> URL: https://issues.apache.org/jira/browse/QPID-2102
> Project: Qpid
>  Issue Type: Bug
>Affects Versions: 0.5
>Reporter: Gordon Sim
> Fix For: 0.6
>
> Attachments: QPID-2102.patch
>
>
> To reproduce:
> Start a broker.
> Use qpid-tool to create a queue with a reject policy and a count limit of 5.
> Enqueue 10 records under a single transaction to that queue.
> Prepare and commit the transaction.
> Broker crashes.

-- 
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-2102) Exceeding reject queue policy under a transaction causes broker crash

[Gordon Sim (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12757925#action_12757925
 ] 

Gordon Sim commented on QPID-2102:
--

Also, the policy check incorrectly comes after the enqueue on disk.

> Exceeding reject queue policy under a transaction causes broker crash 
> --
>
> Key: QPID-2102
> URL: https://issues.apache.org/jira/browse/QPID-2102
> Project: Qpid
>  Issue Type: Bug
>Affects Versions: 0.5
>Reporter: Gordon Sim
> Fix For: 0.6
>
>
> To reproduce:
> Start a broker.
> Use qpid-tool to create a queue with a reject policy and a count limit of 5.
> Enqueue 10 records under a single transaction to that queue.
> Prepare and commit the transaction.
> Broker crashes.

-- 
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: [QPID-1871] Java Client Dispatcher change proposal.

[Martin Ritchie]

2009/9/21 Rafael Schloming :
> Rafael Schloming wrote:
>>
>> Martin Ritchie wrote:
>>>
>>> Hi,
>>>
>>> Following on from looking at QPID-1871. I believe that there is quite
>>> a significant change required to ensure that the message order or
>>> rollback is maintained.
>>>
>>> I propose that we extract the Dispatcher from AMQSession, which will
>>> simplify our biggest class (3100+ lines!) and show clear
>>> responsibility for incoming message processing. This will simplify
>>> rollback as the Dispatcher thread can be given full responsibility for
>>> clearing up the state that it knows best. Rather than the current
>>> situation where the calling thread does some work on AMQSession whilst
>>> the Dispatcher is running/stopping, then calls the the Dispatcher code
>>> directly clean up the remainder. All this while the Dispatcher may be
>>> processing a message.
>>>
>>> Change design posted here:
>>>
>>> http://cwiki.apache.org/confluence/display/qpid/0.6+Java+Client+Dispatcher+Changes
>>>
>>> Comments on the investigation, implications and design welcome.
>>> I'll capture the details on the wiki so we don't lose track of comments
>>
>> Hey Martin,
>>
>> Sorry I didn't pick up on this earlier. We hit this issue a while back in
>> the 0-10 code path. That's why we added RollbackOrderTest, and that's why it
>> doesn't fail for 0-10 brokers. You should probably check out
>> AMQSession.syncDispatchQueue, this method pretty much solves the problem
>> you're describing. It will block until the dispatch queue is empty... or
>> more precisely it will block until everything that is currently in the
>> dispatch queue has been processed by the dispatcher thread, which if done
>> after stopping incoming message flow means it will block until the dispatch
>> queue is empty.
>>
>> This method is used in a few places in the 0-10 codepath where it is
>> necessary to clean out the dispatch queue prior to proceeding (e.g. during
>> failover), however the key place here is AMQSession_0_10.releaseForRollback.
>> If you look at this you'll notice that it is called before the release is
>> actually done. If AMQSession_0_8.releaseForRollback were to do the same, or
>> preferrably if we were to move the syncDispatchQueue call up to
>> AMQSession.java then I suspect this problem would go away without the need
>> for a large refactor.
>
> The other thing you may want to look at is the Dispatchable interface. This
> is how syncDispatchQueue works, and I believe it is a similar concept to the
> ServiceRequests that you mention.

Similar but the difference is that the ServiceRequest queue is
processed before any content in the main message delivery _queue.

Martin

> --Rafael
>
>
> -
> Apache Qpid - AMQP Messaging Implementation
> Project:  http://qpid.apache.org
> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>
>



-- 
Martin Ritchie

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: [QPID-1871] Java Client Dispatcher change proposal.

[Martin Ritchie]

2009/9/21 Rafael Schloming :
> Martin Ritchie wrote:
>>
>> Hi,
>>
>> Following on from looking at QPID-1871. I believe that there is quite
>> a significant change required to ensure that the message order or
>> rollback is maintained.
>>
>> I propose that we extract the Dispatcher from AMQSession, which will
>> simplify our biggest class (3100+ lines!) and show clear
>> responsibility for incoming message processing. This will simplify
>> rollback as the Dispatcher thread can be given full responsibility for
>> clearing up the state that it knows best. Rather than the current
>> situation where the calling thread does some work on AMQSession whilst
>> the Dispatcher is running/stopping, then calls the the Dispatcher code
>> directly clean up the remainder. All this while the Dispatcher may be
>> processing a message.
>>
>> Change design posted here:
>>
>> http://cwiki.apache.org/confluence/display/qpid/0.6+Java+Client+Dispatcher+Changes
>>
>> Comments on the investigation, implications and design welcome.
>> I'll capture the details on the wiki so we don't lose track of comments
>
> Hey Martin,
>
> Sorry I didn't pick up on this earlier. We hit this issue a while back in
> the 0-10 code path. That's why we added RollbackOrderTest, and that's why it
> doesn't fail for 0-10 brokers. You should probably check out
> AMQSession.syncDispatchQueue, this method pretty much solves the problem
> you're describing. It will block until the dispatch queue is empty... or
> more precisely it will block until everything that is currently in the
> dispatch queue has been processed by the dispatcher thread, which if done
> after stopping incoming message flow means it will block until the dispatch
> queue is empty.
>
> This method is used in a few places in the 0-10 codepath where it is
> necessary to clean out the dispatch queue prior to proceeding (e.g. during
> failover), however the key place here is AMQSession_0_10.releaseForRollback.
> If you look at this you'll notice that it is called before the release is
> actually done. If AMQSession_0_8.releaseForRollback were to do the same, or
> preferrably if we were to move the syncDispatchQueue call up to
> AMQSession.java then I suspect this problem would go away without the need
> for a large refactor.
>
> --Rafael

Hi Rafi,

I saw the syncDispatchQueue method but I don't think waiting for the
_queue to clear is not the right solution, IMO, for rollback, even on
0-10. When rollback is called you don't want the dispatcher to process
any more messages. Your client may have MessageListeners setup that
will take a long time to process, so the Dispatcher should stop
processing messages and perform the Rollback.

I've attached a new test for RollbackOrderTest that blocks because the
syncDispatchQueue waits for the Dispatcher to empty the _queue.
However, when called via the MessageListener.onMessage(), you end up
blocking the Dispatcher.

I can understand that you may wish to do the block for 0-10 Failover
as there may still be useful data in the _queue. Also with failover
you are guaranteed that it is not going to be the Dispatcher thread
that is calling syncDispatchQueue.

I think extracting the Dispatcher will make it clearer to show that
the message processing varies in each protocol and will allow the
Session classes to focus on the creation and control of
Consumer/Producers. This will allow Dispatchers for each protocol to
be cleaner and highlight the protocol differences at failover; A 0-8
Dispatcher that simply drops all pending messages compared to the 0-10
Dispatcher that attempts to process all the messages it has received.

I think it is a significant change but I think it is worth it as it
will improve the readability of the Client code as well as improving
the testability. Currently AMQSession is not exactly easy to unit test
so splitting it in to more discrete components and unit testing them
will be beneficial.

The change boils down to:
- Extract Dispatcher Logic to Dispatcher_0_8 , Dispatcher_0_10
- Update AMQSession to use new Dispatcher
- Update Dispatcher to be able to stop processing the _queue of
messages and perform rollback.


Cheers
Martin

-- 
Martin Ritchie
"Dispatcher-Channel-1" daemon prio=10 tid=0x083dc800 nid=0x2e65 waiting on 
condition [0x8e952000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0xb2000e78> (a 
java.util.concurrent.CountDownLatch$Sync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:905)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1217)
at java.util.concurrent.CountDownLatch.await(CountDown

Re: [QPID-1871] Java Client Dispatcher change proposal.

[Rafael Schloming]

Rafael Schloming wrote:

Martin Ritchie wrote:

Hi,

Following on from looking at QPID-1871. I believe that there is quite
a significant change required to ensure that the message order or
rollback is maintained.

I propose that we extract the Dispatcher from AMQSession, which will
simplify our biggest class (3100+ lines!) and show clear
responsibility for incoming message processing. This will simplify
rollback as the Dispatcher thread can be given full responsibility for
clearing up the state that it knows best. Rather than the current
situation where the calling thread does some work on AMQSession whilst
the Dispatcher is running/stopping, then calls the the Dispatcher code
directly clean up the remainder. All this while the Dispatcher may be
processing a message.

Change design posted here:
http://cwiki.apache.org/confluence/display/qpid/0.6+Java+Client+Dispatcher+Changes 



Comments on the investigation, implications and design welcome.
I'll capture the details on the wiki so we don't lose track of comments


Hey Martin,

Sorry I didn't pick up on this earlier. We hit this issue a while back 
in the 0-10 code path. That's why we added RollbackOrderTest, and that's 
why it doesn't fail for 0-10 brokers. You should probably check out 
AMQSession.syncDispatchQueue, this method pretty much solves the problem 
you're describing. It will block until the dispatch queue is empty... or 
more precisely it will block until everything that is currently in the 
dispatch queue has been processed by the dispatcher thread, which if 
done after stopping incoming message flow means it will block until the 
dispatch queue is empty.


This method is used in a few places in the 0-10 codepath where it is 
necessary to clean out the dispatch queue prior to proceeding (e.g. 
during failover), however the key place here is 
AMQSession_0_10.releaseForRollback. If you look at this you'll notice 
that it is called before the release is actually done. If 
AMQSession_0_8.releaseForRollback were to do the same, or preferrably if 
we were to move the syncDispatchQueue call up to AMQSession.java then I 
suspect this problem would go away without the need for a large refactor.


The other thing you may want to look at is the Dispatchable interface. 
This is how syncDispatchQueue works, and I believe it is a similar 
concept to the ServiceRequests that you mention.


--Rafael


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: [QPID-1871] Java Client Dispatcher change proposal.

[Rafael Schloming]

Martin Ritchie wrote:

Hi,

Following on from looking at QPID-1871. I believe that there is quite
a significant change required to ensure that the message order or
rollback is maintained.

I propose that we extract the Dispatcher from AMQSession, which will
simplify our biggest class (3100+ lines!) and show clear
responsibility for incoming message processing. This will simplify
rollback as the Dispatcher thread can be given full responsibility for
clearing up the state that it knows best. Rather than the current
situation where the calling thread does some work on AMQSession whilst
the Dispatcher is running/stopping, then calls the the Dispatcher code
directly clean up the remainder. All this while the Dispatcher may be
processing a message.

Change design posted here:
http://cwiki.apache.org/confluence/display/qpid/0.6+Java+Client+Dispatcher+Changes

Comments on the investigation, implications and design welcome.
I'll capture the details on the wiki so we don't lose track of comments


Hey Martin,

Sorry I didn't pick up on this earlier. We hit this issue a while back 
in the 0-10 code path. That's why we added RollbackOrderTest, and that's 
why it doesn't fail for 0-10 brokers. You should probably check out 
AMQSession.syncDispatchQueue, this method pretty much solves the problem 
you're describing. It will block until the dispatch queue is empty... or 
more precisely it will block until everything that is currently in the 
dispatch queue has been processed by the dispatcher thread, which if 
done after stopping incoming message flow means it will block until the 
dispatch queue is empty.


This method is used in a few places in the 0-10 codepath where it is 
necessary to clean out the dispatch queue prior to proceeding (e.g. 
during failover), however the key place here is 
AMQSession_0_10.releaseForRollback. If you look at this you'll notice 
that it is called before the release is actually done. If 
AMQSession_0_8.releaseForRollback were to do the same, or preferrably if 
we were to move the syncDispatchQueue call up to AMQSession.java then I 
suspect this problem would go away without the need for a large refactor.


--Rafael

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Updated: (QPID-1766) Implemention of selector using Xquery

[chenta lee (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenta lee updated QPID-1766:
-

Attachment: prime_number.diff

Here is an example that use selector to get the prime number between 1~100


> Implemention of selector using Xquery
> -
>
> Key: QPID-1766
> URL: https://issues.apache.org/jira/browse/QPID-1766
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Broker, C++ Client
> Environment: Linux
>Reporter: chenta lee
> Attachments: chenta.diff, Makefile.patch, Makefile.patch, 
> message_selector_pytest.patch, prime_number.diff, selector.diff, 
> selector.diff, selector.patch, selector.patch, selector_broker.patch, 
> selector_client.patch, selector_client.patch, selector_example.zip, 
> selector_new.diff, selector_pytest.diff
>
>
> I implemented the message selector for C++ broker and client using Xquery.
> I will attach an example later.

-- 
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

[QPID-1871] Java Client Dispatcher change proposal.

[Martin Ritchie]

Hi,

Following on from looking at QPID-1871. I believe that there is quite
a significant change required to ensure that the message order or
rollback is maintained.

I propose that we extract the Dispatcher from AMQSession, which will
simplify our biggest class (3100+ lines!) and show clear
responsibility for incoming message processing. This will simplify
rollback as the Dispatcher thread can be given full responsibility for
clearing up the state that it knows best. Rather than the current
situation where the calling thread does some work on AMQSession whilst
the Dispatcher is running/stopping, then calls the the Dispatcher code
directly clean up the remainder. All this while the Dispatcher may be
processing a message.

Change design posted here:
http://cwiki.apache.org/confluence/display/qpid/0.6+Java+Client+Dispatcher+Changes

Comments on the investigation, implications and design welcome.
I'll capture the details on the wiki so we don't lose track of comments

Martin
-- 
Martin Ritchie

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Commented: (QPID-1871) During Rollback Client Rejects Message after sending TxRollback

[Martin Ritchie (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12757889#action_12757889
 ] 

Martin Ritchie commented on QPID-1871:
--

Change design posted here:
http://cwiki.apache.org/confluence/display/qpid/0.6+Java+Client+Dispatcher+Changes

> During Rollback Client Rejects Message after sending TxRollback
> ---
>
> Key: QPID-1871
> URL: https://issues.apache.org/jira/browse/QPID-1871
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker, Java Client
>Affects Versions: M4, 0.5
>Reporter: Martin Ritchie
>Assignee: Martin Ritchie
> Attachments: AckBug.txt, RollbackOrderTest.patch
>
>
> Summary:
> See QPID-1864 for annotated log output.
> The log output is from a run with the Java broker, but highlights that the 
> client dispatcher thread is not synchronized with the main thread during 
> rollback.
> As a result the main thread sends the TxRollback before the Dispatcher has 
> sent its Reject message. This results, on the java broker, in the unrejected 
> message being redelivered, which may be out of order depending on what other 
> messages have been released on the message queue.
> If we are to continue to rely on the dispatcher thread rejecting/releasing 
> the message it is currently processing (i.e. the message that is neither in 
> the _queue preDispatchQueue nor the _synchronousQueue for receiver delivery) 
> then we will need to synchronize with the main thread's rollback/recover 
> calls so that the dispatcher can finish processing its message before the 
> rollback/recover completes.
> The message that the Dispatcher thread has can be seen in AMQSession 
> L:2866:dispatchMessage(). 
> On Rollback we stop the dispatcher (L2763) which can result in the dispatcher 
> thread stopping on L2877 and holding on the the message it is in the middle 
> of delivery. More likely during recover the dispatcher will block on the lock 
> L2870.
> When the dispatcher is restarted (L2792) it is then free to reject its 
> message. However, the thread that restarted the dispatcher's next call is to 
> send the rollback command(L1553) Which is where the race condition occurs.
> Potential Fix:
> Message Rejection should be performed BEFORE we stop the dispatcher.
> On L:2825 we remove the message from the _queue (preDispatchQueue) and then 
> potentailly sit on the message L:2877 when we get stopped.
> If the reject call in L:2888 was before the wait then we could reject the 
> message rather than sit on it.
> Note: Now that I look at this a bit more the rollback (L2754) code looks to 
> be over synchronized. I'm not sure the dispatcher will actually ever stop on 
> the wait L2877 during rollback as the dispatcher is stopped and started again 
> inside the one syncronisation which would prevent the dispatcher getting to 
> the wait. So will more likely block on the sync L2870
> Moving the setConnectionStopped calls out of the sync block along and 
> ensuring that the _rollbackMark is updated before the connection is stopped 
> then we should ok.

-- 
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: RollbackOrderTest and CPP broker

[Martin Ritchie]

2009/9/18 Gordon Sim :
> On 09/18/2009 04:58 PM, Martin Ritchie wrote:
>>
>> Hi CPP broker devs,
>>
>> I'm just looking at the RollbackOrderTest and wondered what the CPP
>> broker will do if the client attempts to release a range of
>> deliveryTags that the broker no longer has?
>
> It will ignore the request for any id in the ranges specified that does not
> correspond to a known delivery.

Ok that is what the current java broker does but I think it is masking
an ordering issue, at least with the Java broker.

The Java broker keeps a list of unacked messages which have been sent
to a consumer, which, when rejected are returned to the main queue for
consumption. When the TxRollback is recevied the contents of the
unacked queue are resent before the contents of the main queue. This
means that all rejects must be sent before the TxRollback or the
contents of the unacked queue will jump ahead of the main queue.

How does the CPP broker maintain the list of messages sent to the client?

I haven't yet had time to write a test using AMQP frames that
simulates the race condition but it is possible for the java client
dispatcher to reject a single message after the TxRollback is sent.
For the Java broker this means a message (also most likey not the
front message on the queue) will be held by the dispatcher whilst the
session rollback is performed.

When the rollback is complete the dispatcher then rejects the message
it is holding. Problem is the Java broker ignores this as the message
that was to be rejected has already been resent to the client. The
problem is the message was resent before any of the messages from the
main queue, which may be out of order.

My re-reading of the JMS Spec suggests that this might actually be ok,
as the message is marked redelivered. However, it doesn't seem right
to me given that we can actually perform in order delivery on
rollback.

Just wondered if you have ever seen a failure of RollbackOrderTest.
The test doesn't send very many messages so the Dispatcher thread may
actually get to process all the messages before the rollback is
initiated. I noticed that this test is actually disabled against the
Java broker, so the test has been 'passing' for ages.

Cheers

Martin

>> In the Java broker the releases are done as BasicRejects in the 08/09
>> code path and the broker currently only logs out warning if it does
>> not have a record of the delivery tag.
>>
>> I was wondering if the CPP broker does anything similar, mainly so I
>> can see if the issue that I've seen (QPID-1871) affects the 0-10 code
>> path. I feel it should but I don't know enough about how the CPP
>> broker works to make that call.
>>
>> Cheers
>>
>> Martin
>
>
> -
> Apache Qpid - AMQP Messaging Implementation
> Project:  http://qpid.apache.org
> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>
>



-- 
Martin Ritchie

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Updated: (QPID-1119) [Java] Timeout on consumer creation with large queues

[Martin Ritchie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martin Ritchie updated QPID-1119:
-

Fix Version/s: (was: M4)
   M3

> [Java] Timeout on consumer creation with large queues
> -
>
> Key: QPID-1119
> URL: https://issues.apache.org/jira/browse/QPID-1119
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Affects Versions: M2.1
>Reporter: Marnie McCormack
>Assignee: Aidan Skinner
> Fix For: M3
>
>
> We've seen consumer timeout ("Error registering consumer: 
> org.apache.qpid.AMQTimeoutException: Server did not respond in a timely 
> fashion"). This was seen with volume testing, and 45,000 messages in the 
> queue the consumer was attempting to connect to.
> The issue there is that for every subscription request it needs to go over 
> the whole queue, to work out which messages should go to which subscriber. 
> The broker runs with number of threads == number of cores, so if you have 
> lots of consumers they will queue up behind one another to get processed. One 
> solution is to stagger the consumer starts on the appication side, but we can 
> also expose the connection timeout for configuration so that applications can 
> use this.
> Thus need to create a configurable timeout for sync responses. Rob Godfrey 
> can advise if further info required.

-- 
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-1119) [Java] Timeout on consumer creation with large queues

[Martin Ritchie (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12757858#action_12757858
 ] 

Martin Ritchie commented on QPID-1119:
--

FAQ Entry
http://cwiki.apache.org/confluence/display/qpid/Qpid+Java+FAQ#QpidJavaFAQ-Clientkeepsthrowing%27Serverdidnotrespondinatimelyfashion%27.

> [Java] Timeout on consumer creation with large queues
> -
>
> Key: QPID-1119
> URL: https://issues.apache.org/jira/browse/QPID-1119
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Affects Versions: M2.1
>Reporter: Marnie McCormack
>Assignee: Aidan Skinner
> Fix For: M4
>
>
> We've seen consumer timeout ("Error registering consumer: 
> org.apache.qpid.AMQTimeoutException: Server did not respond in a timely 
> fashion"). This was seen with volume testing, and 45,000 messages in the 
> queue the consumer was attempting to connect to.
> The issue there is that for every subscription request it needs to go over 
> the whole queue, to work out which messages should go to which subscriber. 
> The broker runs with number of threads == number of cores, so if you have 
> lots of consumers they will queue up behind one another to get processed. One 
> solution is to stagger the consumer starts on the appication side, but we can 
> also expose the connection timeout for configuration so that applications can 
> use this.
> Thus need to create a configurable timeout for sync responses. Rob Godfrey 
> can advise if further info required.

-- 
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