> On Fri, Feb 26, 2010 at 10:25 AM, Gordon Sim wrote:
> > On 02/23/2010 10:36 PM, Andrew Stitcher wrote:
> >>
> >> I've uploaded qpid-0.6rc6 and I think that we are ready for a vote
> >> immediately:
> >>
> >> Thanks to Rajith the files that were in violation of the
> Apache rules
> >> on licens
[
https://issues.apache.org/jira/browse/QPID-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross reassigned QPID-2411:
--
Assignee: Ted Ross
> Created Documentation for Writing a CPP QMF console application
> -
[
https://issues.apache.org/jira/browse/QPID-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved QPID-2423.
Resolution: Fixed
> Add Constructors to set initial value of content for MapContent and
> ListContent
> ---
Add Constructors to set initial value of content for MapContent and ListContent
---
Key: QPID-2423
URL: https://issues.apache.org/jira/browse/QPID-2423
Project: Qpid
On Fri, Feb 26, 2010 at 10:25 AM, Gordon Sim wrote:
> On 02/23/2010 10:36 PM, Andrew Stitcher wrote:
>>
>> I've uploaded qpid-0.6rc6 and I think that we are ready for a vote
>> immediately:
>>
>> Thanks to Rajith the files that were in violation of the Apache rules on
>> licenses now have license
Thanks Gordon. I'll fold your example into our code.
The only reaon we have a queue per exchange is that we can monitor queue
lengths for individual instruments in the event of delays on our pricing. If it
is optimal to have one queue per session then we can implement that.
Thanks for your help
On 02/23/2010 10:36 PM, Andrew Stitcher wrote:
I've uploaded qpid-0.6rc6 and I think that we are ready for a vote immediately:
Thanks to Rajith the files that were in violation of the Apache rules on
licenses now have license texts.
The only differences between rc6 and rc5 are non-functional, s
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
Thanks for the feedback from those that gave it. Lacking any further
input, I have gone ahead and completed an initial feature matrix
(http://cwiki.apache.org/confluence/display/qpid/0.6+Feature+Matrix)
and feature description list to which each item links
(http://cwiki.apache.org/confluence/dis
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
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
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::subscribe() is synchronous, which will impact the
On 02/25/2010 07:47 PM, a fabbri wrote:
If I may answer my own question--after some serious web searching:
To use RDMA with a qpid client such as latency test, set the
environment variable QPID_LOAD_MODULE=/path/to/rdmaconnector.so
I'll resist the temptation to email again to thank myself. ;-)
[
https://issues.apache.org/jira/browse/QPID-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kotrekhov updated QPID-1811:
---
Attachment: sasl.diff
patch to find saslpasswd2 in $PATH on file system.
Not all OS have saslp
If I may answer my own question--after some serious web searching:
To use RDMA with a qpid client such as latency test, set the
environment variable QPID_LOAD_MODULE=/path/to/rdmaconnector.so
I'll resist the temptation to email again to thank myself. ;-)
Aaron
On Thu, Feb 25, 2010 at 3:46 PM,
Hi,
I'm able to run the C++ broker w/ the RDMA transport by using the
--load-module option, e.g.:
qpidd --load-module rdma.so --transport rdma ...
Next I try to use latencytest with -P rdma, but it complains (as the
protocol is not registered).
How should I make latencytest load the transport m
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 vc90 C++
broker. Could the broker be the problem
20 matches
Mail list logo
