[jira] [Commented] (PROTON-1622) Add coverage reporting to CMake build

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217526#comment-16217526
 ] 

ASF subversion and git services commented on PROTON-1622:
-

Commit 540ef366f3a124b4dc3ec595504a6fd309fb45bf in qpid-proton's branch 
refs/heads/master from [~chug]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=540ef36 ]

PROTON-1622: Add instructions for coverage reporting to DEVELOPERS.md


> Add coverage reporting to CMake build
> -
>
> Key: PROTON-1622
> URL: https://issues.apache.org/jira/browse/PROTON-1622
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Assignee: Justin Ross
>Priority: Minor
>  Labels: patch, testing
> Fix For: proton-c-0.18.1
>
>
> This improvement is intended to cover
> * Reporting coverage from Python code
> * Upload of Python and C/C++ coverage data from Travis CI to codecov.io for 
> easy viewing



--
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] [Resolved] (DISPATCH-860) Link Route tests failing intermittently.

[Ganesh Murthy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ganesh Murthy resolved DISPATCH-860.

Resolution: Fixed

> Link Route tests failing intermittently.
> 
>
> Key: DISPATCH-860
> URL: https://issues.apache.org/jira/browse/DISPATCH-860
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 1.0.0
>Reporter: Ganesh Murthy
> Fix For: 1.0.0
>
>
> Run the link route system tests repeatedly and the router crashes during one 
> of the test runs.
> Here is the backtrace - 
> #0  0x7699d1f7 in raise () from /lib64/libc.so.6
> #1  0x7699e8e8 in abort () from /lib64/libc.so.6
> #2  0x76996266 in __assert_fail_base () from /lib64/libc.so.6
> #3  0x76996312 in __assert_fail () from /lib64/libc.so.6
> #4  0x77ba4201 in sys_mutex_lock (mutex=)
> at /h/amqp/d/d10/dispatch/src/posix/threading.c:57
> #5  0x77b9f535 in qd_message_send (
> in_msg=in_msg@entry=0x7fffe406bb90, link=link@entry=0x7fffd4026450,
> strip_annotations=,
> restart_rx=restart_rx@entry=0x7fffe9e5c278)
> at /h/amqp/d/d10/dispatch/src/message.c:1539
> #6  0x77bb8894 in CORE_link_deliver (context=0xb59fb0,
> link=0x7fffe4053f50, dlv=0x7fffe4065f50, settled=)
> at /h/amqp/d/d10/dispatch/src/router_node.c:1342
> #7  0x77bb6485 in qdr_link_process_deliveries (core=0xaf7030,
> link=0x7fffe4053f50, credit=26)
> at /h/amqp/d/d10/dispatch/src/router_core/transfer.c:149
> #8  0x77babf94 in qdr_connection_process (conn=0x7fffcc00b310)
> at /h/amqp/d/d10/dispatch/src/router_core/connections.c:261
> #9  0x77b96908 in writable_handler (container=0xaf6e20,
> container=0xaf6e20, conn=0x7fffe0024820, qd_conn=0x7fffe0001e50)
> at /h/amqp/d/d10/dispatch/src/container.c:329
> #10 qd_container_handle_event (container=0xaf6e20,
> event=event@entry=0x7fffd4009ee0)
> at /h/amqp/d/d10/dispatch/src/container.c:552
> #11 0x77bbd9ad in handle (qd_server=qd_server@entry=0x9634b0,
> e=0x7fffd4009ee0) at /h/amqp/d/d10/dispatch/src/server.c:912
> #12 0x77bbe698 in thread_run (arg=0x9634b0)
> at /h/amqp/d/d10/dispatch/src/server.c:930
> #13 0x7750ae25 in start_thread () from /lib64/libpthread.so.0
> #14 0x76a6034d in clone () from /lib64/libc.so.6



--
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-dispatch pull request #213: Added delivery reference protrection from q...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/qpid-dispatch/pull/213


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (DISPATCH-860) Link Route tests failing intermittently.

[Ganesh Murthy (JIRA)]

Ganesh Murthy created DISPATCH-860:
--

 Summary: Link Route tests failing intermittently.
 Key: DISPATCH-860
 URL: https://issues.apache.org/jira/browse/DISPATCH-860
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Container
Affects Versions: 1.0.0
Reporter: Ganesh Murthy
 Fix For: 1.0.0


Run the link route system tests repeatedly and the router crashes during one of 
the test runs.

Here is the backtrace - 

#0  0x7699d1f7 in raise () from /lib64/libc.so.6
#1  0x7699e8e8 in abort () from /lib64/libc.so.6
#2  0x76996266 in __assert_fail_base () from /lib64/libc.so.6
#3  0x76996312 in __assert_fail () from /lib64/libc.so.6
#4  0x77ba4201 in sys_mutex_lock (mutex=)
at /h/amqp/d/d10/dispatch/src/posix/threading.c:57
#5  0x77b9f535 in qd_message_send (
in_msg=in_msg@entry=0x7fffe406bb90, link=link@entry=0x7fffd4026450,
strip_annotations=,
restart_rx=restart_rx@entry=0x7fffe9e5c278)
at /h/amqp/d/d10/dispatch/src/message.c:1539
#6  0x77bb8894 in CORE_link_deliver (context=0xb59fb0,
link=0x7fffe4053f50, dlv=0x7fffe4065f50, settled=)
at /h/amqp/d/d10/dispatch/src/router_node.c:1342
#7  0x77bb6485 in qdr_link_process_deliveries (core=0xaf7030,
link=0x7fffe4053f50, credit=26)
at /h/amqp/d/d10/dispatch/src/router_core/transfer.c:149
#8  0x77babf94 in qdr_connection_process (conn=0x7fffcc00b310)
at /h/amqp/d/d10/dispatch/src/router_core/connections.c:261
#9  0x77b96908 in writable_handler (container=0xaf6e20,
container=0xaf6e20, conn=0x7fffe0024820, qd_conn=0x7fffe0001e50)
at /h/amqp/d/d10/dispatch/src/container.c:329
#10 qd_container_handle_event (container=0xaf6e20,
event=event@entry=0x7fffd4009ee0)
at /h/amqp/d/d10/dispatch/src/container.c:552
#11 0x77bbd9ad in handle (qd_server=qd_server@entry=0x9634b0,
e=0x7fffd4009ee0) at /h/amqp/d/d10/dispatch/src/server.c:912
#12 0x77bbe698 in thread_run (arg=0x9634b0)
at /h/amqp/d/d10/dispatch/src/server.c:930
#13 0x7750ae25 in start_thread () from /lib64/libpthread.so.0
#14 0x76a6034d in clone () from /lib64/libc.so.6



--
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-7646) [Java Broker] fix AbstractAMQPSession#getLocalTransactionOpen to support values > 1

[Keith Wall (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217167#comment-16217167
 ] 

Keith Wall edited comment on QPID-7646 at 10/24/17 4:16 PM:


I think it is useful to think first about the use-cases for the transaction 
statistics on the model. I can think of two:

# As an operator, I need to be able to determine if a connection is using 
transactions for messaging. The failure to use transactions is a common 
application error.  Application owners tend to report "message loss" from the 
messaging layer.
# As an operator or developer, applications that begin transactional work and 
then fail to commit can be a difficult problem to diagnose.  It would be 
desirable if the Broker could help reveal this to me.

Currently on the model we have the following transaction related statistics:

{{Session#localTransactionBegins}}  (cumulative)
{{Session#localTransactionRollbacks}} (cumulative)
{{Session#localTransactionOpen}} (point in time - number of open transactions 
at this moment)
{{Session#getTransactionStartTime}} (time when the current *producing* store 
transaction began)
{{Session#getTransactionUpdateTime}} (time when the current *producing* store  
transaction last received new work)

and attributes:

QueueManagingVirtualHost#getStoreTransactionIdleTimeoutClose
QueueManagingVirtualHost#getStoreTransactionIdleTimeoutWarn
QueueManagingVirtualHost#getStoreTransactionOpenTimeoutClose
QueueManagingVirtualHost#getStoreTransactionOpenTimeoutWarn

The last two statistics were influenced by implementation - specifically how 
the Broker uses the store. For a producing session the message store 
transaction is opened as the first message arrives and continues until the 
producing session is committed.  For consuming sessions, the change of state is 
a memory until the consuming session is committed, at which point we have a 
single short lived store transaction.

h3. Problem

For AMQP 0-9..0-10 transactions are scoped to channels or sessions.  In AMQP 
1.0, this is not the case.  A single transaction can span multiple sessions.   
This necessitates a re-modelling.

h3. Proposal - Model changes - for v7.

# Introduce 
QueueManagingVirtualHost#(TransactedEnqueuedMessages|TransactedDequeuedMessages)
 and 
   
Connection#(TransactedEnqueuedMessages|getTransactedEnqueuedMessages)
# Replace Session#getTransactionStartTime and #getTransactionUpdateTime with 
Connection#getOldestTransactionStartTime 
# Move Session#localTransaction(Begins|Rollback|Open) from Session to 
Connection  (do we actually need these?)

The transactedEnqueuedMessages/transactedDequeuedMessages statistics allows an 
operator to determine if a application is using transactions or not.  He does 
this by comparing the transactedEnqueuedMessages with the  
totalEnqueuedMessages etc.   If the transactedEnqueuedMessages is lower, he can 
infer that transactions are not universally in use on that connection or 
virtualhost.

h3. Future work - not v7 - TransactionTimeout for AMQP 1.0:

* AMQConnection_1_0#getOpenTransactions is unused - push up and change the 
return type to Iterator
* For 0-9 and 0-10 getOpenTranactions will simply expose the LocalTransaction 
associated with each session of the connection.
* Refactor the TransactionTimeoutTicker to be associated with a connection 
instead of session. It will call AMQConnection#getOpenTransactions.
* How will the transaction timeout close the session or connection for 0-9 or 
0-10?  Perhaps TransactionTimeoutTicker can have protocol specific 
implementations allowing it to do the right thing for each protocol.
* For AMQP 1.0 What is the correct way to abort the timed out transaction.  Can 
we simply close the transaction-coordinator link?  How would client respond to 
this?






was (Author: k-wall):
I think it is useful to think first about the use-cases for the transaction 
statistics on the model. I can think of two:

# As an operator, I need to be able to determine if a connection is using 
transactions for messaging. The failure to use transactions is a common 
application error.  Application owners tend to report "message loss" from the 
messaging layer.
# As an operator or developer, applications that begin transactional work and 
then fail to commit can be a difficult problem to diagnose.  It would be 
desirable if the Broker could help reveal this to me.

Currently on the model we have the following transaction related statistics:

{{Session#localTransactionBegins}}  (cumulative)
{{Session#localTransactionRollbacks}} (cumulative)
{{Session#localTransactionOpen}} (point in time - number of open transactions 
at this moment)
{{Session#getTransactionStartTime}} (time when the current *producing* store 
transaction began)
{{Session#getTransactionUpdateTime}} (time when the current *producing* store  
transaction last received new work)

and 

[jira] [Commented] (QPID-7646) [Java Broker] fix AbstractAMQPSession#getLocalTransactionOpen to support values > 1

[Keith Wall (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217167#comment-16217167
 ] 

Keith Wall commented on QPID-7646:
--

I think it is useful to think first about the use-cases for the transaction 
statistics on the model. I can think of two:

# As an operator, I need to be able to determine if a connection is using 
transactions for messaging. The failure to use transactions is a common 
application error.  Application owners tend to report "message loss" from the 
messaging layer.
# As an operator or developer, applications that begin transactional work and 
then fail to commit can be a difficult problem to diagnose.  It would be 
desirable if the Broker could help reveal this to me.

Currently on the model we have the following transaction related statistics:

{{Session#localTransactionBegins}}  (cumulative)
{{Session#localTransactionRollbacks}} (cumulative)
{{Session#localTransactionOpen}} (point in time - number of open transactions 
at this moment)
{{Session#getTransactionStartTime}} (time when the current *producing* store 
transaction began)
{{Session#getTransactionUpdateTime}} (time when the current *producing* store  
transaction last received new work)

and attributes:

QueueManagingVirtualHost#getStoreTransactionIdleTimeoutClose
QueueManagingVirtualHost#getStoreTransactionIdleTimeoutWarn
QueueManagingVirtualHost#getStoreTransactionOpenTimeoutClose
QueueManagingVirtualHost#getStoreTransactionOpenTimeoutWarn

The last two statistics were influenced by implementation - specifically how 
the Broker uses the store. For a producing session the message store 
transaction is opened as the first message arrives and continues until the 
producing session is committed.  For consuming sessions, the change of state is 
a memory until the consuming session is committed, at which point we have a 
single short lived store transaction.

For AMQP 0-9..0-10 transactions are scoped to channels or sessions.  In AMQP 
1.0, this is not the case.  A single transaction can span multiple sessions.   
This necessitates a re-modelling.

h1. Proposal - Model changes - for v7.

# Introduce 
QueueManagingVirtualHost#(TransactedEnqueuedMessages|TransactedDequeuedMessages)
 and 
   
Connection#(TransactedEnqueuedMessages|getTransactedEnqueuedMessages)
# Replace Session#getTransactionStartTime and #getTransactionUpdateTime with 
Connection#getOldestTransactionStartTime 
# Move Session#localTransaction(Begins|Rollback|Open) from Session to 
Connection  (do we actually need these?)

The transactedEnqueuedMessages/transactedDequeuedMessages statistics allows an 
operator to determine if a application is using transactions or not.  He does 
this by comparing the transactedEnqueuedMessages with the  
totalEnqueuedMessages etc.   If the transactedEnqueuedMessages is lower, he can 
infer that transactions are not universally in use on that connection or 
virtualhost.

h1. Future work - not v7 - TransactionTimeout for AMQP 1.0:

* AMQConnection_1_0#getOpenTransactions is unused - push up and change the 
return type to Iterator
* For 0-9 and 0-10 getOpenTranactions will simply expose the LocalTransaction 
associated with each session of the connection.
* Refactor the TransactionTimeoutTicker to be associated with a connection 
instead of session. It will call AMQConnection#getOpenTransactions.
* How will the transaction timeout close the session or connection for 0-9 or 
0-10?  Perhaps TransactionTimeoutTicker can have protocol specific 
implementations allowing it to do the right thing for each protocol.
* For AMQP 1.0 What is the correct way to abort the timed out transaction.  Can 
we simply close the transaction-coordinator link?  How would client respond to 
this?





> [Java Broker] fix AbstractAMQPSession#getLocalTransactionOpen to support 
> values > 1
> ---
>
> Key: QPID-7646
> URL: https://issues.apache.org/jira/browse/QPID-7646
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> During the review of QPID-7633 it was noted:
> bq. Why do we only return 0 or 1 from 
> AbstractAMQPSession#getLocalTransactionOpen. That seems wrong.
> which was followed up by Rob:
> bq. On getLocalTransactionOpen, I agree that looks very dodgy. In AMQP 0-x 
> the value will only be 0 or 1, but I'm not sure the implementation the we 
> have now is safe. I think the implementations will need to define this 
> properly (i.e. the calculation will need to be atomic, and the value may be > 
> 1 for AMQP 1.0 )



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For 

[jira] [Comment Edited] (QPID-7646) [Java Broker] fix AbstractAMQPSession#getLocalTransactionOpen to support values > 1

[Keith Wall (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217167#comment-16217167
 ] 

Keith Wall edited comment on QPID-7646 at 10/24/17 4:15 PM:


I think it is useful to think first about the use-cases for the transaction 
statistics on the model. I can think of two:

# As an operator, I need to be able to determine if a connection is using 
transactions for messaging. The failure to use transactions is a common 
application error.  Application owners tend to report "message loss" from the 
messaging layer.
# As an operator or developer, applications that begin transactional work and 
then fail to commit can be a difficult problem to diagnose.  It would be 
desirable if the Broker could help reveal this to me.

Currently on the model we have the following transaction related statistics:

{{Session#localTransactionBegins}}  (cumulative)
{{Session#localTransactionRollbacks}} (cumulative)
{{Session#localTransactionOpen}} (point in time - number of open transactions 
at this moment)
{{Session#getTransactionStartTime}} (time when the current *producing* store 
transaction began)
{{Session#getTransactionUpdateTime}} (time when the current *producing* store  
transaction last received new work)

and attributes:

QueueManagingVirtualHost#getStoreTransactionIdleTimeoutClose
QueueManagingVirtualHost#getStoreTransactionIdleTimeoutWarn
QueueManagingVirtualHost#getStoreTransactionOpenTimeoutClose
QueueManagingVirtualHost#getStoreTransactionOpenTimeoutWarn

The last two statistics were influenced by implementation - specifically how 
the Broker uses the store. For a producing session the message store 
transaction is opened as the first message arrives and continues until the 
producing session is committed.  For consuming sessions, the change of state is 
a memory until the consuming session is committed, at which point we have a 
single short lived store transaction.

For AMQP 0-9..0-10 transactions are scoped to channels or sessions.  In AMQP 
1.0, this is not the case.  A single transaction can span multiple sessions.   
This necessitates a re-modelling.

h2. Proposal - Model changes - for v7.

# Introduce 
QueueManagingVirtualHost#(TransactedEnqueuedMessages|TransactedDequeuedMessages)
 and 
   
Connection#(TransactedEnqueuedMessages|getTransactedEnqueuedMessages)
# Replace Session#getTransactionStartTime and #getTransactionUpdateTime with 
Connection#getOldestTransactionStartTime 
# Move Session#localTransaction(Begins|Rollback|Open) from Session to 
Connection  (do we actually need these?)

The transactedEnqueuedMessages/transactedDequeuedMessages statistics allows an 
operator to determine if a application is using transactions or not.  He does 
this by comparing the transactedEnqueuedMessages with the  
totalEnqueuedMessages etc.   If the transactedEnqueuedMessages is lower, he can 
infer that transactions are not universally in use on that connection or 
virtualhost.

h2. Future work - not v7 - TransactionTimeout for AMQP 1.0:

* AMQConnection_1_0#getOpenTransactions is unused - push up and change the 
return type to Iterator
* For 0-9 and 0-10 getOpenTranactions will simply expose the LocalTransaction 
associated with each session of the connection.
* Refactor the TransactionTimeoutTicker to be associated with a connection 
instead of session. It will call AMQConnection#getOpenTransactions.
* How will the transaction timeout close the session or connection for 0-9 or 
0-10?  Perhaps TransactionTimeoutTicker can have protocol specific 
implementations allowing it to do the right thing for each protocol.
* For AMQP 1.0 What is the correct way to abort the timed out transaction.  Can 
we simply close the transaction-coordinator link?  How would client respond to 
this?






was (Author: k-wall):
I think it is useful to think first about the use-cases for the transaction 
statistics on the model. I can think of two:

# As an operator, I need to be able to determine if a connection is using 
transactions for messaging. The failure to use transactions is a common 
application error.  Application owners tend to report "message loss" from the 
messaging layer.
# As an operator or developer, applications that begin transactional work and 
then fail to commit can be a difficult problem to diagnose.  It would be 
desirable if the Broker could help reveal this to me.

Currently on the model we have the following transaction related statistics:

{{Session#localTransactionBegins}}  (cumulative)
{{Session#localTransactionRollbacks}} (cumulative)
{{Session#localTransactionOpen}} (point in time - number of open transactions 
at this moment)
{{Session#getTransactionStartTime}} (time when the current *producing* store 
transaction began)
{{Session#getTransactionUpdateTime}} (time when the current *producing* store  
transaction last received new work)

and attributes:

[jira] [Updated] (QPID-7971) [Java Broker] [AMQP1.0] [AMQP0-9] Queue#ConsumerCountWithCredit statistic not decremented when consumer disconnects

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7971:
-
Status: Reviewable  (was: In Progress)

> [Java Broker] [AMQP1.0] [AMQP0-9] Queue#ConsumerCountWithCredit statistic not 
> decremented when consumer disconnects
> ---
>
> Key: QPID-7971
> URL: https://issues.apache.org/jira/browse/QPID-7971
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> Running {{HelloWorld}} against the Java Broker, I notice that the 
> {{Queue#ConsumerCountWithCredit}} statistic does not return to zero after the 
> connection is closed.  The problem is not apparent -when using the older 
> protocols-.  Corrected: AMQP 0-9 also exhibits the same problem.
> I notice {{org.apache.qpid.server.consumer.AbstractConsumerTarget#close}} 
> clears {{_consumers}} then calls {{setNotifyWorkDesired}} which iterates 
> {{_consumers}}.
> I verified that v6.1 is not affected.



--
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] (QPID-7971) [Java Broker] [AMQP1.0] [AMQP0-9] Queue#ConsumerCountWithCredit statistic not decremented when consumer disconnects

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall reassigned QPID-7971:


Assignee: Keith Wall

> [Java Broker] [AMQP1.0] [AMQP0-9] Queue#ConsumerCountWithCredit statistic not 
> decremented when consumer disconnects
> ---
>
> Key: QPID-7971
> URL: https://issues.apache.org/jira/browse/QPID-7971
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> Running {{HelloWorld}} against the Java Broker, I notice that the 
> {{Queue#ConsumerCountWithCredit}} statistic does not return to zero after the 
> connection is closed.  The problem is not apparent -when using the older 
> protocols-.  Corrected: AMQP 0-9 also exhibits the same problem.
> I notice {{org.apache.qpid.server.consumer.AbstractConsumerTarget#close}} 
> clears {{_consumers}} then calls {{setNotifyWorkDesired}} which iterates 
> {{_consumers}}.
> I verified that v6.1 is not affected.



--
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-7832) Refactor store/protocol API using Collection

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217160#comment-16217160
 ] 

ASF subversion and git services commented on QPID-7832:
---

Commit e64e282688da8963133dc09c630482c686d8be7a in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=e64e282 ]

QPID-7832: [Java Broker] Introduce QpidByteBuffer interface and split 
implementation into separate classes


> Refactor store/protocol API using Collection
> -
>
> Key: QPID-7832
> URL: https://issues.apache.org/jira/browse/QPID-7832
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 
> .0001-QPID-7832-Java-Broker-Small-performance-optimisation.patch.swp, 
> 0001-QPID-7832-Java-Broker-Refactor-store-protocol-API-us.patch, 
> 0002-QPID-7832-Java-Broker-Improve-performance-for-QpidBy.patch
>
>
> Store/protocol APIs have gradually been evolving to accept/return message 
> content/message metadata in terms of an ordered list of QBBs.  This has lead 
> to use of helper methods such as those in QBBUtils which read from a list of 
> buffers rather than a single one.
> This would be better refactored.   QpidByteBuffer should be an interface.  
> This would allow a concrete implementation CompositeQpidByteBuffer which is 
> backed by a list produced by the store or network IO.



--
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] (PROTON-1176) Core dump if reactor creation fails

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217143#comment-16217143
 ] 

ASF subversion and git services commented on PROTON-1176:
-

Commit 415a1f7ab6c76414a98b26883fe2d6c3ba26addd in qpid-proton's branch 
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=415a1f7 ]

PROTON-1176: [python] remove unreliable file descriptors test

Removed a FD overflow test that is not reliable under both linux and windows.


> Core dump if reactor creation fails
> ---
>
> Key: PROTON-1176
> URL: https://issues.apache.org/jira/browse/PROTON-1176
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.12.0
>Reporter: Cliff Jansen
>Assignee: Alan Conway
>  Labels: crash
> Fix For: proton-c-0.18.1
>
>
> If a BlockingConnection fails creating a reactor from Proton-C, the wrapper 
> constructor for the container fails on a null "impl" value, causing a core 
> dump rather than an exception.
> This can happen if the process runs out of file descriptors and cannot 
> allocate the self-pipes needed by the reactor.
> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1319165



--
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-proton pull request #:

[alanconway]

Github user alanconway commented on the pull request:


https://github.com/apache/qpid-proton/commit/da7f5056a45528196be6733fc56a1f41bda58ded#commitcomment-25161035
  
In tests/python/proton_tests/utils.py:
In tests/python/proton_tests/utils.py on line 180:
Thanks, that test is causing problems in a couple of ways. I've removed it
till I can figure out a more reliable way to do it.

On Tue, Oct 24, 2017 at 1:29 PM, Jiří Daněk 
wrote:

> this has to be except OSError as e, or just except OSError here.
> Otherwise it fails to run on Python 3. https://travis-ci.org/apache/
> qpid-proton/builds/291711488. There is one more instance of this Python 3
> incompatible syntax elsewhere in Proton; it is not running in Tox in
> travis, so it was not caught.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> 
,
> or mute the thread
> 

> .
>



---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7981) [Java Broker] [AMQP1.0] Handle erroneous null termini cases

[Keith Wall (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216852#comment-16216852
 ] 

Keith Wall commented on QPID-7981:
--

Hi Rob,

I agree with your ideas you put above with regard to desired broker behaviour:

https://issues.apache.org/jira/browse/QPID-7981?focusedCommentId=16215404=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16215404

Just to be clear, I think we are saying that in these cases (null source on an 
incoming link from the broker's point-of-view, or null target on an outgoing 
link from the broker's point of view), the behaviours will be the same as the 
last sentense of 2.6.3 "Establishing Or Resuming A Link":

bq. Note that if the application chooses not to create a terminus, the session 
endpoint will still create a link endpoint and issue an attach indicating that 
the link endpoint has no associated local terminus. In this case, the session 
endpoint MUST immediately detach the newly created link endpoint.

For the incoming link, the Broker will of course no longer be issuing credit.   
 If the peer were to try and transfer messages, I think 2.6.5 "Link Errors" 
would apply i.e.a  session error rather than a connection closed.

bq. If any input (other than a detach) related to the endpoint either via the 
input handle or delivery-ids be received, the session MUST be terminated with 
an errant-link session-error. 

For the outgoing link, if the client were to pipeline an attach with a null 
target and a flow, 2.6.5 "Link Errors" would  apply too and the errant-link 
session-error would result.

I think it would be good is the AMQP 1.0 spec could be clarified.


> [Java Broker] [AMQP1.0] Handle erroneous null termini cases
> ---
>
> Key: QPID-7981
> URL: https://issues.apache.org/jira/browse/QPID-7981
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> Testing the Broker against Rhea's {{example/helloworld.js}} shows that the 
> AMQP 1.0 protocol layer fails in at least two places.
> The first is if the {{Target}} (not mandatory) is omitted from the incoming 
> attach.
> {noformat}
> 2017-10-21 18:13:20,609 DEBUG [IO-/10.211.55.13:52033] (o.a.q.s.p.frame) - 
> RECV[/10.211.55.13:52033|0] : 
> Attach{name=7e65e0a0-961f-e941-b42b-262380143f76,handle=0,role=receiver,source=Source{address=examples}}
> 2017-10-21 18:13:20,622 DEBUG [IO-/10.211.55.13:52033] (o.a.q.s.p.v.LinkImpl) 
> - Error attaching link
> java.lang.NullPointerException: null
>   at 
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.createConsumerTarget(SendingLinkEndpoint.java:209)
>   at 
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.attachReceived(SendingLinkEndpoint.java:636)
>   at 
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.establishLink(SendingLinkEndpoint.java:352)
>   at 
> org.apache.qpid.server.protocol.v1_0.AbstractLinkEndpoint.receiveAttach(AbstractLinkEndpoint.java:131)
>   at 
> org.apache.qpid.server.protocol.v1_0.LinkImpl.attach(LinkImpl.java:106)
>   at 
> org.apache.qpid.server.protocol.v1_0.Session_1_0.receiveAttach(Session_1_0.java:210)
>   at 
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receiveAttach(AMQPConnection_1_0Impl.java:435)
>   at 
> org.apache.qpid.server.protocol.v1_0.type.transport.Attach.invoke(Attach.java:366)
>   at 
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:517)
>   at 
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$receive$0(AMQPConnection_1_0Impl.java:469)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receive(AMQPConnection_1_0Impl.java:463)
>   at 
> org.apache.qpid.server.protocol.v1_0.framing.FrameHandler.parse(FrameHandler.java:211)
>   at 
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$received$11(AMQPConnection_1_0Impl.java:1316)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:1291)
>   at 
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:134)
>   at 
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:606)
>   at 
> org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.processData(NonBlockingConnectionTLSDelegate.java:136)
>   at 
> org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
>   at 
> 

[GitHub] qpid-proton pull request #:

[jdanekrh]

Github user jdanekrh commented on the pull request:


https://github.com/apache/qpid-proton/commit/da7f5056a45528196be6733fc56a1f41bda58ded#commitcomment-25156357
  
In tests/python/proton_tests/utils.py:
In tests/python/proton_tests/utils.py on line 180:
this has to be `except OSError as e`, or just `except OSError` here. 
Otherwise it fails to run on Python 3. 
https://travis-ci.org/apache/qpid-proton/builds/291711488. There is one more 
instance of this Python 3 incompatible syntax elsewhere in Proton; it is not 
running in Tox in travis, so it was not caught.


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7981) [Java Broker] [AMQP1.0] Handle erroneous null termini cases

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7981:
-
Description: 
Testing the Broker against Rhea's {{example/helloworld.js}} shows that the AMQP 
1.0 protocol layer fails in at least two places.

The first is if the {{Target}} (not mandatory) is omitted from the incoming 
attach.

{noformat}
2017-10-21 18:13:20,609 DEBUG [IO-/10.211.55.13:52033] (o.a.q.s.p.frame) - 
RECV[/10.211.55.13:52033|0] : 
Attach{name=7e65e0a0-961f-e941-b42b-262380143f76,handle=0,role=receiver,source=Source{address=examples}}
2017-10-21 18:13:20,622 DEBUG [IO-/10.211.55.13:52033] (o.a.q.s.p.v.LinkImpl) - 
Error attaching link
java.lang.NullPointerException: null
at 
org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.createConsumerTarget(SendingLinkEndpoint.java:209)
at 
org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.attachReceived(SendingLinkEndpoint.java:636)
at 
org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.establishLink(SendingLinkEndpoint.java:352)
at 
org.apache.qpid.server.protocol.v1_0.AbstractLinkEndpoint.receiveAttach(AbstractLinkEndpoint.java:131)
at 
org.apache.qpid.server.protocol.v1_0.LinkImpl.attach(LinkImpl.java:106)
at 
org.apache.qpid.server.protocol.v1_0.Session_1_0.receiveAttach(Session_1_0.java:210)
at 
org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receiveAttach(AMQPConnection_1_0Impl.java:435)
at 
org.apache.qpid.server.protocol.v1_0.type.transport.Attach.invoke(Attach.java:366)
at 
org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:517)
at 
org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$receive$0(AMQPConnection_1_0Impl.java:469)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receive(AMQPConnection_1_0Impl.java:463)
at 
org.apache.qpid.server.protocol.v1_0.framing.FrameHandler.parse(FrameHandler.java:211)
at 
org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$received$11(AMQPConnection_1_0Impl.java:1316)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:1291)
at 
org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:134)
at 
org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:606)
at 
org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.processData(NonBlockingConnectionTLSDelegate.java:136)
at 
org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
at 
org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
at 
org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
at 
org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:563)
at 
org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:354)
at 
org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
at 
org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:521)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at 
org.apache.qpid.server.bytebuffer.QpidByteBuffer.lambda$null$0(QpidByteBuffer.java:1396)
at java.lang.Thread.run(Thread.java:748)
{noformat}

The second is if the {{Source}}  (again not mandatory) is omitted:
{noformat}
2017-10-21 18:19:52,556 DEBUG [IO-/10.211.55.13:52035] 
(o.a.q.s.p.v.f.FrameHandler) - RECV 89 bytes
2017-10-21 18:19:52,557 DEBUG [IO-/10.211.55.13:52035] (o.a.q.s.p.frame) - 
RECV[/10.211.55.13:52035|0] : 
Attach{name=c2c65769-7d3b-5440-b8fb-f00badbddd0d,handle=1,role=sender,target=Target{address=examples},initialDeliveryCount=0}
2017-10-21 18:19:52,562 DEBUG [IO-/10.211.55.13:52035] (o.a.q.s.p.frame) - 
SEND[/10.211.55.13:52035|0] : 
Attach{name=c2c65769-7d3b-5440-b8fb-f00badbddd0d,handle=1,role=receiver,target=Target{address=examples,durable=none,capabilities=[REJECT_UNROUTABLE,
 
DELAYED_DELIVERY]},unsettled={},maxMessageSize=10,offeredCapabilities=[REJECT_UNROUTABLE,
 DELAYED_DELIVERY],properties={}}
2017-10-21 18:19:52,565 DEBUG [IO-/10.211.55.13:52035] (o.a.q.s.p.frame) - 
SEND[/10.211.55.13:52035|0] : 
Flow{nextIncomingId=0,incomingWindow=8192,nextOutgoingId=0,outgoingWindow=2048,handle=1,deliveryCount=0,linkCredit=2,echo=false}

[jira] [Updated] (QPID-7981) [Java Broker] [AMQP1.0] Handle erroneous null termini cases

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7981:
-
Summary: [Java Broker] [AMQP1.0] Handle erroneous null termini cases  (was: 
[Java Broker] [AMQP1.0] Protocol layer assumes source and target are not null.)

> [Java Broker] [AMQP1.0] Handle erroneous null termini cases
> ---
>
> Key: QPID-7981
> URL: https://issues.apache.org/jira/browse/QPID-7981
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> Testing the Broker against Rhea's {{example/helloworld.js}} shows that the 
> AMQP 1.0 protocol layer fails in at least two places.
> The first is if the {{Target}} (not mandatory) is omitted from the incoming 
> attach.
> {noformat}
> 2017-10-21 18:13:20,609 DEBUG [IO-/10.211.55.13:52033] (o.a.q.s.p.frame) - 
> RECV[/10.211.55.13:52033|0] : 
> Attach{name=7e65e0a0-961f-e941-b42b-262380143f76,handle=0,role=receiver,source=Source{address=examples}}
> 2017-10-21 18:13:20,622 DEBUG [IO-/10.211.55.13:52033] (o.a.q.s.p.v.LinkImpl) 
> - Error attaching link
> java.lang.NullPointerException: null
>   at 
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.createConsumerTarget(SendingLinkEndpoint.java:209)
>   at 
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.attachReceived(SendingLinkEndpoint.java:636)
>   at 
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.establishLink(SendingLinkEndpoint.java:352)
>   at 
> org.apache.qpid.server.protocol.v1_0.AbstractLinkEndpoint.receiveAttach(AbstractLinkEndpoint.java:131)
>   at 
> org.apache.qpid.server.protocol.v1_0.LinkImpl.attach(LinkImpl.java:106)
>   at 
> org.apache.qpid.server.protocol.v1_0.Session_1_0.receiveAttach(Session_1_0.java:210)
>   at 
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receiveAttach(AMQPConnection_1_0Impl.java:435)
>   at 
> org.apache.qpid.server.protocol.v1_0.type.transport.Attach.invoke(Attach.java:366)
>   at 
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:517)
>   at 
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$receive$0(AMQPConnection_1_0Impl.java:469)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receive(AMQPConnection_1_0Impl.java:463)
>   at 
> org.apache.qpid.server.protocol.v1_0.framing.FrameHandler.parse(FrameHandler.java:211)
>   at 
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$received$11(AMQPConnection_1_0Impl.java:1316)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:1291)
>   at 
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:134)
>   at 
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:606)
>   at 
> org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.processData(NonBlockingConnectionTLSDelegate.java:136)
>   at 
> org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
>   at 
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
>   at 
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
>   at 
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:563)
>   at 
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:354)
>   at 
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
>   at 
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:521)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at 
> org.apache.qpid.server.bytebuffer.QpidByteBuffer.lambda$null$0(QpidByteBuffer.java:1396)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The second is if the {{Source}}  (again not mandatory) is omitted:
> {noformat}
> 2017-10-21 18:19:52,556 DEBUG [IO-/10.211.55.13:52035] 
> (o.a.q.s.p.v.f.FrameHandler) - RECV 89 bytes
> 2017-10-21 18:19:52,557 DEBUG [IO-/10.211.55.13:52035] (o.a.q.s.p.frame) - 
> RECV[/10.211.55.13:52035|0] : 
> Attach{name=c2c65769-7d3b-5440-b8fb-f00badbddd0d,handle=1,role=sender,target=Target{address=examples},initialDeliveryCount=0}
> 

[jira] [Updated] (PROTON-1651) Run spellchecker on proton-c code

[JIRA]

 [ 
https://issues.apache.org/jira/browse/PROTON-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Daněk updated PROTON-1651:
---
Attachment: (was: idea_dictionary.xml)

> Run spellchecker on proton-c code
> -
>
> Key: PROTON-1651
> URL: https://issues.apache.org/jira/browse/PROTON-1651
> Project: Qpid Proton
>  Issue Type: Task
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Priority: Minor
> Attachments: idea_dictionary.xml
>
>
> I've noticed some typos. I believe systematic approach in trying to get rid 
> of them is in order.



--
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] (PROTON-1651) Run spellchecker on proton-c code

[JIRA]

 [ 
https://issues.apache.org/jira/browse/PROTON-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Daněk updated PROTON-1651:
---
Attachment: idea_dictionary.xml

> Run spellchecker on proton-c code
> -
>
> Key: PROTON-1651
> URL: https://issues.apache.org/jira/browse/PROTON-1651
> Project: Qpid Proton
>  Issue Type: Task
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Priority: Minor
> Attachments: idea_dictionary.xml
>
>
> I've noticed some typos. I believe systematic approach in trying to get rid 
> of them is in order.



--
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-7910) [Java Broker] Improve qpid.stop script

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216794#comment-16216794
 ] 

ASF subversion and git services commented on QPID-7910:
---

Commit cd12e2dbcafba3013349df0858fdb07c9c6b30c7 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=cd12e2d ]

QPID-7910: [Qpid Broker-J] [Scripts] Revert switch from pgrep to ps as -F flag 
not supported on old pgrep versions.
Reinstate kill -9 if the processes don't go away sufficiently quickly.


> [Java Broker] Improve qpid.stop script
> --
>
> Key: QPID-7910
> URL: https://issues.apache.org/jira/browse/QPID-7910
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: qpid-stop, qpid-stop
>
>
> Java Broker qpid.stop  needs improvements:
> * it  currently tries to send SIGTERM and SIGKILL commands twice. It is 
> superfluous. Sending event once should be sufficient. 
> * we can use {{kill -0}} to verify the process instead of using ps
> * make {{$SLEEP_DELAY}} overridable from command line
> * script should be able to wait until Qpid processes are killed before exiting



--
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-7971) [Java Broker] [AMQP1.0] [AMQP0-9] Queue#ConsumerCountWithCredit statistic not decremented when consumer disconnects

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216792#comment-16216792
 ] 

ASF subversion and git services commented on QPID-7971:
---

Commit d1b74e424d2bf71004357cf7b3e968b68b1aed10 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=d1b74e4 ]

QPID-7971: [Qpid Broker-J] Ensure that consumers are notified no-work during 
consumer target close


> [Java Broker] [AMQP1.0] [AMQP0-9] Queue#ConsumerCountWithCredit statistic not 
> decremented when consumer disconnects
> ---
>
> Key: QPID-7971
> URL: https://issues.apache.org/jira/browse/QPID-7971
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> Running {{HelloWorld}} against the Java Broker, I notice that the 
> {{Queue#ConsumerCountWithCredit}} statistic does not return to zero after the 
> connection is closed.  The problem is not apparent -when using the older 
> protocols-.  Corrected: AMQP 0-9 also exhibits the same problem.
> I notice {{org.apache.qpid.server.consumer.AbstractConsumerTarget#close}} 
> clears {{_consumers}} then calls {{setNotifyWorkDesired}} which iterates 
> {{_consumers}}.
> I verified that v6.1 is not affected.



--
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] (PROTON-1651) Run spellchecker on proton-c code

[JIRA]

 [ 
https://issues.apache.org/jira/browse/PROTON-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Daněk updated PROTON-1651:
---
Attachment: idea_dictionary.xml

Attached dictionary from IntelliJ, which I used for spellchecking. I went 
through the list twice, probably should have at least one more pass. Idea does 
not automatically ignore keywords in some languages, but it is not all that bad 
experience..

> Run spellchecker on proton-c code
> -
>
> Key: PROTON-1651
> URL: https://issues.apache.org/jira/browse/PROTON-1651
> Project: Qpid Proton
>  Issue Type: Task
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Priority: Minor
> Attachments: idea_dictionary.xml
>
>
> I've noticed some typos. I believe systematic approach in trying to get rid 
> of them is in order.



--
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-7986) [Qpid Broker-J] [AMQP0-10] Remove redundant casts left by collapse of ServerConnection/SessionSession etc

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216793#comment-16216793
 ] 

ASF subversion and git services commented on QPID-7986:
---

Commit 8031475838849d6509510981975c3af0533e252f 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=8031475 ]

QPID-7986: [Qpid Broker-J] [AMQP0-10] Remove redundant casts left by collapse 
of ServerConnection/SessionSession etc. No functional changes.


> [Qpid Broker-J] [AMQP0-10] Remove redundant casts left by collapse of 
> ServerConnection/SessionSession etc
> -
>
> Key: QPID-7986
> URL: https://issues.apache.org/jira/browse/QPID-7986
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Trivial
> Fix For: qpid-java-broker-7.0.0
>
>
> Work of QPID-7622 (the collapse of AMQP 0-10 ServerConnection with Connection 
> etc) left behind a swath of redundant casts.  These can be mechanically 
> removed.  No functional changes.



--
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] (PROTON-1651) Run spellchecker on proton-c code

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216788#comment-16216788
 ] 

ASF GitHub Bot commented on PROTON-1651:


Github user jdanekrh commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/127#discussion_r146539425
  
--- Diff: proton-c/bindings/cpp/src/messaging_adapter.cpp ---
@@ -275,7 +275,7 @@ void on_transport_closed(messaging_handler& handler, 
pn_event_t* event) {
 // If the connection isn't open generate on_transport_open event
 // because we didn't generate it yet and the events won't match.
 pn_connection_t *conn = pn_event_connection(event);
-if (!conn || is_remote_unititialised(pn_connection_state(conn))) {
+if (!conn || is_remote_uninitialized(pn_connection_state(conn))) {
--- End diff --

highlighting code change


> Run spellchecker on proton-c code
> -
>
> Key: PROTON-1651
> URL: https://issues.apache.org/jira/browse/PROTON-1651
> Project: Qpid Proton
>  Issue Type: Task
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Priority: Minor
>
> I've noticed some typos. I believe systematic approach in trying to get rid 
> of them is in order.



--
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-proton pull request #127: PROTON-1651 Fix typos found by the spellcheck...

[jdanekrh]

Github user jdanekrh commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/127#discussion_r146539425
  
--- Diff: proton-c/bindings/cpp/src/messaging_adapter.cpp ---
@@ -275,7 +275,7 @@ void on_transport_closed(messaging_handler& handler, 
pn_event_t* event) {
 // If the connection isn't open generate on_transport_open event
 // because we didn't generate it yet and the events won't match.
 pn_connection_t *conn = pn_event_connection(event);
-if (!conn || is_remote_unititialised(pn_connection_state(conn))) {
+if (!conn || is_remote_uninitialized(pn_connection_state(conn))) {
--- End diff --

highlighting code change


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1651) Run spellchecker on proton-c code

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216787#comment-16216787
 ] 

ASF GitHub Bot commented on PROTON-1651:


Github user jdanekrh commented on the issue:

https://github.com/apache/qpid-proton/pull/127
  
What is blech?

 >   transport_consume(transport);// blech - testBindAfterOpen
 


> Run spellchecker on proton-c code
> -
>
> Key: PROTON-1651
> URL: https://issues.apache.org/jira/browse/PROTON-1651
> Project: Qpid Proton
>  Issue Type: Task
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Priority: Minor
>
> I've noticed some typos. I believe systematic approach in trying to get rid 
> of them is in order.



--
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-proton issue #127: PROTON-1651 Fix typos found by the spellchecker

[jdanekrh]

Github user jdanekrh commented on the issue:

https://github.com/apache/qpid-proton/pull/127
  
What is blech?

 >   transport_consume(transport);// blech - testBindAfterOpen
 


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1651) Run spellchecker on proton-c code

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216784#comment-16216784
 ] 

ASF GitHub Bot commented on PROTON-1651:


Github user jdanekrh commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/127#discussion_r146539063
  
--- Diff: tests/python/proton_tests/messenger.py ---
@@ -629,7 +629,7 @@ def testDefaultRewriteSUHPN(self):
   def testDefaultRewriteSUPHPN(self):
 self._testRewrite("amqp://user:pass@original:123/name", 
"amqp://original:123/name")
 
-  def testRewriteSupress(self):
+  def testRewriteSuppress(self):
--- End diff --

highlighting code chabge


> Run spellchecker on proton-c code
> -
>
> Key: PROTON-1651
> URL: https://issues.apache.org/jira/browse/PROTON-1651
> Project: Qpid Proton
>  Issue Type: Task
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Priority: Minor
>
> I've noticed some typos. I believe systematic approach in trying to get rid 
> of them is in order.



--
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] (PROTON-1651) Run spellchecker on proton-c code

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216781#comment-16216781
 ] 

ASF GitHub Bot commented on PROTON-1651:


Github user jdanekrh commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/127#discussion_r146538990
  
--- Diff: tests/python/proton_tests/message.py ---
@@ -69,7 +69,7 @@ def testPriority(self):
   def testTtl(self):
 self._test("ttl", 0, range(12345, 54321))
 
-  def testFirstAquirer(self):
+  def testFirstAcquirer(self):
--- End diff --

highlighting code change


> Run spellchecker on proton-c code
> -
>
> Key: PROTON-1651
> URL: https://issues.apache.org/jira/browse/PROTON-1651
> Project: Qpid Proton
>  Issue Type: Task
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Priority: Minor
>
> I've noticed some typos. I believe systematic approach in trying to get rid 
> of them is in order.



--
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-proton pull request #127: PROTON-1651 Fix typos found by the spellcheck...

[jdanekrh]

Github user jdanekrh commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/127#discussion_r146539063
  
--- Diff: tests/python/proton_tests/messenger.py ---
@@ -629,7 +629,7 @@ def testDefaultRewriteSUHPN(self):
   def testDefaultRewriteSUPHPN(self):
 self._testRewrite("amqp://user:pass@original:123/name", 
"amqp://original:123/name")
 
-  def testRewriteSupress(self):
+  def testRewriteSuppress(self):
--- End diff --

highlighting code chabge


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1651) Run spellchecker on proton-c code

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216776#comment-16216776
 ] 

ASF GitHub Bot commented on PROTON-1651:


Github user jdanekrh commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/127#discussion_r146538752
  
--- Diff: proton-c/bindings/ruby/lib/core/ssl.rb ---
@@ -126,25 +126,25 @@ def cipher_name
 end
 
 # Returns the name of the SSL protocol that is currently active, or
-# returns nil if SSL is nota ctive. Not that the protocol may change 
over
-# time due to renegotation.
+# returns nil if SSL is not active. Not that the protocol may change 
over
+# time due to renegotiation.
 #
 # @return [String, nil] The protocol name.
 #
 def protocol_name
   rc, name = Cproton.pn_ssl_get_protocol_name(@impl, 128)
-  retur name if rc
+  return name if rc
--- End diff --

highlighting code change


> Run spellchecker on proton-c code
> -
>
> Key: PROTON-1651
> URL: https://issues.apache.org/jira/browse/PROTON-1651
> Project: Qpid Proton
>  Issue Type: Task
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Priority: Minor
>
> I've noticed some typos. I believe systematic approach in trying to get rid 
> of them is in order.



--
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] (PROTON-1651) Run spellchecker on proton-c code

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216780#comment-16216780
 ] 

ASF GitHub Bot commented on PROTON-1651:


Github user jdanekrh commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/127#discussion_r146538930
  
--- Diff: proton-c/bindings/ruby/lib/reactor/container.rb ---
@@ -155,7 +155,7 @@ def create_sender(context, opts = {})
 sender.source.address = opts[:source] if !opts[:source].nil?
 sender.target.address = target if target
 sender.handler = opts[:handler] if !opts[:handler].nil?
-sender.tag_generator = opts[:tag_generator] if 
!opts[:tag_gnenerator].nil?
+sender.tag_generator = opts[:tag_generator] if 
!opts[:tag_generator].nil?
--- End diff --

highlighting code change


> Run spellchecker on proton-c code
> -
>
> Key: PROTON-1651
> URL: https://issues.apache.org/jira/browse/PROTON-1651
> Project: Qpid Proton
>  Issue Type: Task
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Priority: Minor
>
> I've noticed some typos. I believe systematic approach in trying to get rid 
> of them is in order.



--
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-proton pull request #127: PROTON-1651 Fix typos found by the spellcheck...

[jdanekrh]

Github user jdanekrh commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/127#discussion_r146538990
  
--- Diff: tests/python/proton_tests/message.py ---
@@ -69,7 +69,7 @@ def testPriority(self):
   def testTtl(self):
 self._test("ttl", 0, range(12345, 54321))
 
-  def testFirstAquirer(self):
+  def testFirstAcquirer(self):
--- End diff --

highlighting code change


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-proton pull request #127: PROTON-1651 Fix typos found by the spellcheck...

[jdanekrh]

Github user jdanekrh commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/127#discussion_r146538930
  
--- Diff: proton-c/bindings/ruby/lib/reactor/container.rb ---
@@ -155,7 +155,7 @@ def create_sender(context, opts = {})
 sender.source.address = opts[:source] if !opts[:source].nil?
 sender.target.address = target if target
 sender.handler = opts[:handler] if !opts[:handler].nil?
-sender.tag_generator = opts[:tag_generator] if 
!opts[:tag_gnenerator].nil?
+sender.tag_generator = opts[:tag_generator] if 
!opts[:tag_generator].nil?
--- End diff --

highlighting code change


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1651) Run spellchecker on proton-c code

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216778#comment-16216778
 ] 

ASF GitHub Bot commented on PROTON-1651:


Github user jdanekrh commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/127#discussion_r146538833
  
--- Diff: proton-c/bindings/ruby/lib/handler/endpoint_state_handler.rb ---
@@ -164,7 +164,7 @@ def on_link_error(event)
 Qpid::Proton::Event.dispatch(@delegate, :on_link_error, event)
   else
 self.log_error(event.link, "link")
-event.conneciton.close
+event.connection.close
--- End diff --

higlighting code change


> Run spellchecker on proton-c code
> -
>
> Key: PROTON-1651
> URL: https://issues.apache.org/jira/browse/PROTON-1651
> Project: Qpid Proton
>  Issue Type: Task
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Priority: Minor
>
> I've noticed some typos. I believe systematic approach in trying to get rid 
> of them is in order.



--
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-proton pull request #127: PROTON-1651 Fix typos found by the spellcheck...

[jdanekrh]

Github user jdanekrh commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/127#discussion_r146538833
  
--- Diff: proton-c/bindings/ruby/lib/handler/endpoint_state_handler.rb ---
@@ -164,7 +164,7 @@ def on_link_error(event)
 Qpid::Proton::Event.dispatch(@delegate, :on_link_error, event)
   else
 self.log_error(event.link, "link")
-event.conneciton.close
+event.connection.close
--- End diff --

higlighting code change


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-proton pull request #127: PROTON-1651 Fix typos found by the spellcheck...

[jdanekrh]

Github user jdanekrh commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/127#discussion_r146538752
  
--- Diff: proton-c/bindings/ruby/lib/core/ssl.rb ---
@@ -126,25 +126,25 @@ def cipher_name
 end
 
 # Returns the name of the SSL protocol that is currently active, or
-# returns nil if SSL is nota ctive. Not that the protocol may change 
over
-# time due to renegotation.
+# returns nil if SSL is not active. Not that the protocol may change 
over
+# time due to renegotiation.
 #
 # @return [String, nil] The protocol name.
 #
 def protocol_name
   rc, name = Cproton.pn_ssl_get_protocol_name(@impl, 128)
-  retur name if rc
+  return name if rc
--- End diff --

highlighting code change


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1651) Run spellchecker on proton-c code

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216775#comment-16216775
 ] 

ASF GitHub Bot commented on PROTON-1651:


Github user jdanekrh commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/127#discussion_r146538680
  
--- Diff: proton-c/bindings/ruby/lib/core/connection.rb ---
@@ -201,7 +201,7 @@ def remote_desired_capabilities
 # @return [Data] The remote properties.
 #
 def remote_properties
-  data_to_object(Cproton.pn_connection_remote_properites(@impl))
+  data_to_object(Cproton.pn_connection_remote_properties(@impl))
--- End diff --

highlighting code change


> Run spellchecker on proton-c code
> -
>
> Key: PROTON-1651
> URL: https://issues.apache.org/jira/browse/PROTON-1651
> Project: Qpid Proton
>  Issue Type: Task
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Priority: Minor
>
> I've noticed some typos. I believe systematic approach in trying to get rid 
> of them is in order.



--
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-proton pull request #127: PROTON-1651 Fix typos found by the spellcheck...

[jdanekrh]

Github user jdanekrh commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/127#discussion_r146538680
  
--- Diff: proton-c/bindings/ruby/lib/core/connection.rb ---
@@ -201,7 +201,7 @@ def remote_desired_capabilities
 # @return [Data] The remote properties.
 #
 def remote_properties
-  data_to_object(Cproton.pn_connection_remote_properites(@impl))
+  data_to_object(Cproton.pn_connection_remote_properties(@impl))
--- End diff --

highlighting code change


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1651) Run spellchecker on proton-c code

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216774#comment-16216774
 ] 

ASF GitHub Bot commented on PROTON-1651:


Github user jdanekrh commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/127#discussion_r146538625
  
--- Diff: proton-c/bindings/javascript/module.js ---
@@ -327,7 +327,7 @@ Module.EventDispatch = new function() { // Note the use 
of new to create a Singl
  * actually free and remove the selectable is deferred until 
next
  * time round the (internal JavaScript) event loop. This 
turned out
  * to be necessary because in some cases the ws WebSocket 
library
- * calls the onclose callback (concurrently!!) before the 
onmessage
+ * calls the on_close callback (concurrently!!) before the 
on_message
--- End diff --

couldn't find what are correct names for these callbacks, maybe I got it 
wrong


> Run spellchecker on proton-c code
> -
>
> Key: PROTON-1651
> URL: https://issues.apache.org/jira/browse/PROTON-1651
> Project: Qpid Proton
>  Issue Type: Task
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Priority: Minor
>
> I've noticed some typos. I believe systematic approach in trying to get rid 
> of them is in order.



--
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-proton pull request #127: PROTON-1651 Fix typos found by the spellcheck...

[jdanekrh]

Github user jdanekrh commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/127#discussion_r146538625
  
--- Diff: proton-c/bindings/javascript/module.js ---
@@ -327,7 +327,7 @@ Module.EventDispatch = new function() { // Note the use 
of new to create a Singl
  * actually free and remove the selectable is deferred until 
next
  * time round the (internal JavaScript) event loop. This 
turned out
  * to be necessary because in some cases the ws WebSocket 
library
- * calls the onclose callback (concurrently!!) before the 
onmessage
+ * calls the on_close callback (concurrently!!) before the 
on_message
--- End diff --

couldn't find what are correct names for these callbacks, maybe I got it 
wrong


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1651) Run spellchecker on proton-c code

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216773#comment-16216773
 ] 

ASF GitHub Bot commented on PROTON-1651:


Github user jdanekrh commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/127#discussion_r146538458
  
--- Diff: proton-c/bindings/cpp/src/interop_test.cpp ---
@@ -57,8 +57,8 @@ void test_data_ostream() {
 ASSERT_EQUAL("true, false, 42, 42, -42, 12345, -12345, 12345, -12345, 
0.125, 0.125", str(dt));
 }
 
-// Test extracting to exact AMQP types works corectly, extrating to 
invalid types fails.
-void test_decoder_primitves_exact() {
+// Test extracting to exact AMQP types works correctly, extracting to 
invalid types fails.
+void test_decoder_primitives_exact() {
--- End diff --

highlighting change to code


> Run spellchecker on proton-c code
> -
>
> Key: PROTON-1651
> URL: https://issues.apache.org/jira/browse/PROTON-1651
> Project: Qpid Proton
>  Issue Type: Task
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Priority: Minor
>
> I've noticed some typos. I believe systematic approach in trying to get rid 
> of them is in order.



--
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] (PROTON-1651) Run spellchecker on proton-c code

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216772#comment-16216772
 ] 

ASF GitHub Bot commented on PROTON-1651:


Github user jdanekrh commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/127#discussion_r146538275
  
--- Diff: examples/cpp/multithreaded_client.cpp ---
@@ -47,7 +47,7 @@
 #include 
 #include 
 
-// Lock output from threads to avoid scramblin
+// Lock output from threads to avoid scrambling
--- End diff --

Is this correct fix?


> Run spellchecker on proton-c code
> -
>
> Key: PROTON-1651
> URL: https://issues.apache.org/jira/browse/PROTON-1651
> Project: Qpid Proton
>  Issue Type: Task
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Priority: Minor
>
> I've noticed some typos. I believe systematic approach in trying to get rid 
> of them is in order.



--
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-proton pull request #127: PROTON-1651 Fix typos found by the spellcheck...

[jdanekrh]

Github user jdanekrh commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/127#discussion_r146538458
  
--- Diff: proton-c/bindings/cpp/src/interop_test.cpp ---
@@ -57,8 +57,8 @@ void test_data_ostream() {
 ASSERT_EQUAL("true, false, 42, 42, -42, 12345, -12345, 12345, -12345, 
0.125, 0.125", str(dt));
 }
 
-// Test extracting to exact AMQP types works corectly, extrating to 
invalid types fails.
-void test_decoder_primitves_exact() {
+// Test extracting to exact AMQP types works correctly, extracting to 
invalid types fails.
+void test_decoder_primitives_exact() {
--- End diff --

highlighting change to code


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-proton pull request #127: PROTON-1651 Fix typos found by the spellcheck...

[jdanekrh]

Github user jdanekrh commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/127#discussion_r146538275
  
--- Diff: examples/cpp/multithreaded_client.cpp ---
@@ -47,7 +47,7 @@
 #include 
 #include 
 
-// Lock output from threads to avoid scramblin
+// Lock output from threads to avoid scrambling
--- End diff --

Is this correct fix?


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1651) Run spellchecker on proton-c code

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216771#comment-16216771
 ] 

ASF GitHub Bot commented on PROTON-1651:


GitHub user jdanekrh opened a pull request:

https://github.com/apache/qpid-proton/pull/127

PROTON-1651 Fix typos found by the spellchecker

> injecter  proton.Injecter
* injector, maybe. this is public api, so probably should not be touched, 
though

> Now that we've covered the basics with the archetypical hello world app, 
let's look at some more interesting examples.

* archetypal, maybe?
* decreffed
** how many f's, proton has f and ff both

> ractor = Reactor.wrap(self.reactor_impl)
* intentional?

I've been probably overzealous what I now realise is just british spelling. 
Found that deserialised with s is just alternative spelling, I can revert these 
instances...

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jdanekrh/qpid-proton jd_typos

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-proton/pull/127.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #127


commit 3ee744ca62687a66178d32e36746930835ec7db5
Author: Jiri Danek 
Date:   2017-10-24T06:49:17Z

PROTON-1651 Fix typos found by the spellchecker




> Run spellchecker on proton-c code
> -
>
> Key: PROTON-1651
> URL: https://issues.apache.org/jira/browse/PROTON-1651
> Project: Qpid Proton
>  Issue Type: Task
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Priority: Minor
>
> I've noticed some typos. I believe systematic approach in trying to get rid 
> of them is in order.



--
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-proton pull request #127: PROTON-1651 Fix typos found by the spellcheck...

[jdanekrh]

GitHub user jdanekrh opened a pull request:

https://github.com/apache/qpid-proton/pull/127

PROTON-1651 Fix typos found by the spellchecker

> injecter  proton.Injecter
* injector, maybe. this is public api, so probably should not be touched, 
though

> Now that we've covered the basics with the archetypical hello world app, 
let's look at some more interesting examples.

* archetypal, maybe?
* decreffed
** how many f's, proton has f and ff both

> ractor = Reactor.wrap(self.reactor_impl)
* intentional?

I've been probably overzealous what I now realise is just british spelling. 
Found that deserialised with s is just alternative spelling, I can revert these 
instances...

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jdanekrh/qpid-proton jd_typos

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-proton/pull/127.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #127


commit 3ee744ca62687a66178d32e36746930835ec7db5
Author: Jiri Danek 
Date:   2017-10-24T06:49:17Z

PROTON-1651 Fix typos found by the spellchecker




---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPID-7986) [Qpid Broker-J] [AMQP0-10] Remove redundant casts left by collapse of ServerConnection/SessionSession etc

[Keith Wall (JIRA)]

Keith Wall created QPID-7986:


 Summary: [Qpid Broker-J] [AMQP0-10] Remove redundant casts left by 
collapse of ServerConnection/SessionSession etc
 Key: QPID-7986
 URL: https://issues.apache.org/jira/browse/QPID-7986
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker
Reporter: Keith Wall
Priority: Trivial
 Fix For: qpid-java-broker-7.0.0


Work of QPID-7622 (the collapse of AMQP 0-10 ServerConnection with Connection 
etc) left behind a swath of redundant casts.  These can be mechanically 
removed.  No functional changes.



--
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] (PROTON-1651) Run spellchecker on proton-c code

[JIRA]

 [ 
https://issues.apache.org/jira/browse/PROTON-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Daněk updated PROTON-1651:
---
Priority: Minor  (was: Major)

> Run spellchecker on proton-c code
> -
>
> Key: PROTON-1651
> URL: https://issues.apache.org/jira/browse/PROTON-1651
> Project: Qpid Proton
>  Issue Type: Task
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Priority: Minor
>
> I've noticed some typos. I believe systematic approach in trying to get rid 
> of them is in order.



--
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-7971) [Java Broker] [AMQP1.0] [AMQP0-9] Queue#ConsumerCountWithCredit statistic not decremented when consumer disconnects

[Keith Wall (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216601#comment-16216601
 ] 

Keith Wall commented on QPID-7971:
--

The 0-10 path is different because on session detach, the 
ConsumerTarget_0_10#stop is called with clears credit then tells the consumers 
that {{setNotifyWorkDesired(false)}}.  This masks the problem.  The defect is 
actually in AbstractConsumerTarget#close which clears {{_consumers}} before 
calling {{setNotifyWorkDesired}}.

> [Java Broker] [AMQP1.0] [AMQP0-9] Queue#ConsumerCountWithCredit statistic not 
> decremented when consumer disconnects
> ---
>
> Key: QPID-7971
> URL: https://issues.apache.org/jira/browse/QPID-7971
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> Running {{HelloWorld}} against the Java Broker, I notice that the 
> {{Queue#ConsumerCountWithCredit}} statistic does not return to zero after the 
> connection is closed.  The problem is not apparent -when using the older 
> protocols-.  Corrected: AMQP 0-9 also exhibits the same problem.
> I notice {{org.apache.qpid.server.consumer.AbstractConsumerTarget#close}} 
> clears {{_consumers}} then calls {{setNotifyWorkDesired}} which iterates 
> {{_consumers}}.
> I verified that v6.1 is not affected.



--
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-7971) [Java Broker] [AMQP1.0] [AMQP0-9] Queue#ConsumerCountWithCredit statistic not decremented when consumer disconnects

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7971:
-
Summary: [Java Broker] [AMQP1.0] [AMQP0-9] Queue#ConsumerCountWithCredit 
statistic not decremented when consumer disconnects  (was: [Java Broker] 
[AMQP1.0] Queue#ConsumerCountWithCredit statistic not decremented when consumer 
disconnects)

> [Java Broker] [AMQP1.0] [AMQP0-9] Queue#ConsumerCountWithCredit statistic not 
> decremented when consumer disconnects
> ---
>
> Key: QPID-7971
> URL: https://issues.apache.org/jira/browse/QPID-7971
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> Running {{HelloWorld}} against the Java Broker, I notice that the 
> {{Queue#ConsumerCountWithCredit}} statistic does not return to zero after the 
> connection is closed.  The problem is not apparent -when using the older 
> protocols-.  Corrected: AMQP 0-9 also exhibits the same problem.
> I notice {{org.apache.qpid.server.consumer.AbstractConsumerTarget#close}} 
> clears {{_consumers}} then calls {{setNotifyWorkDesired}} which iterates 
> {{_consumers}}.
> I verified that v6.1 is not affected.



--
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] (PROTON-1651) Run spellchecker on proton-c code

[JIRA]

Jiri Daněk created PROTON-1651:
--

 Summary: Run spellchecker on proton-c code
 Key: PROTON-1651
 URL: https://issues.apache.org/jira/browse/PROTON-1651
 Project: Qpid Proton
  Issue Type: Task
Affects Versions: proton-c-0.18.0
Reporter: Jiri Daněk


I've noticed some typos. I believe systematic approach in trying to get rid of 
them is in order.



--
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