Hi Steve,
Need your help in this regard.
When we stop the message bus and restart it, it shows as started, but when we
check other components which access this message bus, it fails.
We tried to clear the files from the data folder and then restarted it, it
worked fine. I don't understand, wh
Setting the TCP_NODELAY default to ON makes sense. +1
Instant turn around of short request/response messages makes
the product look better out-of-the-box. Robbie's 5x story is
compelling.
-Chuck
- Original Message -
> From: "Robbie Gemmell"
> To: dev@qpid.apache.org
> Sent: Tuesday, Nov
I think it works both ways. Is it better to offer the ultimate default
out the box performance in a narrow set of uses cases but suck at
everything else (which is what we appear to have now), or deliver
great out the box performance across the wider set and possibly merely
'good' performance in the
[
https://issues.apache.org/jira/browse/QPID-3579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146507#comment-13146507
]
jirapos...@reviews.apache.org commented on QPID-3579:
-
---
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2675/#review3115
---
Ship it!
Works well, nice and simple. Don't offhand have a use for it
TCP_NODELAY makes a considerable improvement in synchronous cases
(sync pub, sync ack etc) and small tx cases and we generally recommend
that as a tuning option to our users/customers.
The reason for making TCP_NODELAY false by default is based on the
assumption that in most cases people will want
[
https://issues.apache.org/jira/browse/QPID-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146473#comment-13146473
]
Andrew Stitcher commented on QPID-3464:
---
@Jose Pedro Olveira
I'm planning to apply t
[
https://issues.apache.org/jira/browse/QPID-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146464#comment-13146464
]
Justin Ross commented on QPID-3586:
---
Approved for the 0.14 release branch.
[
https://issues.apache.org/jira/browse/QPID-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146461#comment-13146461
]
Chuck Rolke commented on QPID-3586:
---
Approved.
> Changes for QPID-3464 b
Oh, I should have mentioned it also caused a rather noticable 35%+
reduction in the time taking to run the tests, going from 19min16sec
to 12min24sec for the default java-mms.0-10 profile, which in itself
is a good enough reason for me to want it regardless of any actual
user benefits ;)
On 8 Nove
We will take a look and see if there is anything we think worth
noting. In general I am strongly of the opinion that JIRA makes the
release notes though, and if you cant tell what you need from that
list then it is the JIRA itself which needs updated, not extra text
added to describe it.
Robbie
O
Hi all,
I was looking into some sluggish consumer creation performance with
the Java client for a posting on the user list, and eventually
narrowed the issue down to TCP_NODELAY being set false by default,
leading to ExecutionSyncs taking an extraordinary amount of time to
complete. This made ever
[
https://issues.apache.org/jira/browse/QPID-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146431#comment-13146431
]
Jose Pedro Oliveira commented on QPID-3464:
---
Andrew,
Would it be possible to als
[
https://issues.apache.org/jira/browse/QPID-3574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146425#comment-13146425
]
Jose Pedro Oliveira commented on QPID-3574:
---
The patch 04_reorganize-automake-qpi
JIRA:
https://issues.apache.org/jira/browse/QPID-3586
Fix:
http://svn.apache.org/viewvc?view=rev&rev=1198929
This is a bug that stops the 0.14 C++ cmake build from working; it is a
simple autotools(!) Makefile.am error.
I think the bug is important enough and the fix simple enough to be
applie
Hi Robbie (and co),
I noticed at least one behavioural changes that warrants a prominent
release note.
I've added a comment in QPID-3583 to cover the change of acking
behaviour for the AUTO_ACK case. See [1]
Could you guys help with some of the changes made in the failover side.
I'd let you folks
[
https://issues.apache.org/jira/browse/QPID-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146399#comment-13146399
]
Rajith Attapattu commented on QPID-3583:
We need to release note the following chan
[
https://issues.apache.org/jira/browse/QPID-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-3519:
-
Fix Version/s: 0.15
> Refactor the logic behind sending of the selector arguments during
> subscripti
[
https://issues.apache.org/jira/browse/QPID-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-3518:
-
Fix Version/s: 0.15
> Introduce client side ability to detect server side selector support presence
>
[
https://issues.apache.org/jira/browse/QPID-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-3518:
-
Fix Version/s: (was: 0.13)
> Introduce client side ability to detect server side selector support
20 matches
Mail list logo
