[jira] [Commented] (QPIDJMS-131) Provide for finer grained control over sending of messages as presettled.
[ https://issues.apache.org/jira/browse/QPIDJMS-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15264873#comment-15264873 ] ASF subversion and git services commented on QPIDJMS-131: - Commit bac662d540ab51e418ef2b328c56507d2f9f13cb in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=bac662d ] https://issues.apache.org/jira/browse/QPIDJMS-131 Initial pass of addition of JmsPresettlePolicy to allow finer control over presettlement in the JMS client. > Provide for finer grained control over sending of messages as presettled. > - > > Key: QPIDJMS-131 > URL: https://issues.apache.org/jira/browse/QPIDJMS-131 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.6.0 >Reporter: Timothy Bish > > Provider more options for when a message can be sent presettled or not. > Cases where it makes sense to allow for presettle sends are messages sent as > non-persistent or messages sent inside a transaction where the transaction > boundary can provide the sync point for batch send success or failure. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7231) Example of REST call to invoke the Queue clear queue operation in incorrect
[ https://issues.apache.org/jira/browse/QPID-7231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall resolved QPID-7231. -- Resolution: Fixed > Example of REST call to invoke the Queue clear queue operation in incorrect > --- > > Key: QPID-7231 > URL: https://issues.apache.org/jira/browse/QPID-7231 > Project: Qpid > Issue Type: Bug > Components: Documentation, Java Broker >Affects Versions: qpid-java-6.0.2 >Reporter: Michal Zerola >Priority: Trivial > Labels: documentation > Fix For: qpid-java-6.0.3, qpid-java-6.1 > > > Example of REST call to invoke the queue clear operation in Java Broker > Documentation at: > https://qpid.apache.org/releases/qpid-java-6.0.2/java-broker/book/Java-Broker-Management-Channel-REST-API.html#d0e2197 > is incorrect. It should not contain '../default/..' part of the path. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7231) Example of REST call to invoke the Queue clear queue operation in incorrect
[ https://issues.apache.org/jira/browse/QPID-7231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15264830#comment-15264830 ] ASF subversion and git services commented on QPID-7231: --- Commit 1741704 from [~k-wall] in branch 'java/branches/6.0.x' [ https://svn.apache.org/r1741704 ] QPID-7231: [Java Broker Documentation] Correct example illustrating invocation of operation using REST svn merge -c 1741702 ^/qpid/java/trunk > Example of REST call to invoke the Queue clear queue operation in incorrect > --- > > Key: QPID-7231 > URL: https://issues.apache.org/jira/browse/QPID-7231 > Project: Qpid > Issue Type: Bug > Components: Documentation, Java Broker >Affects Versions: qpid-java-6.0.2 >Reporter: Michal Zerola >Priority: Trivial > Labels: documentation > Fix For: qpid-java-6.0.3, qpid-java-6.1 > > > Example of REST call to invoke the queue clear operation in Java Broker > Documentation at: > https://qpid.apache.org/releases/qpid-java-6.0.2/java-broker/book/Java-Broker-Management-Channel-REST-API.html#d0e2197 > is incorrect. It should not contain '../default/..' part of the path. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7231) Example of REST call to invoke the Queue clear queue operation in incorrect
[ https://issues.apache.org/jira/browse/QPID-7231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15264819#comment-15264819 ] ASF subversion and git services commented on QPID-7231: --- Commit 1741702 from [~k-wall] in branch 'java/trunk' [ https://svn.apache.org/r1741702 ] QPID-7231: [Java Broker Documentation] Correct example illustrating invocation of operation using REST > Example of REST call to invoke the Queue clear queue operation in incorrect > --- > > Key: QPID-7231 > URL: https://issues.apache.org/jira/browse/QPID-7231 > Project: Qpid > Issue Type: Bug > Components: Documentation, Java Broker >Affects Versions: qpid-java-6.0.2 >Reporter: Michal Zerola >Priority: Trivial > Labels: documentation > Fix For: qpid-java-6.0.3, qpid-java-6.1 > > > Example of REST call to invoke the queue clear operation in Java Broker > Documentation at: > https://qpid.apache.org/releases/qpid-java-6.0.2/java-broker/book/Java-Broker-Management-Channel-REST-API.html#d0e2197 > is incorrect. It should not contain '../default/..' part of the path. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-287) Policy does not allow configuration for unspecified Open hostname
[ https://issues.apache.org/jira/browse/DISPATCH-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-287. -- Resolution: Fixed Fix Version/s: 0.6 Fixed at Commit 375c3ed Note that the proton subsystem handling of Open Hostname is a *moving target*. In the past an open to 'localhost:5672' set a hostname of '0.0.0.0:5672'. Now the same open generates a blank hostname. In the future, the rules may change. > Policy does not allow configuration for unspecified Open hostname > - > > Key: DISPATCH-287 > URL: https://issues.apache.org/jira/browse/DISPATCH-287 > Project: Qpid Dispatch > Issue Type: Bug > Components: Policy Engine >Affects Versions: 0.6 >Reporter: Chuck Rolke >Assignee: Chuck Rolke > Fix For: 0.6 > > > Currently if the hostname is blank when policy is in force then the > connection is automatically disallowed. An improvement in this case would be > to allow for some policy to be assigned. > Policy is normally assigned based on the incoming connection's > (username, client-host-ip, Open.hostname) tuple. This issue could be solved > by allowing for blank Open.hostname in the policy definitions and run time. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-287) Policy does not allow configuration for unspecified Open hostname
[ https://issues.apache.org/jira/browse/DISPATCH-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15264769#comment-15264769 ] ASF subversion and git services commented on DISPATCH-287: -- Commit 375c3edcda07c04ba24070037a415a455804404a in qpid-dispatch's branch refs/heads/master from [~chug] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=375c3ed ] DISPATCH-287: Allow blank application name. A blank application name is treated like any other. > Policy does not allow configuration for unspecified Open hostname > - > > Key: DISPATCH-287 > URL: https://issues.apache.org/jira/browse/DISPATCH-287 > Project: Qpid Dispatch > Issue Type: Bug > Components: Policy Engine >Affects Versions: 0.6 >Reporter: Chuck Rolke >Assignee: Chuck Rolke > > Currently if the hostname is blank when policy is in force then the > connection is automatically disallowed. An improvement in this case would be > to allow for some policy to be assigned. > Policy is normally assigned based on the incoming connection's > (username, client-host-ip, Open.hostname) tuple. This issue could be solved > by allowing for blank Open.hostname in the policy definitions and run time. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-299) After policy rejects a connection queued Begin causes a crash
[
https://issues.apache.org/jira/browse/DISPATCH-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke resolved DISPATCH-299.
--
Resolution: Fixed
Fix Version/s: 0.6
Fixed at Commit 0f5a359
> After policy rejects a connection queued Begin causes a crash
> -
>
> Key: DISPATCH-299
> URL: https://issues.apache.org/jira/browse/DISPATCH-299
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Policy Engine
>Affects Versions: 0.6
>Reporter: Chuck Rolke
> Fix For: 0.6
>
>
> Over the wire the router sees:
> {noformat}
> Wed Apr 27 16:07:23 2016 SERVER (trace) [1]:AMQP 1.0 layer detected
> Wed Apr 27 16:07:23 2016 SERVER (trace) [1]: <- AMQP
> Wed Apr 27 16:07:23 2016 SERVER (trace) [1]:0 <- @open(16)
> [container-id="B730345F-FCA9-4F05-9305-ACA2C04B55C9",
> hostname="172.28.128.5", channel-max=32767]
> Wed Apr 27 16:07:23 2016 SERVER (trace) [1]:0 <- @begin(17)
> [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=2147483647]
> Wed Apr 27 16:07:23 2016 SERVER (trace) [1]:0 <- @attach(18)
> [name="sender-xxx", handle=0, role=false, snd-settle-mode=2,
> rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false],
> target=@target(41) [durable=0, timeout=0, dynamic=false],
> initial-delivery-count=0]
> Wed Apr 27 16:07:23 2016 SERVER (trace) [1]: -> AMQP
> Wed Apr 27 16:07:23 2016 POLICY (info) DENY AMQP Open for user 'anonymous',
> host '172.28.128.1', application '172.28.128.5': User is not in a user group
> and default users are denied
> Wed Apr 27 16:07:23 2016 POLICY (trace) ALLOW AMQP Begin Session. user:
> anonymous, hostip: 172.28.128.1, app: 172.28.128.5
> Wed Apr 27 16:07:23 2016 POLICY (info) DENY AMQP Attach anonymous sender for
> user 'anonymous', host '172.28.128.1', app '172.28.128.5'
> {noformat}
> After policy has rejected the connection it is unprepared to process the
> Begin event and further events on the connection should be dropped.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-301) Some unit tests fail with workerThreads are set to 4
Ganesh Murthy created DISPATCH-301:
--
Summary: Some unit tests fail with workerThreads are set to 4
Key: DISPATCH-301
URL: https://issues.apache.org/jira/browse/DISPATCH-301
Project: Qpid Dispatch
Issue Type: Bug
Components: Container
Affects Versions: 0.6
Reporter: Ganesh Murthy
Python tests like system_tests_user_id and system_tests_qdstat fail when the
workerThreads are set to more than 1 (in my test case I had workerThreads set
to 4)
I see the following output -
{noformat}
[gmurthy@localhost build]$ PN_TRACE_FRM=1
"/home/gmurthy/opensource/dispatch/build/tests/run.py" "-m" "unittest" "-v"
"system_tests_user_id"
test_ssl_user_id (system_tests_user_id.QdSSLUseridTest) ... [0x55a742167ee0]:
-> SASL
[0x55a742167ee0]: <- SASL
[0x55a742167ee0]:0 <- @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:EXTERNAL]]
[0x55a742167ee0]:0 -> @sasl-init(65) [mechanism=:EXTERNAL, initial-response=b""]
[0x55a742167ee0]:0 <- @sasl-outcome(68) [code=0]
[0x55a742167ee0]: -> AMQP
[0x55a742167ee0]:0 -> @open(16)
[container-id="473eaeaf-c3af-43d9-91ed-f10b53b38084", channel-max=32767]
[0x55a742167ee0]: <- AMQP
[0x55a742167ee0]:0 <- @open(16) [container-id="QDR", max-frame-size=16384,
channel-max=32767, idle-time-out=6,
offered-capabilities=:"ANONYMOUS-RELAY",
properties={:product="qpid-dispatch-router", :version="0.6.0"}]
[0x55a742167ee0]:0 -> @begin(17) [next-outgoing-id=0,
incoming-window=2147483647, outgoing-window=2147483647]
[0x55a742167ee0]:0 -> @attach(18)
[name="473eaeaf-c3af-43d9-91ed-f10b53b38084-$management", handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0,
dynamic=false], target=@target(41) [address="$management", durable=0,
timeout=0, dynamic=false], initial-delivery-count=0]
[0x55a742167ee0]:0 -> @close(24) [error=@error(29)
[condition=:"amqp:connection:framing-error", description="SSL Failure: Unknown
error."]]
[0x55a742167ee0]: <- EOS
[0x55a742167ee0]: -> EOS
ERROR
==
ERROR: test_ssl_user_id (system_tests_user_id.QdSSLUseridTest)
--
Traceback (most recent call last):
File "/home/gmurthy/opensource/dispatch/tests/system_tests_user_id.py", line
220, in test_ssl_user_id
node = Node.connect(addr, ssl_domain=domain)
File
"/home/gmurthy/opensource/dispatch/python/qpid_dispatch/management/client.py",
line 98, in connect
return Node(Node.connection(url, router, timeout, ssl_domain))
File
"/home/gmurthy/opensource/dispatch/python/qpid_dispatch/management/client.py",
line 112, in __init__
self.client = SyncRequestResponse(connection, self.url.path)
File
"/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/utils.py",
line 321, in __init__
self.sender = self.connection.create_sender(self.address)
File
"/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/utils.py",
line 211, in create_sender
return BlockingSender(self, self.container.create_sender(self.conn,
address, name=name, handler=handler, options=options))
File
"/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/utils.py",
line 68, in __init__
super(BlockingSender, self).__init__(connection, sender)
File
"/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/utils.py",
line 32, in __init__
msg="Opening link %s" % link.name)
File
"/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/utils.py",
line 264, in wait
raise ConnectionException("Connection %s disconnected" % self.url)
ConnectionException: Connection amqps://0.0.0.0:27216/$management disconnected
--
Ran 1 test in 2.144s
FAILED (errors=1)
[gmurthy@localhost build]$
{noformat}
Switch the workerThreads back to 1 and the tests will pass
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1185) [proton-j] Send operations like SendLink.send() & RecvLink.flow() (aka writing to the transport stack) doesn't flush all bytes to the Network
[ https://issues.apache.org/jira/browse/PROTON-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sreeram Garlapati updated PROTON-1185: -- Summary: [proton-j] Send operations like SendLink.send() & RecvLink.flow() (aka writing to the transport stack) doesn't flush all bytes to the Network (was: [proton-j] writing to the transport stack doesn't flush all bytes to the Network) > [proton-j] Send operations like SendLink.send() & RecvLink.flow() (aka > writing to the transport stack) doesn't flush all bytes to the Network > - > > Key: PROTON-1185 > URL: https://issues.apache.org/jira/browse/PROTON-1185 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.12.2 > Environment: All >Reporter: Sreeram Garlapati > Labels: proton-j, send-stuck > Fix For: 0.13.0 > > > We are experiencing this issue intermittently - writing to Proton-j transport > stack doesn't flush bytes to the Network. The application remains in "stuck > state" - until more bytes are written to that Transport. > We are experiencing this in both these APIs - SenderImpl.send(...) and > ReceiverImpl.flow(...) - which under-the-covers writes bytes to Transport. We > can see our Traces where we are invoking these APIs - but at this point - the > Proton frames (set PN_TRACE_FRM=1) stops. > We use SSL transport and our Amqp layer is here: > https://github.com/Azure/azure-event-hubs/tree/master/java/azure-eventhubs/src/main/java/com/microsoft/azure/servicebus/amqp > Please let me know what exact information will be useful to diagnose this > issue. > This issue currently consistently repro's after Sending on 1 Link (on 1 > Session - 1 AmqpConnection) **for a long time**. While I am trying hard to > break this down to a simplest possible reproducer code - I filed the issue to > communicate ahead. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7230) Broker terminates the connection to JMS Client
[ https://issues.apache.org/jira/browse/QPID-7230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15264640#comment-15264640 ] Ben commented on QPID-7230: --- But why is it working with persistent messages and not with transient messages? Tomorrow I will try the scenario again, this time with configured queue size. > Broker terminates the connection to JMS Client > -- > > Key: QPID-7230 > URL: https://issues.apache.org/jira/browse/QPID-7230 > Project: Qpid > Issue Type: Bug > Components: C++ Broker, Java Client >Affects Versions: 0.32 > Environment: Fedora21 and C++ Broker installed by package manager >Reporter: Ben > Attachments: 200-a.log, 300-a.log > > > Following scenario: > One Producer and one Consumer created by a Java JMS-Client. The Producer is > sending 200x15mb non persistent messages to a queue. This queue is located on > a local running c++ broker. After few messages my broker terminates the > connection with the following exception. > javax.jms.JMSException: send not allowed after the sender is closed. > The really astonishing is, that this behavior only occurs with non persistent > messages. If I change the delivery mode to persistent, my broker won't close > the connection. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-992) Proton's use of Cyrus SASL is not thread-safe.
[
https://issues.apache.org/jira/browse/PROTON-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15264603#comment-15264603
]
michael goulish commented on PROTON-992:
Dispatch is not yet immune to this issue.
Also, I think Proton needs to let the application handle initialization and
shutdown of Cyrus SASL.
I made a test that brings up a 6-router network, and randomly kills and
restarts routers.
I get a router core, usually within 5 iterations, because of this issue.
Here is how I fixed it:
1. Let dispatch code call sasl_client_init() and sasl_server_init() at the
top of qd_server_run(). And remove these calls from Proton. In keeping these
calls to itself, Proton cannot prevent two threads from simultaneously getting
into sasl_*_init(). SegV City.
2. Prevent proton from calling sasl_{client,server}_done(), in
pni_sasl_impl_free(). Being thread-agnostic, Proton cannot possibly know when
it's safe to dispose of the sasl object, which is being used by many threads.
Both of those Cyrus calls affect global state by NULLing out a global pointer
that stores the mechanisms string.
With these changes, my test has now run to 400 iterations with no crash.
> Proton's use of Cyrus SASL is not thread-safe.
> --
>
> Key: PROTON-992
> URL: https://issues.apache.org/jira/browse/PROTON-992
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.10
>Reporter: michael goulish
>Assignee: Andrew Stitcher
>Priority: Critical
>
> Documentation for the Cyrus SASL library says that the library is believed to
> be thread-safe only if the code that uses it meets several requirements.
> The requirements are:
> * you supply mutex functions (see sasl_set_mutex())
> * you make no libsasl calls until sasl_client/server_init() completes
> * no libsasl calls are made after sasl_done() is begun
> * when using GSSAPI, you use a thread-safe GSS / Kerberos 5 library.
> It says explicitly that that sasl_set* calls are not thread safe, since they
> set global state.
> The proton library makes calls to sasl_set* functions in :
> pni_init_client()
> pni_init_server(), and
> pni_process_init()
> Since those are internal functions, there is no way for code that uses Proton
> to lock around those calls.
> I think proton needs a new API call to let applications call
> sasl_set_mutex(). Or something.
> We probably also need other protections to meet the other requirements
> specified in the Cyrus documentation (and quoted above).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7241) AMQP 1.0: large messages (>10MB) are very slow over AMQP 1.0
Gordon Sim created QPID-7241: Summary: AMQP 1.0: large messages (>10MB) are very slow over AMQP 1.0 Key: QPID-7241 URL: https://issues.apache.org/jira/browse/QPID-7241 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client Affects Versions: qpid-cpp-0.34 Reporter: Gordon Sim Assignee: Gordon Sim Looks like some bad interaction with the proton-c layer causing lots of memmoving. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7230) Broker terminates the connection to JMS Client
[
https://issues.apache.org/jira/browse/QPID-7230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15264403#comment-15264403
]
Gordon Sim commented on QPID-7230:
--
The original description sounds very much like it is a queue limit issue. I
modified the Sender example that comes with the qpid jms client to send 20k
messages. Running that against a broker with default config on my laptop gives:
{noformat}
[1569627428:1] -> Transfer{handle=0, deliveryId=6, deliveryTag=2,
messageFormat=0, settled=null, more=false, rcvSettleMode=null, state=null,
resume=false, aborted=false, batchable=false} (2140)
"\x00Sp\xc0\x02\x01B\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-typeQ\x05\x00Ss\xc0J\x0a\xa10ID::552ab624-9f10-4ce2-a9d0-11aa2508088b:1:1:1-7@\xa1\x05queue@@\x83\x00\x00\x01Tb\xe0\x03\xaa\x00Sw\xb1\x011-\x00xoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxoxo"...(truncated)
[1569627428:1] <- Detach{handle=0, closed=true,
error=Error{condition=amqp:precondition-failed,
description='resource-limit-exceeded: Maximum depth exceeded on queue:
current=[count: 5, size: 10700], max=[size: 104857600]
(/home/gordon/projects/qpid/qpid/cpp/src/qpid/broker/Queue.cpp:1633)',
info=null}}
[1569627428:1] -> Detach{handle=0, closed=true, error=null}
Caught exception, exiting.
javax.jms.JMSException: send not allowed after the sender is closed.
at
org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:66)
at
org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:88)
at org.apache.qpid.jms.JmsConnection.send(JmsConnection.java:632)
at org.apache.qpid.jms.JmsConnection.send(JmsConnection.java:616)
at
org.apache.qpid.jms.JmsNoTxTransactionContext.send(JmsNoTxTransactionContext.java:37)
at org.apache.qpid.jms.JmsSession.send(JmsSession.java:699)
at org.apache.qpid.jms.JmsSession.send(JmsSession.java:620)
at
org.apache.qpid.jms.JmsMessageProducer.sendMessage(JmsMessageProducer.java:172)
at
org.apache.qpid.jms.JmsMessageProducer.send(JmsMessageProducer.java:148)
at Sender.main(Sender.java:80)
Caused by: java.io.IOException: send not allowed after the sender is closed.
at
org.apache.qpid.jms.util.IOExceptionSupport.create(IOExceptionSupport.java:45)
at
org.apache.qpid.jms.provider.ProviderFuture.failOnError(ProviderFuture.java:108)
at
org.apache.qpid.jms.provider.ProviderFuture.sync(ProviderFuture.java:102)
at org.apache.qpid.jms.JmsConnection.send(JmsConnection.java:627)
... 7 more
Caused by: java.lang.IllegalStateException: send not allowed after the sender
is closed.
at
org.apache.qpid.proton.engine.impl.SenderImpl.send(SenderImpl.java:47)
at
org.apache.qpid.jms.provider.amqp.AmqpFixedProducer.encodeAndSend(AmqpFixedProducer.java:178)
at
org.apache.qpid.jms.provider.amqp.AmqpFixedProducer.doSend(AmqpFixedProducer.java:141)
at
org.apache.qpid.jms.provider.amqp.AmqpFixedProducer.send(AmqpFixedProducer.java:105)
at
org.apache.qpid.jms.provider.amqp.AmqpProvider$8.run(AmqpProvider.java:481)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
That said, the handling of large messages by the c++ broker is very slow over
AMQP 1.0. I'll raise a separate JIRA for that.
> Broker terminates the connection to JMS Client
> --
>
> Key: QPID-7230
> URL: https://issues.apache.org/jira/browse/QPID-7230
> P
[jira] [Commented] (PROTON-1183) C++ binding: make proton::terminus internal
[ https://issues.apache.org/jira/browse/PROTON-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15264321#comment-15264321 ] ASF subversion and git services commented on PROTON-1183: - Commit 07ab957ffe8918586ddc3f66ea1ef47606b6b077 in qpid-proton's branch refs/heads/master from Clifford Jansen [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=07ab957 ] PROTON-1183: clearer filter example > C++ binding: make proton::terminus internal > --- > > Key: PROTON-1183 > URL: https://issues.apache.org/jira/browse/PROTON-1183 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Affects Versions: 0.12.2 >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: 0.13.0 > > > Hide terminus from visible api surface. Add source and target replacement > calsses. create source_options and target_options for configuration and move > from sender/receiver configuration where appropriate. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7165) Allow query results to be sorted and paginated
[
https://issues.apache.org/jira/browse/QPID-7165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-7165:
-
Attachment: (was: QPID-7165-add-sorting-pagination.tar.gz)
> Allow query results to be sorted and paginated
> --
>
> Key: QPID-7165
> URL: https://issues.apache.org/jira/browse/QPID-7165
> Project: Qpid
> Issue Type: New Feature
> Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.1
>
> Attachments:
> 0001-QPID-7165-Java-Broker-Allow-query-results-to-be-sort.patch,
> 0001-QPID-7165-Java-Broker-Allow-query-results-to-be-sort.patch,
> 0002-QPID-7165-Java-Broker-Allow-query-results-to-be-sort.patch,
> 0002-QPID-7165-Java-Broker-Allow-query-results-to-be-sort.patch,
> 0004-WIP.patch
>
>
> Extend the mechanism provided by QPID-6969 to allow for the results set to be
> sorted by one or more columns and results set to be paginated.
> For the ordering clause, we could use SQL:2011 ORDER BY clause as a guide
> e.g. {{orderBy='x ASC,y DESC,z'}}
> For the pagination, SQL standardisation does not include it.
> https://en.wikipedia.org/wiki/Select_%28SQL%29#Result_limits We could opt for
> {{limit=}} {{offset=}} like MySQL/Sybase. We could also consider HTTP Range
> headers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-7165) Allow query results to be sorted and paginated
[
https://issues.apache.org/jira/browse/QPID-7165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy closed QPID-7165.
Resolution: Fixed
Assignee: (was: Lorenz Quack)
> Allow query results to be sorted and paginated
> --
>
> Key: QPID-7165
> URL: https://issues.apache.org/jira/browse/QPID-7165
> Project: Qpid
> Issue Type: New Feature
> Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.1
>
> Attachments:
> 0001-QPID-7165-Java-Broker-Allow-query-results-to-be-sort.patch,
> 0001-QPID-7165-Java-Broker-Allow-query-results-to-be-sort.patch,
> 0002-QPID-7165-Java-Broker-Allow-query-results-to-be-sort.patch,
> 0002-QPID-7165-Java-Broker-Allow-query-results-to-be-sort.patch,
> 0004-WIP.patch, QPID-7165-add-sorting-pagination.tar.gz
>
>
> Extend the mechanism provided by QPID-6969 to allow for the results set to be
> sorted by one or more columns and results set to be paginated.
> For the ordering clause, we could use SQL:2011 ORDER BY clause as a guide
> e.g. {{orderBy='x ASC,y DESC,z'}}
> For the pagination, SQL standardisation does not include it.
> https://en.wikipedia.org/wiki/Select_%28SQL%29#Result_limits We could opt for
> {{limit=}} {{offset=}} like MySQL/Sybase. We could also consider HTTP Range
> headers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7230) Broker terminates the connection to JMS Client
[
https://issues.apache.org/jira/browse/QPID-7230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15264263#comment-15264263
]
Gordon Sim commented on QPID-7230:
--
A simpler way to get the protocol trace in your case may be to do so on the
client. From the client doc:
{quote}
When debugging some issues, it may sometimes be useful to enable additional
protocol trace logging from the Qpid Proton AMQP 1.0 library. There are two
options to achieve this:
+ Set the environment variable (not Java system property) *PN_TRACE_FRM* to
*true*, which will cause Proton to emit frame logging to stdout.
+ Add the option *amqp.traceFrames=true* to your connection URI to have the
client add a protocol tracer to Proton, and configure the
*org.apache.qpid.jms.provider.amqp.FRAMES* Logger to *TRACE* level to include
the output in your logs.
{quote}
That would clearly show if the broker is detaching due to a queue limit.
> Broker terminates the connection to JMS Client
> --
>
> Key: QPID-7230
> URL: https://issues.apache.org/jira/browse/QPID-7230
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker, Java Client
>Affects Versions: 0.32
> Environment: Fedora21 and C++ Broker installed by package manager
>Reporter: Ben
> Attachments: 200-a.log, 300-a.log
>
>
> Following scenario:
> One Producer and one Consumer created by a Java JMS-Client. The Producer is
> sending 200x15mb non persistent messages to a queue. This queue is located on
> a local running c++ broker. After few messages my broker terminates the
> connection with the following exception.
> javax.jms.JMSException: send not allowed after the sender is closed.
> The really astonishing is, that this behavior only occurs with non persistent
> messages. If I change the delivery mode to persistent, my broker won't close
> the connection.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7240) acquired messages are not evicted from priority-ring queue
[ https://issues.apache.org/jira/browse/QPID-7240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved QPID-7240. -- Resolution: Fixed > acquired messages are not evicted from priority-ring queue > -- > > Key: QPID-7240 > URL: https://issues.apache.org/jira/browse/QPID-7240 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.28 >Reporter: Gordon Sim >Assignee: Gordon Sim > Fix For: qpid-cpp-next > > > If a priority queue with a ring queue limit policy exceeds the limit, the > lowest priority oldest message should be removed. However at present acquired > messages are not considered here. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7230) Broker terminates the connection to JMS Client
[ https://issues.apache.org/jira/browse/QPID-7230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15264202#comment-15264202 ] Gordon Sim commented on QPID-7230: -- The address in use error means there is another broker listening on that port. If you have root privileges you can shut down the qpidd service (e.g. sudo service qpidd stop) then start it in a console again (remember to restart the service is you need it afterwards). The c++ broker has a default maximum queue depth in bytes. If that is exceeded it will detach the sending link. If the sender continues to send on that same link after that, then the broker would close the connection. You can alter the limits per queue using qpid-config or the broker wide default using the default-queue-limit option either as a command line argument or through the conf file. The default conf file location depends on how the broker was built/packaged/installed. Often it is in /etc/qpid/qpidd.conf, you can see where it is on your system through the qpidd --help options. There should be an error logged on the broker if links are detached for hitting the limit. Large persistent messages are indeed slow with the c++ broker (I see 20MB messages taking about 1 second though, so not as slow as you are seeing). I have also observed that sending non-persistent messages over AMQP 1.0 is an order of magnitude slower than over AMQP 0-10 though that is with the c++ client and I haven't determined whether it is the client or the broker (or both!) at fault there. I haven't hit anything like the symptom you describe where the broker becomes very slow even for smaller messages. My guess there is that either the memory use is causing swapping or that perhaps the queue is flow controlled(?). I'll see if I can get a test client for the JMS client you are using. > Broker terminates the connection to JMS Client > -- > > Key: QPID-7230 > URL: https://issues.apache.org/jira/browse/QPID-7230 > Project: Qpid > Issue Type: Bug > Components: C++ Broker, Java Client >Affects Versions: 0.32 > Environment: Fedora21 and C++ Broker installed by package manager >Reporter: Ben > Attachments: 200-a.log, 300-a.log > > > Following scenario: > One Producer and one Consumer created by a Java JMS-Client. The Producer is > sending 200x15mb non persistent messages to a queue. This queue is located on > a local running c++ broker. After few messages my broker terminates the > connection with the following exception. > javax.jms.JMSException: send not allowed after the sender is closed. > The really astonishing is, that this behavior only occurs with non persistent > messages. If I change the delivery mode to persistent, my broker won't close > the connection. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (DISPATCH-244) SASL library generates un-necessary DNS and LDAP requests
[
https://issues.apache.org/jira/browse/DISPATCH-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway reopened DISPATCH-244:
--
This issue has been reported by other users and needs to be addressed.
> SASL library generates un-necessary DNS and LDAP requests
> -
>
> Key: DISPATCH-244
> URL: https://issues.apache.org/jira/browse/DISPATCH-244
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 0.5
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.6
>
>
> The dispatch system tests (e.g. system_tests_management) run very slowly when
> connected to a VPN.
> - about 10x slower on VPN configured to use TCP connection
> - about 5x slower on VPN configured for UDP connection
> Wireshark shows unexpected LDAP and DNS queries on the VPN interface.
> `wallace` below is the local host name, but is not mentioned in any tests so
> must be picked up by proton or dispatch at runtime:
> {code}
> 1 0.0 10.3.113.10810.11.6.1 LDAP242
> searchRequest(11) "dc=redhat,dc=com" wholeSubtree
> 2 0.035161000 10.3.113.10810.5.30.160 DNS 72
> Standard query 0xd03f A wallace.lab.bos.redhat.com
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7240) acquired messages are not evicted from priority-ring queue
[ https://issues.apache.org/jira/browse/QPID-7240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15264110#comment-15264110 ] ASF subversion and git services commented on QPID-7240: --- Commit 1741635 from [~gsim] in branch 'qpid/trunk' [ https://svn.apache.org/r1741635 ] QPID-7240: use protper cursor type when purging priority levels > acquired messages are not evicted from priority-ring queue > -- > > Key: QPID-7240 > URL: https://issues.apache.org/jira/browse/QPID-7240 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.28 >Reporter: Gordon Sim >Assignee: Gordon Sim > Fix For: qpid-cpp-next > > > If a priority queue with a ring queue limit policy exceeds the limit, the > lowest priority oldest message should be removed. However at present acquired > messages are not considered here. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7189) [Java Client 0-8..0-10] Client fails to negotiate AMQP connection after downgrading from 0-10 to 0-91
[
https://issues.apache.org/jira/browse/QPID-7189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7189:
-
Summary: [Java Client 0-8..0-10] Client fails to negotiate AMQP connection
after downgrading from 0-10 to 0-91 (was: [Java Client 0-8..0-10] Client fails
to create delegate for AMQP 0.9.1 in response to broker supported protocol
received during protocol negotiation)
> [Java Client 0-8..0-10] Client fails to negotiate AMQP connection after
> downgrading from 0-10 to 0-91
> -
>
> Key: QPID-7189
> URL: https://issues.apache.org/jira/browse/QPID-7189
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Affects Versions: 0.32, qpid-java-6.0, qpid-java-6.0.1
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-6.0.2, qpid-java-6.1
>
> Attachments:
> 0001-QPID-7189-Rename-connection-delegates-to-match-proto.patch
>
>
> If broker replies with AMQP 0.9.1 during protocol negotiation, the client is
> not able to create a delegate as it is looking for delegate using the code
> below:
> {code}
> String delegateClassName =
> String.format("org.apache.qpid.client.AMQConnectionDelegate_s_%s",
> pe.getMajorVersion(), pe.getMinorVersion());
> {code}
> There is no delegate AMQConnectionDelegate_0_91
> The client fails with exception as below:
> {noformat}
> Exception in thread "main" javax.jms.JMSException: Error creating connection:
> Protocol: 0.91 is rquired by the broker but is not currently supported by
> this client library implementation
> at
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:134)
> at
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:57)
> at org.apache.qpid.example.Hello.runTest(Hello.java:50)
> at org.apache.qpid.example.Hello.main(Hello.java:36)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> Caused by: org.apache.qpid.AMQProtocolException: Protocol: 0.91 is rquired by
> the broker but is not currently supported by this client library
> implementation [error code 543: client unsupported protocol]
> at
> org.apache.qpid.client.AMQConnection.initDelegate(AMQConnection.java:626)
> at
> org.apache.qpid.client.AMQConnection.makeConnection(AMQConnection.java:521)
> at org.apache.qpid.client.AMQConnection.(AMQConnection.java:474)
> at
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:130)
> ... 8 more
> Caused by: java.lang.ClassNotFoundException:
> org.apache.qpid.client.AMQConnectionDelegate_0_91
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at
> org.apache.qpid.client.AMQConnection.initDelegate(AMQConnection.java:616)
> ... 11 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7114) [Java Broker] ConnectionBuilder should set protocol and cipher suites on all code paths
[
https://issues.apache.org/jira/browse/QPID-7114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7114:
-
Affects Version/s: qpid-java-6.0.1
> [Java Broker] ConnectionBuilder should set protocol and cipher suites on all
> code paths
> ---
>
> Key: QPID-7114
> URL: https://issues.apache.org/jira/browse/QPID-7114
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0.1
>Reporter: Lorenz Quack
> Fix For: qpid-java-6.0.2, qpid-java-6.1
>
>
> The {{CustomisedSSLSocketFactory}} in {{ConnectionBuilder}} 5
> {{createSocket}} methods that should set the TLS protocols and cipher suites
> on the created socket. We somehow missed to do that on {{createSocket(Socket,
> String, int, boolean)}}
> On 6.0.1, this defect prevented the customisation of the TLS protocol and
> cypher suites used by the JMX connector.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7114) [Java Broker] ConnectionBuilder should set protocol and cipher suites on all code paths
[
https://issues.apache.org/jira/browse/QPID-7114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7114:
-
Description:
The {{CustomisedSSLSocketFactory}} in {{ConnectionBuilder}} 5 {{createSocket}}
methods that should set the TLS protocols and cipher suites on the created
socket. We somehow missed to do that on {{createSocket(Socket, String, int,
boolean)}}
On 6.0.1, this defect prevented the customisation of the TLS protocol and
cypher suites used by the JMX connector.
was:
The {{CustomisedSSLSocketFactory}} in {{ConnectionBuilder}} 5 {{createSocket}}
methods that should set the TLS protocols and cipher suites on the created
socket. We somehow missed to do that on {{createSocket(Socket, String, int,
boolean)}}
On 6.0.1, this defect prevented the customisation of the
> [Java Broker] ConnectionBuilder should set protocol and cipher suites on all
> code paths
> ---
>
> Key: QPID-7114
> URL: https://issues.apache.org/jira/browse/QPID-7114
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0.1
>Reporter: Lorenz Quack
> Fix For: qpid-java-6.0.2, qpid-java-6.1
>
>
> The {{CustomisedSSLSocketFactory}} in {{ConnectionBuilder}} 5
> {{createSocket}} methods that should set the TLS protocols and cipher suites
> on the created socket. We somehow missed to do that on {{createSocket(Socket,
> String, int, boolean)}}
> On 6.0.1, this defect prevented the customisation of the TLS protocol and
> cypher suites used by the JMX connector.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7114) [Java Broker] ConnectionBuilder should set protocol and cipher suites on all code paths
[
https://issues.apache.org/jira/browse/QPID-7114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7114:
-
Description:
The {{CustomisedSSLSocketFactory}} in {{ConnectionBuilder}} 5 {{createSocket}}
methods that should set the TLS protocols and cipher suites on the created
socket. We somehow missed to do that on {{createSocket(Socket, String, int,
boolean)}}
On 6.0.1, this defect prevented the customisation of the
was:The {{CustomisedSSLSocketFactory}} in {{ConnectionBuilder}} 5
{{createSocket}} methods that should set the TLS protocols and cipher suites on
the created socket. We somehow missed to do that on {{createSocket(Socket,
String, int, boolean)}}
> [Java Broker] ConnectionBuilder should set protocol and cipher suites on all
> code paths
> ---
>
> Key: QPID-7114
> URL: https://issues.apache.org/jira/browse/QPID-7114
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-6.0.2, qpid-java-6.1
>
>
> The {{CustomisedSSLSocketFactory}} in {{ConnectionBuilder}} 5
> {{createSocket}} methods that should set the TLS protocols and cipher suites
> on the created socket. We somehow missed to do that on {{createSocket(Socket,
> String, int, boolean)}}
> On 6.0.1, this defect prevented the customisation of the
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7240) acquired messages are not evicted from priority-ring queue
Gordon Sim created QPID-7240: Summary: acquired messages are not evicted from priority-ring queue Key: QPID-7240 URL: https://issues.apache.org/jira/browse/QPID-7240 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.28 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: qpid-cpp-next If a priority queue with a ring queue limit policy exceeds the limit, the lowest priority oldest message should be removed. However at present acquired messages are not considered here. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7207) Reorganize Qpid source for independent releases
[ https://issues.apache.org/jira/browse/QPID-7207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15263989#comment-15263989 ] ASF subversion and git services commented on QPID-7207: --- Commit 1741620 from [~justi9] in branch 'qpid/trunk' [ https://svn.apache.org/r1741620 ] QPID-7207: Remove a duplicate suppression and expand the applicability of another > Reorganize Qpid source for independent releases > --- > > Key: QPID-7207 > URL: https://issues.apache.org/jira/browse/QPID-7207 > Project: Qpid > Issue Type: Task >Reporter: Justin Ross >Assignee: Justin Ross > > An effort to achieve the source tree layout proposed here\[1\]. It allows the > Qpid project to produce independent releases of Qpid C++ and Python as well > as other modules that have heretofore been bundled into one large Qpid > release. More detail in the proposal\[2\]. > \[1\] > https://cwiki.apache.org/confluence/display/qpid/Source+tree+layout+proposal > \[2\] https://github.com/ssorj/qpid-svn-reorg -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7239) [Java Broker] Apply JavaScript code style to WMC
[ https://issues.apache.org/jira/browse/QPID-7239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack reassigned QPID-7239: -- Assignee: Lorenz Quack > [Java Broker] Apply JavaScript code style to WMC > > > Key: QPID-7239 > URL: https://issues.apache.org/jira/browse/QPID-7239 > Project: Qpid > Issue Type: Task > Components: Java Broker >Reporter: Lorenz Quack >Assignee: Lorenz Quack >Priority: Trivial > Fix For: qpid-java-6.1 > > > The JavaScript code of the web management console is formatted very > inconsistently. > We should apply a consistent style in one go. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-7239) [Java Broker] Apply JavaScript code style to WMC
[ https://issues.apache.org/jira/browse/QPID-7239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack closed QPID-7239. -- Resolution: Fixed > [Java Broker] Apply JavaScript code style to WMC > > > Key: QPID-7239 > URL: https://issues.apache.org/jira/browse/QPID-7239 > Project: Qpid > Issue Type: Task > Components: Java Broker >Reporter: Lorenz Quack >Assignee: Lorenz Quack >Priority: Trivial > Fix For: qpid-java-6.1 > > > The JavaScript code of the web management console is formatted very > inconsistently. > We should apply a consistent style in one go. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-300) Deprecate the ContainerEntity and move its attributes to RouterEntity
Ganesh Murthy created DISPATCH-300: -- Summary: Deprecate the ContainerEntity and move its attributes to RouterEntity Key: DISPATCH-300 URL: https://issues.apache.org/jira/browse/DISPATCH-300 Project: Qpid Dispatch Issue Type: Improvement Components: Container Affects Versions: 0.6 Reporter: Ganesh Murthy Assignee: Ganesh Murthy Move the attributes of ContainerEntity to RouterEntity thus deprecating ContainerEntity so we will have reduced complexity. This change should be backward compatible meaning configs currently using ContainerEntity must not be affected by this change. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7239) [Java Broker] Apply JavaScript code style to WMC
[ https://issues.apache.org/jira/browse/QPID-7239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15263907#comment-15263907 ] ASF subversion and git services commented on QPID-7239: --- Commit 1741610 from [~lorenz.quack] in branch 'java/trunk' [ https://svn.apache.org/r1741610 ] QPID-7239: [Java Broker] Revert code style reformatting for cryptoJS > [Java Broker] Apply JavaScript code style to WMC > > > Key: QPID-7239 > URL: https://issues.apache.org/jira/browse/QPID-7239 > Project: Qpid > Issue Type: Task > Components: Java Broker >Reporter: Lorenz Quack >Priority: Trivial > Fix For: qpid-java-6.1 > > > The JavaScript code of the web management console is formatted very > inconsistently. > We should apply a consistent style in one go. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7239) [Java Broker] Apply JavaScript code style to WMC
[ https://issues.apache.org/jira/browse/QPID-7239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15263902#comment-15263902 ] ASF subversion and git services commented on QPID-7239: --- Commit 1741609 from [~lorenz.quack] in branch 'java/trunk' [ https://svn.apache.org/r1741609 ] QPID-7239: [Java Broker] Apply consistent JavaScript code style > [Java Broker] Apply JavaScript code style to WMC > > > Key: QPID-7239 > URL: https://issues.apache.org/jira/browse/QPID-7239 > Project: Qpid > Issue Type: Task > Components: Java Broker >Reporter: Lorenz Quack >Priority: Trivial > Fix For: qpid-java-6.1 > > > The JavaScript code of the web management console is formatted very > inconsistently. > We should apply a consistent style in one go. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7239) [Java Broker] Apply JavaScript code style to WMC
Lorenz Quack created QPID-7239: -- Summary: [Java Broker] Apply JavaScript code style to WMC Key: QPID-7239 URL: https://issues.apache.org/jira/browse/QPID-7239 Project: Qpid Issue Type: Task Components: Java Broker Reporter: Lorenz Quack Priority: Trivial Fix For: qpid-java-6.1 The JavaScript code of the web management console is formatted very inconsistently. We should apply a consistent style in one go. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7238) [Java Broker, WMC] Share data from structure service amongst UI elements
[ https://issues.apache.org/jira/browse/QPID-7238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15263813#comment-15263813 ] Lorenz Quack commented on QPID-7238: If this is implemented the QueryBuilder should update the scope drop down selector from this information. > [Java Broker, WMC] Share data from structure service amongst UI elements > > > Key: QPID-7238 > URL: https://issues.apache.org/jira/browse/QPID-7238 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Lorenz Quack > > Currently the TreeView in the WMC polls the structure service every 5 > seconds. Other UI components (e.g. QueryBuilder) also occasionally need this > information. > We should share the information instead of making multiple requests. > One possible way is to store this information in management. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7238) [Java Broker, WMC] Share data from structure service amongst UI elements
Lorenz Quack created QPID-7238: -- Summary: [Java Broker, WMC] Share data from structure service amongst UI elements Key: QPID-7238 URL: https://issues.apache.org/jira/browse/QPID-7238 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Lorenz Quack Currently the TreeView in the WMC polls the structure service every 5 seconds. Other UI components (e.g. QueryBuilder) also occasionally need this information. We should share the information instead of making multiple requests. One possible way is to store this information in management. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7165) Allow query results to be sorted and paginated
[
https://issues.apache.org/jira/browse/QPID-7165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15263752#comment-15263752
]
ASF subversion and git services commented on QPID-7165:
---
Commit 1741584 from [~lorenz.quack] in branch 'java/trunk'
[ https://svn.apache.org/r1741584 ]
QPID-7165: [Java Broker] Fix opening query from VirtualHost tab and sort
visualisation in advanced mode
> Allow query results to be sorted and paginated
> --
>
> Key: QPID-7165
> URL: https://issues.apache.org/jira/browse/QPID-7165
> Project: Qpid
> Issue Type: New Feature
> Components: Java Broker
>Reporter: Keith Wall
>Assignee: Lorenz Quack
> Fix For: qpid-java-6.1
>
> Attachments:
> 0001-QPID-7165-Java-Broker-Allow-query-results-to-be-sort.patch,
> 0001-QPID-7165-Java-Broker-Allow-query-results-to-be-sort.patch,
> 0002-QPID-7165-Java-Broker-Allow-query-results-to-be-sort.patch,
> 0002-QPID-7165-Java-Broker-Allow-query-results-to-be-sort.patch,
> 0004-WIP.patch, QPID-7165-add-sorting-pagination.tar.gz
>
>
> Extend the mechanism provided by QPID-6969 to allow for the results set to be
> sorted by one or more columns and results set to be paginated.
> For the ordering clause, we could use SQL:2011 ORDER BY clause as a guide
> e.g. {{orderBy='x ASC,y DESC,z'}}
> For the pagination, SQL standardisation does not include it.
> https://en.wikipedia.org/wiki/Select_%28SQL%29#Result_limits We could opt for
> {{limit=}} {{offset=}} like MySQL/Sybase. We could also consider HTTP Range
> headers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7237) Excessive threads creation when suspending/resuming flow
[ https://issues.apache.org/jira/browse/QPID-7237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15263713#comment-15263713 ] Flavio Baronti commented on QPID-7237: -- This is somewhat connected to QPID-1084. > Excessive threads creation when suspending/resuming flow > > > Key: QPID-7237 > URL: https://issues.apache.org/jira/browse/QPID-7237 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.24, qpid-java-6.0.2 >Reporter: Flavio Baronti > Attachments: QPID-7237.patch > > > In high load situations, with a NO_ACKNOWLEDGE session, it is possible for > the client to create an excessive amount of threads to suspend/resume the > channel. > I'm providing a patch to avoid creating a new thread if the previous thread > has not completed its operation. This patch appears to avoid the problem in > our environment. Notice we are using version 0.24, but the code is the same > in the latest version. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7237) Excessive threads creation when suspending/resuming flow
[ https://issues.apache.org/jira/browse/QPID-7237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Baronti updated QPID-7237: - Attachment: QPID-7237.patch > Excessive threads creation when suspending/resuming flow > > > Key: QPID-7237 > URL: https://issues.apache.org/jira/browse/QPID-7237 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.24, qpid-java-6.0.2 >Reporter: Flavio Baronti > Attachments: QPID-7237.patch > > > In high load situations, with a NO_ACKNOWLEDGE session, it is possible for > the client to create an excessive amount of threads to suspend/resume the > channel. > I'm providing a patch to avoid creating a new thread if the previous thread > has not completed its operation. This patch appears to avoid the problem in > our environment. Notice we are using version 0.24, but the code is the same > in the latest version. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7237) Excessive threads creation when suspending/resuming flow
Flavio Baronti created QPID-7237: Summary: Excessive threads creation when suspending/resuming flow Key: QPID-7237 URL: https://issues.apache.org/jira/browse/QPID-7237 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: qpid-java-6.0.2, 0.24 Reporter: Flavio Baronti In high load situations, with a NO_ACKNOWLEDGE session, it is possible for the client to create an excessive amount of threads to suspend/resume the channel. I'm providing a patch to avoid creating a new thread if the previous thread has not completed its operation. This patch appears to avoid the problem in our environment. Notice we are using version 0.24, but the code is the same in the latest version. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
