Alan Conway wrote:
On 03/01/2010 11:45 PM, Rafael Schloming wrote:
Gordon Sim wrote:
On 02/26/2010 03:09 PM, Alan Conway wrote:
On 02/26/2010 09:47 AM, Gordon Sim wrote:
On 02/26/2010 02:29 PM, Alan Conway wrote:
Gordon/Rafi: this raises an interesting question for the new APIs. It
seems lik
On 03/01/2010 11:45 PM, Rafael Schloming wrote:
Gordon Sim wrote:
On 02/26/2010 03:09 PM, Alan Conway wrote:
On 02/26/2010 09:47 AM, Gordon Sim wrote:
On 02/26/2010 02:29 PM, Alan Conway wrote:
Gordon/Rafi: this raises an interesting question for the new APIs. It
seems like async declare/bind
Gordon Sim wrote:
On 02/26/2010 03:09 PM, Alan Conway wrote:
On 02/26/2010 09:47 AM, Gordon Sim wrote:
On 02/26/2010 02:29 PM, Alan Conway wrote:
Gordon/Rafi: this raises an interesting question for the new APIs. It
seems like async declare/bind/subscribe are important features for
cases
lik
your help.
Regards,
Dave
-Original Message-
From: Gordon Sim [mailto:g...@redhat.com]
Sent: 26 February 2010 13:57
To: David Stewart
Cc: dev@qpid.apache.org; us...@qpid.apache.org
Subject: Re: SubscriptionManager performance problem.
On 02/26/2010 10:13 AM, David Stewart wrote:
> The ses
On 02/26/2010 03:09 PM, Alan Conway wrote:
On 02/26/2010 09:47 AM, Gordon Sim wrote:
On 02/26/2010 02:29 PM, Alan Conway wrote:
Gordon/Rafi: this raises an interesting question for the new APIs. It
seems like async declare/bind/subscribe are important features for cases
like this.
I agree, th
On 02/26/2010 09:47 AM, Gordon Sim wrote:
On 02/26/2010 02:29 PM, Alan Conway wrote:
Gordon/Rafi: this raises an interesting question for the new APIs. It
seems like async declare/bind/subscribe are important features for cases
like this.
I agree, this is an interesting case. On the face of it
On 02/26/2010 02:29 PM, Alan Conway wrote:
Gordon/Rafi: this raises an interesting question for the new APIs. It
seems like async declare/bind/subscribe are important features for cases
like this.
I agree, this is an interesting case. On the face of it my initial
suggestion would be a single r
On 02/26/2010 08:56 AM, Gordon Sim wrote:
On 02/26/2010 10:13 AM, David Stewart wrote:
The session was synchronous. Using the AsyncSession brought the 75
seconds down to 5-10 which is a fantastic improvement.
The bottleneck still appears to be the SessionManager though.
SessionManager::subscri
On 02/26/2010 05:13 AM, David Stewart wrote:
The session was synchronous. Using the AsyncSession brought the 75 seconds down
to 5-10 which is a fantastic improvement.
The bottleneck still appears to be the SessionManager though.
I should mention that we're running a vc90 C++ client against a vc
]
Sent: 25 February 2010 17:39
To: dev@qpid.apache.org
Cc: David Stewart; us...@qpid.apache.org
Subject: Re: SubscriptionManager performance problem.
On 02/25/2010 04:51 PM, David Stewart wrote:
Hi all,
we are running a bridge between our old middleware and qpid system which at
startup queries th
lto:g...@redhat.com]
Sent: 25 February 2010 17:39
To: dev@qpid.apache.org
Cc: David Stewart; us...@qpid.apache.org
Subject: Re: SubscriptionManager performance problem.
On 02/25/2010 04:51 PM, David Stewart wrote:
Hi all,
we are running a bridge between our old middleware and qpid system whi
e the problem?
Should I see better performance from a linux broker?
-Original Message-
From: Gordon Sim [mailto:g...@redhat.com]
Sent: 25 February 2010 17:39
To: dev@qpid.apache.org
Cc: David Stewart; us...@qpid.apache.org
Subject: Re: SubscriptionManager performance problem.
On 02/25/2010 04:
On 02/25/2010 11:51 AM, David Stewart wrote:
Hi all,
we are running a bridge between our old middleware and qpid system which at
startup queries the existing middleware for the number of broadcast groups it
knows about. It is a pricing system so there are ~2.
The bridge creates a fanout ex
On 02/25/2010 04:51 PM, David Stewart wrote:
Hi all,
we are running a bridge between our old middleware and qpid system which at
startup queries the existing middleware for the number of broadcast groups it
knows about. It is a pricing system so there are ~2.
The bridge creates a fanout ex
I should have mentioned this is in the C++ API for qpid 0.5,
Sorry,
Dave
-Original Message-
From: David Stewart
Sent: 25 February 2010 16:51
To: dev@qpid.apache.org
Cc: us...@qpid.apache.org
Subject: SubscriptionManager performance problem.
Hi all,
we are running a bridge between our old
Hi all,
we are running a bridge between our old middleware and qpid system which at
startup queries the existing middleware for the number of broadcast groups it
knows about. It is a pricing system so there are ~2.
The bridge creates a fanout exchange for each broadcast group, creates a queu
16 matches
Mail list logo
