[jira] [Updated] (PROTON-1394) Creating a Container leaks two file descriptors
[ https://issues.apache.org/jira/browse/PROTON-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated PROTON-1394: - Attachment: pn1394_0.patch Here is an alternate patch that I hope will work fine with older versions of Python and can be backported to older versions of Proton. By also breaking the circular reference in the handler hierarchy, it allows the reactor to free up more than just file descriptors and results in a complete release of Python and C resources according to my testing. It should be noted that weak references to any Wrapper objects (i.e. Reactor and Container) is a dubious strategy since the Python Wrapper object's life may be very short. Hence the use of the reactor's C impl rather than a Python weakref in the ErrorDelegate. None of the handlers are Wrapper objects, so a weakref proxy is used to break that circular reference. > Creating a Container leaks two file descriptors > --- > > Key: PROTON-1394 > URL: https://issues.apache.org/jira/browse/PROTON-1394 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.16.0 >Reporter: Mike Bonnet > Attachments: fix_container_leak.patch, leakyprotonpipes.py, > new_fix_container_leak.patch, pn1394_0.patch > > > Creating a Container (Reactor) creates a pipe (two file descriptors). This > pipe is never freed, even after the Container is stopped and goes out of > scope. An application that creates many short-lived Containers will quickly > exhaust file descriptors and Container creation will start failing. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7787) [Java Broker] In AMQP 1.0 allow the SASL outcome to carry additional information
[
https://issues.apache.org/jira/browse/QPID-7787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7787:
-
Attachment: 0001-QPID-7787-Java-Broker-Use-the-AMQP-SaslOutcome-s-add.patch
> [Java Broker] In AMQP 1.0 allow the SASL outcome to carry additional
> information
>
>
> Key: QPID-7787
> URL: https://issues.apache.org/jira/browse/QPID-7787
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> 0001-QPID-7787-Java-Broker-Use-the-AMQP-SaslOutcome-s-add.patch,
> QPID_7787___allow_the_SASL_outcome_to_carry_additional_information.patch
>
>
> Currently, when a SASL negotiation is successful but has additional data this
> data is sent as a challenge requiring another round-trip.
> AMQP 1.0 allows to send additional data in the SASL Outcome frame avoiding
> the additional round trip. We should use this in
> {{AMQPConnection_1_0Impl#processSaslResponse}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7787) [Java Broker] In AMQP 1.0 allow the SASL outcome to carry additional information
[
https://issues.apache.org/jira/browse/QPID-7787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16084158#comment-16084158
]
Keith Wall commented on QPID-7787:
--
Refreshed patch - no changes.
> [Java Broker] In AMQP 1.0 allow the SASL outcome to carry additional
> information
>
>
> Key: QPID-7787
> URL: https://issues.apache.org/jira/browse/QPID-7787
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> 0001-QPID-7787-Java-Broker-Use-the-AMQP-SaslOutcome-s-add.patch,
> QPID_7787___allow_the_SASL_outcome_to_carry_additional_information.patch
>
>
> Currently, when a SASL negotiation is successful but has additional data this
> data is sent as a challenge requiring another round-trip.
> AMQP 1.0 allows to send additional data in the SASL Outcome frame avoiding
> the additional round trip. We should use this in
> {{AMQPConnection_1_0Impl#processSaslResponse}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
Qpid Zone Exchange Binding basics java
Hello, How are you doing ? I'm new to qpid and facing some issues with the basics; I don't find a tuto or a step by step example using java to create : Exchange zone, queues, binding, consumer, producer. The most important thing that i can't find is how to create the exchange zone and binding using routing key, all that i want to do it not in command line but using the java (qpid client dependency for instance or even if ther's any spring-amqp implementation for the qpid that would be great). Thanks for your help, Meher
[jira] [Commented] (QPIDJMS-298) Use online service to manage and display coverage reports
[ https://issues.apache.org/jira/browse/QPIDJMS-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16084034#comment-16084034 ] ASF GitHub Bot commented on QPIDJMS-298: Github user jdanekrh commented on the issue: https://github.com/apache/qpid-jms/pull/8 @ctron thanks, I haven't noticed that problem. New version of jacoco plugin has goal `jacoco:report-aggregate`, which should aggregate coverage across all modules. Using it * breaks the cyclometric complexity column in the codecov.io report, for some reason * causes jacoco to find more partially-covered files in package `qpid-jms-client/src/main/java/org/apache/qpid/jms/selector`, so the coverage ends up going down, not up, as I had expected. > Use online service to manage and display coverage reports > - > > Key: QPIDJMS-298 > URL: https://issues.apache.org/jira/browse/QPIDJMS-298 > Project: Qpid JMS > Issue Type: Wish > Components: qpid-jms-client, qpid-jms-discovery >Affects Versions: 0.24.0 >Reporter: Jiri Danek >Priority: Minor > > There are multiple coverage monitoring online services that integrate with > popular CI services, like TravisCI. > I propose uploading coverage report from run in TravisCI to some coverage > monitoring service. This way, test coverage will become more visible. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-jms issue #8: QPIDJMS-298 Add coverage report uploading to codecov.io i...
Github user jdanekrh commented on the issue: https://github.com/apache/qpid-jms/pull/8 @ctron thanks, I haven't noticed that problem. New version of jacoco plugin has goal `jacoco:report-aggregate`, which should aggregate coverage across all modules. Using it * breaks the cyclometric complexity column in the codecov.io report, for some reason * causes jacoco to find more partially-covered files in package `qpid-jms-client/src/main/java/org/apache/qpid/jms/selector`, so the coverage ends up going down, not up, as I had expected. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7835) dead lock error
[
https://issues.apache.org/jira/browse/QPID-7835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16083748#comment-16083748
]
Keith Wall commented on QPID-7835:
--
I appreciate that you are checking the code and hear that you believe the issue
still exists, but please attach a thread dump with a reproduction of the
problem whilst using 6.1.3. This will allow me to completely understand and
resolve the issue in an efficient manner.
> dead lock error
> ---
>
> Key: QPID-7835
> URL: https://issues.apache.org/jira/browse/QPID-7835
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Affects Versions: 0.24
>Reporter: hanfeng
> Attachments: jstack.txt
>
>
> When the message server links over time, a message is sent, the caller to
> perceive the message send timeout, take the initiative to close the session,
> at the same time links are perceived to request timeout to shut down
> connection, re link the message server.
> When the link function of doClose to get off the lock _failoverMutex, but did
> not get a specific lock _messageDeliveryLock to close the session, close the
> session function close to get to the _messageDeliveryLock _failoverMutex
> lock, lock wait for link
> Deadlock.
> Modification method.
> In session's close function, add a judgment that you are closing session.
> public void close(long timeout) throws JMSException
> {
> {color:red} if （super.isClosing()） return ;{color}
> setClosing(true);
> lockMessageDelivery();
> try
> {
> // We must close down all producers and consumers in an orderly
> fashion. This is the only method
> // that can be called from a different thread of control from the
> one controlling the session.
> synchronized (getFailoverMutex())
> {
> close(timeout, true);
> }
> }
> finally
> {
> unlockMessageDelivery();
> }
> }
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7858) [Java Broker] Bump com.fasterxml.jackson dependency 2.5 => 2.8
[ https://issues.apache.org/jira/browse/QPID-7858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16083760#comment-16083760 ] ASF subversion and git services commented on QPID-7858: --- Commit 2d52d429eb3be32a13059eb5cb65c200dafeba4f in qpid-broker-j's branch refs/heads/master from [~k-wall] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=2d52d42 ] QPID-7858 [Java Broker] Bump com.fasterxml.jackson dependency from 2.5 to 2.8 > [Java Broker] Bump com.fasterxml.jackson dependency 2.5 => 2.8 > -- > > Key: QPID-7858 > URL: https://issues.apache.org/jira/browse/QPID-7858 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-broker-7.0.0 > > > The Broker uses Jackson for handling JSON. The Broker is currently a couple > of minor releases behind. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7858) [Java Broker] Bump com.fasterxml.jackson dependency 2.5 => 2.8
Keith Wall created QPID-7858: Summary: [Java Broker] Bump com.fasterxml.jackson dependency 2.5 => 2.8 Key: QPID-7858 URL: https://issues.apache.org/jira/browse/QPID-7858 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Keith Wall Fix For: qpid-java-broker-7.0.0 The Broker uses Jackson for handling JSON. The Broker is currently a couple of minor releases behind. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7835) dead lock error
[
https://issues.apache.org/jira/browse/QPID-7835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16083647#comment-16083647
]
hanfeng commented on QPID-7835:
---
I've read the source code and found that this problem still exists in the
latest version
> dead lock error
> ---
>
> Key: QPID-7835
> URL: https://issues.apache.org/jira/browse/QPID-7835
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Affects Versions: 0.24
>Reporter: hanfeng
> Attachments: jstack.txt
>
>
> When the message server links over time, a message is sent, the caller to
> perceive the message send timeout, take the initiative to close the session,
> at the same time links are perceived to request timeout to shut down
> connection, re link the message server.
> When the link function of doClose to get off the lock _failoverMutex, but did
> not get a specific lock _messageDeliveryLock to close the session, close the
> session function close to get to the _messageDeliveryLock _failoverMutex
> lock, lock wait for link
> Deadlock.
> Modification method.
> In session's close function, add a judgment that you are closing session.
> public void close(long timeout) throws JMSException
> {
> {color:red} if （super.isClosing()） return ;{color}
> setClosing(true);
> lockMessageDelivery();
> try
> {
> // We must close down all producers and consumers in an orderly
> fashion. This is the only method
> // that can be called from a different thread of control from the
> one controlling the session.
> synchronized (getFailoverMutex())
> {
> close(timeout, true);
> }
> }
> finally
> {
> unlockMessageDelivery();
> }
> }
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7835) dead lock error
[
https://issues.apache.org/jira/browse/QPID-7835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16083647#comment-16083647
]
hanfeng edited comment on QPID-7835 at 7/12/17 8:39 AM:
I've read the source code and found that this problem still exists in the 6.1.3
version
was (Author: hfwork...@163.com):
I've read the source code and found that this problem still exists in the
latest version
> dead lock error
> ---
>
> Key: QPID-7835
> URL: https://issues.apache.org/jira/browse/QPID-7835
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Affects Versions: 0.24
>Reporter: hanfeng
> Attachments: jstack.txt
>
>
> When the message server links over time, a message is sent, the caller to
> perceive the message send timeout, take the initiative to close the session,
> at the same time links are perceived to request timeout to shut down
> connection, re link the message server.
> When the link function of doClose to get off the lock _failoverMutex, but did
> not get a specific lock _messageDeliveryLock to close the session, close the
> session function close to get to the _messageDeliveryLock _failoverMutex
> lock, lock wait for link
> Deadlock.
> Modification method.
> In session's close function, add a judgment that you are closing session.
> public void close(long timeout) throws JMSException
> {
> {color:red} if （super.isClosing()） return ;{color}
> setClosing(true);
> lockMessageDelivery();
> try
> {
> // We must close down all producers and consumers in an orderly
> fashion. This is the only method
> // that can be called from a different thread of control from the
> one controlling the session.
> synchronized (getFailoverMutex())
> {
> close(timeout, true);
> }
> }
> finally
> {
> unlockMessageDelivery();
> }
> }
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1486) Proton(-J) provides no mechanism to get or set the additional-data field on sasl-outcome
[ https://issues.apache.org/jira/browse/PROTON-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall reassigned PROTON-1486: -- Assignee: Keith Wall > Proton(-J) provides no mechanism to get or set the additional-data field on > sasl-outcome > > > Key: PROTON-1486 > URL: https://issues.apache.org/jira/browse/PROTON-1486 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Reporter: Rob Godfrey >Assignee: Keith Wall > Attachments: PROTON_1486.patch > > > The Proton Engine API provides no mechanism for getting or setting the > additional-data field on sasl-outcome. > Some SASL mechanisms (e.g. SCRAM-SHA-\*) send additional data along with the > outcome (in the case of SCRAM-SHA-\* the additional data is a proof that the > server is also aware of the credentials and is not simply just accepting any > credential data as part of some sort of attack). > One approach for the API would be to expose the additional-data field using > the send/recv/pending methods used for exchanging the challenge/response in > the earlier phases of the sasl exchange. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7857) [Java Broker] Invalid routing key
Tomas Vavricka created QPID-7857:
Summary: [Java Broker] Invalid routing key
Key: QPID-7857
URL: https://issues.apache.org/jira/browse/QPID-7857
Project: Qpid
Issue Type: Bug
Components: Java Broker
Affects Versions: qpid-java-broker-7.0.0
Environment: Java Broker - latest trunk
Qpid JMS client - 0.11.1
Reporter: Tomas Vavricka
Fix For: qpid-java-broker-7.0.0
There is an issue with routing key when sending message to Java Broker. When
ACL rule contains {{routingKey}} constraint Java Broker denies access.
ACL rule:
{noformat}
ACL ALLOW-LOG FIXGW ACCESS VIRTUALHOST
ACL ALLOW-LOG FIXGW PUBLISH EXCHANGE name="request.FIXGW"
routingKey="TradeReport*"
{noformat}
Client code snippet:
{code:java}
TextMessage message = session.createTextMessage("...");
message.setJMSCorrelationID(UUID.randomUUID().toString());
message.setJMSType("TradeReport");
{code}
Java Broker log:
{noformat}
...
2017-07-11 15:55:31,003 DEBUG [IO-/172.23.38.39:40030] (o.a.q.s.s.a.c.RuleSet)
- Checking against rule: Rule[identity='ALL',
action=AclAction[action=Action[operation=All, object=All, properties={}],
firewallRule=null], permission=DENY_LOG]
2017-07-11 15:55:31,003 DEBUG [IO-/172.23.38.39:40030] (o.a.q.s.s.a.c.RuleSet)
- Action matches. Result: DENY_LOG
2017-07-11 15:55:31,003 INFO [IO-/172.23.38.39:40030] (q.m.a.denied) -
[con:2(FIXGW@/172.23.38.39:40030/default)/ch:1] ACL-1002 : Denied : Publish
Exchange {ROUTING_KEY=request.FIXGW, NAME=request.FIXGW,
VIRTUALHOST_NAME=default}
2017-07-11 15:55:31,003 DEBUG [IO-/172.23.38.39:40030]
(o.a.q.s.m.AbstractConfiguredObject) - authorise returned DENIED
2017-07-11 15:55:31,003 DEBUG [IO-/172.23.38.39:40030] (o.a.q.s.p.frame) -
SEND[/172.23.38.39:40030|1] :
Detach{handle=0,closed=true,error=Error{condition=not-allowed,description=Permission
ACTION(publish) is denied for : Exchange 'request.FIXGW' on VirtualHost
'default'}}
2017-07-11 15:55:31,003 DEBUG [IO-/172.23.38.39:40030]
(o.a.q.s.s.d.DerbyMessageStore) - REMOVE called on message: 3
2017-07-11 15:55:31,003 DEBUG [IO-/172.23.38.39:40030]
(o.a.q.s.p.v.f.FrameHandler) - RECV 0 bytes
...
{noformat}
In log there is routing key same as name. But in client was routing key
specified as TradeReport.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
