[jira] [Updated] (DISPATCH-37) Various memory leaks

[Pavel Moravec (JIRA)]

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

Pavel Moravec updated DISPATCH-37:
--

Attachment: out01.log

valgrind output from a minute run:

==2761== LEAK SUMMARY:
==2761==definitely lost: 21,689 bytes in 95 blocks
==2761==indirectly lost: 152,305 bytes in 953 blocks
==2761==  possibly lost: 807,891 bytes in 4,451 blocks
==2761==still reachable: 1,518,763 bytes in 12,877 blocks
==2761== suppressed: 0 bytes in 0 blocks


 Various memory leaks
 

 Key: DISPATCH-37
 URL: https://issues.apache.org/jira/browse/DISPATCH-37
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Container
Affects Versions: 0.1
Reporter: Pavel Moravec
 Attachments: out01.log


 Valgrind reports various memory leaks after very basic usage of Dispatch 
 router. For basic scenario, have 2 routers A-B and send messages from 
 bouncing producer connected to A to a bouncing consumer connected to B. 
 Attached is valgrind output for that.
 Some particular memory leaks to be commented later on.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (DISPATCH-37) Various memory leaks

[Pavel Moravec (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949191#comment-13949191
 ] 

Pavel Moravec commented on DISPATCH-37:
---

One particular memory leak: in setup_incoming_link:

Single dispatch router running and connecting+disconnecting any link from a 
client. valgrind logs:

==4570== 64 bytes in 2 blocks are definitely lost in loss record 890 of 2,662
==4570==at 0x4A06409: malloc (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==4570==by 0x4C1FD6E: qd_alloc (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C2D821: new_qd_router_link_t (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C3031D: router_incoming_link_handler (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C238FF: setup_incoming_link (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C23CDE: process_handler (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C2407A: handler (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C35103: process_connector (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C35662: thread_run (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x3D6B607C52: start_thread (pthread_create.c:308)
==4570==by 0x3D6B2F5DBC: clone (clone.S:113)

==4570== 3,672 bytes in 54 blocks are possibly lost in loss record 2,512 of 
2,662
==4570==at 0x4A06409: malloc (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==4570==by 0x4C201BC: qd_alloc (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C23599: new_qd_link_t (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C2387D: setup_incoming_link (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C23CDE: process_handler (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C2407A: handler (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C35103: process_connector (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C35662: thread_run (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C3621D: qd_server_run (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x401317: main (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/router/qdrouterd)

==4570== 4,692 (4,624 direct, 68 indirect) bytes in 68 blocks are definitely 
lost in loss record 2,535 of 2,662
==4570==at 0x4A06409: malloc (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==4570==by 0x4C201BC: qd_alloc (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C23599: new_qd_link_t (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C2387D: setup_incoming_link (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C23CDE: process_handler (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C2407A: handler (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C35103: process_connector (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C35662: thread_run (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C3621D: qd_server_run (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x401317: main (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/router/qdrouterd)

==4570== 7,816 (64 direct, 7,752 indirect) bytes in 2 blocks are definitely 
lost in loss record 2,576 of 2,662
==4570==at 0x4A06409: malloc (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==4570==by 0x4C1FD6E: qd_alloc (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C23599: new_qd_link_t (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C2387D: setup_incoming_link (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C23CDE: process_handler (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C2407A: handler (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C35103: process_connector (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x4C35662: thread_run (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==4570==by 0x3D6B607C52: start_thread (pthread_create.c:308)
==4570==by 0x3D6B2F5DBC: clone 

[jira] [Commented] (DISPATCH-37) Various memory leaks

[Pavel Moravec (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949299#comment-13949299
 ] 

Pavel Moravec commented on DISPATCH-37:
---

Another particular memory leak: by connecting and disconnecting another router 
to an inter-router listener:

==8432== 31,808 (64 direct, 31,744 indirect) bytes in 2 blocks are definitely 
lost in loss record 2,663 of 2,675
==8432==at 0x4A06409: malloc (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==8432==by 0x4C1FD6E: qd_alloc (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==8432==by 0x4C2142B: new_qd_composed_field_t (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==8432==by 0x4C21D01: qd_compose (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==8432==by 0x4C2EDF9: router_annotate_message (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==8432==by 0x4C2FC76: router_rx_handler (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==8432==by 0x4C23A57: do_receive (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==8432==by 0x4C23D2C: process_handler (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==8432==by 0x4C2407A: handler (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==8432==by 0x4C35103: process_connector (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==8432==by 0x4C35662: thread_run (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==8432==by 0x3D6B607C52: start_thread (pthread_create.c:308)


 Various memory leaks
 

 Key: DISPATCH-37
 URL: https://issues.apache.org/jira/browse/DISPATCH-37
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Container
Affects Versions: 0.1
Reporter: Pavel Moravec
 Attachments: out01.log


 Valgrind reports various memory leaks after very basic usage of Dispatch 
 router. For basic scenario, have 2 routers A-B and send messages from 
 bouncing producer connected to A to a bouncing consumer connected to B. 
 Attached is valgrind output for that.
 Some particular memory leaks to be commented later on.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (DISPATCH-37) Various memory leaks

[Pavel Moravec (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949375#comment-13949375
 ] 

Pavel Moravec commented on DISPATCH-37:
---

Another particular leak: when sending messages (coming from to a local mobile 
subscriber:

==9009== 47,712 (96 direct, 47,616 indirect) bytes in 3 blocks are definitely 
lost in loss record 2,617 of 2,619
==9009==at 0x4A06409: malloc (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==9009==by 0x4C1FD6E: qd_alloc (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==9009==by 0x4C2142B: new_qd_composed_field_t (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==9009==by 0x4C21D01: qd_compose (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==9009==by 0x4C2C420: qd_python_send (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==9009==by 0x3D6D2DDCED: PyEval_EvalFrameEx (ceval.c:4098)
==9009==by 0x3D6D2DD80B: PyEval_EvalFrameEx (ceval.c:4184)
==9009==by 0x3D6D2DD80B: PyEval_EvalFrameEx (ceval.c:4184)
==9009==by 0x3D6D2DEC7C: PyEval_EvalCodeEx (ceval.c:3330)
==9009==by 0x3D6D26DC9F: function_call (funcobject.c:526)
==9009==by 0x3D6D249DD2: PyObject_Call (abstract.c:2529)
==9009==by 0x3D6D258554: instancemethod_call (classobject.c:2602)

==9009== 33,120 (96 direct, 33,024 indirect) bytes in 3 blocks are definitely 
lost in loss record 2,611 of 2,619
==9009==at 0x4A06409: malloc (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==9009==by 0x4C1FD6E: qd_alloc (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==9009==by 0x4C20E2D: new_qd_bitmask_t (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==9009==by 0x4C20E98: qd_bitmask (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==9009==by 0x4C32510: qd_router_send (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==9009==by 0x4C327AF: qd_router_send2 (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==9009==by 0x4C2C5A9: qd_python_send (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==9009==by 0x3D6D2DDCED: PyEval_EvalFrameEx (ceval.c:4098)
==9009==by 0x3D6D2DD80B: PyEval_EvalFrameEx (ceval.c:4184)
==9009==by 0x3D6D2DD80B: PyEval_EvalFrameEx (ceval.c:4184)
==9009==by 0x3D6D2DEC7C: PyEval_EvalCodeEx (ceval.c:3330)
==9009==by 0x3D6D26DC9F: function_call (funcobject.c:526)

==9009== 8,480 (32 direct, 8,448 indirect) bytes in 1 blocks are definitely 
lost in loss record 2,557 of 2,619
==9009==at 0x4A06409: malloc (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==9009==by 0x4C1FD6E: qd_alloc (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==9009==by 0x4C26A8D: new_qd_field_iterator_t (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==9009==by 0x4C2702B: qd_field_iterator_string (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==9009==by 0x4C32794: qd_router_send2 (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==9009==by 0x4C2C5A9: qd_python_send (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==9009==by 0x3D6D2DDCED: PyEval_EvalFrameEx (ceval.c:4098)
==9009==by 0x3D6D2DD80B: PyEval_EvalFrameEx (ceval.c:4184)
==9009==by 0x3D6D2DD80B: PyEval_EvalFrameEx (ceval.c:4184)
==9009==by 0x3D6D2DEC7C: PyEval_EvalCodeEx (ceval.c:3330)
==9009==by 0x3D6D26DC9F: function_call (funcobject.c:526)
==9009==by 0x3D6D249DD2: PyObject_Call (abstract.c:2529)

==9009== 1,080 bytes in 18 blocks are possibly lost in loss record 2,312 of 
2,619
==9009==at 0x4A06409: malloc (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==9009==by 0x4C201BC: qd_alloc (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==9009==by 0x4C27E59: new_qd_message_t (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==9009==by 0x4C28E15: qd_message (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==9009==by 0x4C29451: qd_message_receive (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==9009==by 0x4C2FA0A: router_rx_handler (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==9009==by 0x4C23A57: do_receive (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==9009==by 0x4C23D2C: process_handler (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==9009==by 0x4C2407A: handler (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==9009==by 0x4C35103: process_connector (in 
/home/pmoravec/dispatch-trunk/trunk/BLD/libqpid-dispatch.so.0.1)
==9009==by 0x4C35662: thread_run (in 

[jira] [Created] (QPID-5643) qpid-route route map does not pass credentials to other brokers in the route map

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5643:
---

 Summary: qpid-route route map does not pass credentials to other 
brokers in the route map
 Key: QPID-5643
 URL: https://issues.apache.org/jira/browse/QPID-5643
 Project: Qpid
  Issue Type: Bug
  Components: Python Tools
Affects Versions: 0.26
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Trivial


Tool qpid-route supports only ANONYMOUS sasl mech in method mapRoutes.

This results as (although both broker nodes are running with very same ACL 
rules and qpid.sasldb):

ExecutionException(error_code=403, command_id=serial(0), class_code=8, 
command_code=1, field_index=0, description=u'unauthorized-access: ACL denied 
queue create request from anonymous@QPID (qpid/broker/SessionAdapter.cpp:349)', 
error_info={}, channel=1, id=serial(0))

The reason is because when qpid-route queries subsequent brokers in the 
federation topology, it does not set any credentials (esp. those used for the 
first broker).

Trivial fix to follow just passes the credentials and other connection options 
to any further broker that the tool connects to.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (QPID-5643) qpid-route route map does not pass credentials to other brokers in the route map

[Pavel Moravec (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-5643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13944976#comment-13944976
 ] 

Pavel Moravec commented on QPID-5643:
-

Reproducer (assuming ~/qpidd.sasldb is proper SASL db with guest/guest 
credentials, and /etc/sasl2/qpidd.conf points to /var/lib/qpidd/qpidd.sasldb):

pkill -9 qpidd
rm qpidd.*.log
echo acl allow guest@QPID all all
acl deny all all  ~/qpidd.acl
cp ~/qpidd.sasldb /var/lib/qpidd

run_qpidd() {
port=$1
rm -rf _${port}
mkdir _${port}
nohup qpidd --port=$port --log-to-file=qpidd.$port.log --data-dir=_${port} 
--auth=yes --log-to-stderr=no --acl-file=/root/qpidd.acl $@ 
}

run_qpidd 5001 --trace
run_qpidd 5002 --trace
sleep 3

qpid-route route add guest/guest@localhost:5001 guest/guest@localhost:5002 
amq.fanout amq.fanout

qpid-route route map guest/guest@localhost:5001



Current output:
Finding Linked Brokers:
guest/guest@localhost:5001... Ok
localhost:5002... ExecutionException(error_code=403, command_id=serial(0), 
class_code=8, command_code=1, field_index=0, description=u'unauthorized-access: 
ACL denied queue create request from anonymous@QPID 
(/builddir/build/BUILD/qpid-0.22/cpp/src/qpid/broker/Broker.cpp:1316)', 
error_info={}, channel=1, id=serial(0))



Expected output:
Finding Linked Brokers:
guest/guest@localhost:5001... Ok
localhost:5002... Ok

Dynamic Routes:
  none found

Static Routes:

  localhost:5001(ex=amq.fanout) = localhost:5002(ex=amq.fanout) key=amq.fanout





 qpid-route route map does not pass credentials to other brokers in the 
 route map
 

 Key: QPID-5643
 URL: https://issues.apache.org/jira/browse/QPID-5643
 Project: Qpid
  Issue Type: Bug
  Components: Python Tools
Affects Versions: 0.26
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Trivial

 Tool qpid-route supports only ANONYMOUS sasl mech in method mapRoutes.
 This results as (although both broker nodes are running with very same ACL 
 rules and qpid.sasldb):
 ExecutionException(error_code=403, command_id=serial(0), class_code=8, 
 command_code=1, field_index=0, description=u'unauthorized-access: ACL denied 
 queue create request from anonymous@QPID 
 (qpid/broker/SessionAdapter.cpp:349)', error_info={}, channel=1, id=serial(0))
 The reason is because when qpid-route queries subsequent brokers in the 
 federation topology, it does not set any credentials (esp. those used for the 
 first broker).
 Trivial fix to follow just passes the credentials and other connection 
 options to any further broker that the tool connects to.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Closed] (QPID-5643) qpid-route route map does not pass credentials to other brokers in the route map

[Pavel Moravec (JIRA)]

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

Pavel Moravec closed QPID-5643.
---

   Resolution: Fixed
Fix Version/s: 0.28

 qpid-route route map does not pass credentials to other brokers in the 
 route map
 

 Key: QPID-5643
 URL: https://issues.apache.org/jira/browse/QPID-5643
 Project: Qpid
  Issue Type: Bug
  Components: Python Tools
Affects Versions: 0.26
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Trivial
 Fix For: 0.28


 Tool qpid-route supports only ANONYMOUS sasl mech in method mapRoutes.
 This results as (although both broker nodes are running with very same ACL 
 rules and qpid.sasldb):
 ExecutionException(error_code=403, command_id=serial(0), class_code=8, 
 command_code=1, field_index=0, description=u'unauthorized-access: ACL denied 
 queue create request from anonymous@QPID 
 (qpid/broker/SessionAdapter.cpp:349)', error_info={}, channel=1, id=serial(0))
 The reason is because when qpid-route queries subsequent brokers in the 
 federation topology, it does not set any credentials (esp. those used for the 
 first broker).
 Trivial fix to follow just passes the credentials and other connection 
 options to any further broker that the tool connects to.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Created] (QPID-5642) Message sequence numbers (enabled with qpid.msg_sequence) should be persistent across broker restarts

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5642:
---

 Summary: Message sequence numbers (enabled with qpid.msg_sequence) 
should be persistent across broker restarts
 Key: QPID-5642
 URL: https://issues.apache.org/jira/browse/QPID-5642
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.26
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor


The C++ broker supports currently only at-least-once and at-most-once 
reliability. Therefore duplicate messages may occur, especially in situations 
involving failovers, reconnects etc. Currently, the broker doesn't offer any 
specific solution for duplicate detection. For many messaging scenarios, it is 
crucial to process every message only once to avoid errors. 

The broker supports message sequencing on exchange level. The message 
sequencing assigns a sequence number to every message which is routed via the 
exchange. In theory, this can be used to detect duplicates. Unfortunately, the 
sequence number isn't stored persistently and is restarted with every restart 
of the broker (HA cluster) and starts again from 1. That makes the use of the 
sequence number for duplicate detection quite complicated, especially since the 
restart of the broker is also the situation when the duplicates may occur.

Therefore, it is required to update message sequence numbers (enabled with 
qpid.msg_sequence) to store/journal after every (pre)route of a durable 
exchange, in order to persist the sequence numbers accross broker restart.




Reproducer:

rm -rf /var/lib/qpidd/* output.txt
service qpidd restart
qpid-config add exchange fanout myFanout --sequence --durable
qpid-receive -a myFanout --connection-options={reconnect:true} -f 
--print-content=no --print-header=yes -m 6  output.txt 2/dev/null 
sleep 1
qpid-send -a myFanout -m 3
service qpidd restart
sleep 1
qpid-send -a myFanout -m 3
cat output.txt


Current output:
Properties: {qpid.msg_sequence:1, sn:1, ts:1394611002529779545, 
x-amqp-0-10.routing-key:}

Properties: {qpid.msg_sequence:2, sn:2, ts:1394611002529879589, 
x-amqp-0-10.routing-key:}

Properties: {qpid.msg_sequence:3, sn:3, ts:1394611002529896423, 
x-amqp-0-10.routing-key:}

Properties: {qpid.msg_sequence:1, sn:1, ts:1394611004142278196, 
x-amqp-0-10.routing-key:}

Properties: {qpid.msg_sequence:2, sn:2, ts:1394611004142340093, 
x-amqp-0-10.routing-key:}

Properties: {qpid.msg_sequence:3, sn:3, ts:1394611004142354743, 
x-amqp-0-10.routing-key:}


Expected output:
Properties: {qpid.msg_sequence:1, sn:1, ts:1394611002529779545, 
x-amqp-0-10.routing-key:}

Properties: {qpid.msg_sequence:2, sn:2, ts:1394611002529879589, 
x-amqp-0-10.routing-key:}

Properties: {qpid.msg_sequence:3, sn:3, ts:1394611002529896423, 
x-amqp-0-10.routing-key:}

Properties: {qpid.msg_sequence:4, sn:1, ts:1394611004142278196, 
x-amqp-0-10.routing-key:}

Properties: {qpid.msg_sequence:5, sn:2, ts:1394611004142340093, 
x-amqp-0-10.routing-key:}

Properties: {qpid.msg_sequence:6, sn:3, ts:1394611004142354743, 
x-amqp-0-10.routing-key:}

(sn comes from qpid-send so it will be re-set to 1)




--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Closed] (QPID-5621) [C++ broker] userId is not passed to ACL when DIGEST-MD5 is used while creating link

[Pavel Moravec (JIRA)]

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

Pavel Moravec closed QPID-5621.
---

   Resolution: Fixed
Fix Version/s: 0.27

 [C++ broker] userId is not passed to ACL when DIGEST-MD5 is used while 
 creating link
 

 Key: QPID-5621
 URL: https://issues.apache.org/jira/browse/QPID-5621
 Project: Qpid
  Issue Type: Improvement
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
 Fix For: 0.27


 Description of problem:
 With authentication enabled and using a SASL method requiring challenge sent 
 to the client (DIGEST-MD5 or so), when creating a federation link there is no 
 username/id passed into the ACL module, thus the link rules with particular 
 username are silently passed by with no match, only matching are the 'all' 
 rules.
 Reproducer:
 ###QPIDD.CONF
 auth=yes
 #acl-file=/var/lib/qpidd/fed.acl
 acl-file=/etc/qpid/fed.acl
 #acl-file=/etc/qpid/qpidd.acl
 log-to-file=/var/lib/qpidd/qpidd.log
 log-enable=info+
 log-enable=debug+:Acl
 data-dir=/var/lib/qpidd
 ###FED.ACL
 acl allow root@QPID all all
 acl deny all all
 ### start 2 brokers with the above setting (one broker with different port 
 and data-dir)
 ###Creating regular link from 1-5672
 qpid-route link add root/root@localhost:1 root/root@localhost:5672 
 DIGEST-MD5
 Logs:
 ###DESTINATION QPIDD LOG (1)
 2013-08-13 10:33:38 [Broker] info The Broker::connect() method will be 
 removed in a future release of QPID. Please use the Broker::create() method 
 with type='link' instead.
 2013-08-13 10:33:38 [Broker] info The Broker::connect() method will be 
 removed in a future release of QPID. Please use the Broker::create() method 
 with type='link' instead.
 2013-08-13 10:33:38 [System] info Connecting: [::1]:5672
 2013-08-13 10:33:38 [System] info Connecting: [::1]:5672
 2013-08-13 10:33:38 [Broker] info Inter-broker link connecting to 
 localhost:5672
 2013-08-13 10:33:38 [Broker] info Inter-broker link connecting to 
 localhost:5672
 2013-08-13 10:33:38 [Network] info Set TCP_NODELAY on connection to 
 localhost:5672
 2013-08-13 10:33:38 [Network] info Set TCP_NODELAY on connection to 
 localhost:5672
 2013-08-13 10:33:38 [Broker] info Inter-broker link established to 
 localhost:5672
 2013-08-13 10:33:38 [Broker] info Inter-broker link established to 
 localhost:5672
 2013-08-13 10:33:38 [Broker] warning Client closed connection with 320: ACL 
 denied  creating a federation link (.. ConnectionHandler.cpp:205)
 2013-08-13 10:33:38 [Broker] warning Client closed connection with 320: ACL 
 denied  creating a federation link (.. ConnectionHandler.cpp:205)
 2013-08-13 10:33:38 [Broker] info Inter-broker link disconnected from 
 localhost:5672 Closed by peer
 2013-08-13 10:33:38 [Broker] info Inter-broker link disconnected from 
 localhost:5672 Closed by peer
 ###SOURCE QPID LOG (5672)
 2013-08-13 10:33:26 [Broker] notice Shut down
 2013-08-13 10:33:26 [Store] notice Journal TplStore: Destroyed
 2013-08-13 10:33:26 [Broker] info Management enabled
 2013-08-13 10:33:26 [Management] info ManagementAgent restored broker ID: 
 1e1f0ae9-a2e3-435c-8f5e-366d93dd69bf
 2013-08-13 10:33:26 [Broker] info Loaded protocol AMQP 1.0
 2013-08-13 10:33:26 [Store] notice Journal TplStore: Created
 2013-08-13 10:33:26 [Store] notice Store module initialized; 
 store-dir=/var/lib/qpidd
 2013-08-13 10:33:26 [Store] info  Default files per journal: 8
 2013-08-13 10:33:26 [Store] info  Default journal file size: 24 (wpgs)
 2013-08-13 10:33:26 [Store] info  Default write cache page size: 32 (KiB)
 2013-08-13 10:33:26 [Store] info  Default number of write cache pages: 32
 2013-08-13 10:33:26 [Store] info  TPL files per journal: 8
 2013-08-13 10:33:26 [Store] info  TPL journal file size: 24 (wpgs)
 2013-08-13 10:33:26 [Store] info  TPL write cache page size: 4 (KiB)
 2013-08-13 10:33:26 [Store] info  TPL number of write cache pages: 64
 2013-08-13 10:33:26 [Security] notice SSL plugin not enabled, you must set 
 --ssl-cert-db to enable it.
 2013-08-13 10:33:26 [Broker] info Registered xml exchange
 2013-08-13 10:33:26 [Store] info Most recent persistence id found: 0x0
 2013-08-13 10:33:26 [Store] info Recovered exchange amq.direct
 2013-08-13 10:33:26 [Store] info Recovered exchange amq.topic
 2013-08-13 10:33:26 [Store] info Recovered exchange amq.fanout
 2013-08-13 10:33:26 [Store] info Recovered exchange amq.match
 2013-08-13 10:33:26 [Security] info SASL: config path set to /etc/sasl2
 2013-08-13 10:33:26 [Broker] info SASL enabled
 2013-08-13 10:33:26 [Network] info Listening to: 0.0.0.0:5672
 2013-08-13 10:33:26 [Network] info Listening to: [::]:5672
 2013-08-13 10:33:26 [Network] notice 

[jira] [Created] (QPID-5619) [C++ broker] Add message auditing

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5619:
---

 Summary: [C++ broker] Add message auditing
 Key: QPID-5619
 URL: https://issues.apache.org/jira/browse/QPID-5619
 Project: Qpid
  Issue Type: Improvement
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec


There is a reasonable request to have message enqueue/dequeue audited. It can 
help troubleshooting or monitoring situations when the broker is suspected from 
discarding a message that was sent to it but never received by a consumer.

Implementation options as to be discussed in qpid users mailing list:

1) Key feature:
- where to store/send the information about new message enqueue/dequeue?
  - store it in a configurable log-file (per queue? per broker?) - problem with 
format of binary data there
  - amend/modify replicated queues for this purpose - though replicated queues 
are designed not to replicate messages that are dequeued before they have been 
replicated
  - generate QMF event to be sent to 
qmf.default.topic/agent.ind.event.org_apache_qpid_broker.queue_name.audit.enqueue|dequeue
 topic - note this would have to change qpid.subject to route the message 
properly
  - have dedicated audit exchange for this purpose (of topic type, I expect) - 
again, qpid.subject would have to be changed

- how to trigger message auditing:
  - via QueueObserver (thanks Gordon for idea)


2) Options of auditing:
- audit enqueue+dequeue events only? or also acquire, release, reject?
- it should be possible to track only one from [enqueue|dequeue|acquire] 
events, or all of them
- event/message should contain:
  - timestamp
  - original message (or just its header? or configurable?)
  - type of event (enqueue/dequeue/..)
  - identification of consumer acquiring/dequeueing the message (and also 
producer?)


3) Provisioning/managing auditing:
- have the possibility to turn on/off auditing per queue (via QMF)
- have some x-declare arguments for the auditing when declaring the queue?





--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Updated] (QPID-5619) [C++ broker] Add message auditing

[Pavel Moravec (JIRA)]

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

Pavel Moravec updated QPID-5619:


Description: 
There is a reasonable request to have message enqueue/dequeue audited. It can 
help troubleshooting or monitoring situations when the broker is suspected from 
discarding a message that was sent to it but never received by a consumer.

Implementation options as to be discussed in qpid users mailing list:

1) Key feature:
a) where to store/send the information about new message enqueue/dequeue?
  - store it in a configurable log-file (per queue? per broker?) - problem with 
format of binary data there
  - amend/modify replicated queues for this purpose - though replicated queues 
are designed not to replicate messages that are dequeued before they have been 
replicated
  - generate QMF event to be sent to 
qmf.default.topic/agent.ind.event.org_apache_qpid_broker.queue_name.audit.enqueue|dequeue
 topic - note this would have to change qpid.subject to route the message 
properly
  - have dedicated audit exchange for this purpose (of topic type, I expect) - 
again, qpid.subject would have to be changed

b) how to trigger message auditing:
  - via QueueObserver (thanks Gordon for idea)


2) Options of auditing:
a) audit enqueue+dequeue events only? or also acquire, release, reject?
b) it should be possible to track only one fromenqueue | dequeue | acquire  
 events, or all of them
c) event/message should contain:
  - timestamp
  - original message (or just its header? or configurable?)
  - type of event (enqueue/dequeue/..)
  - identification of consumer acquiring/dequeueing the message (and also 
producer?)


3) Provisioning/managing auditing:
a) have the possibility to turn on/off auditing per queue (via QMF)
b) have some x-declare arguments for the auditing when declaring the queue?



  was:
There is a reasonable request to have message enqueue/dequeue audited. It can 
help troubleshooting or monitoring situations when the broker is suspected from 
discarding a message that was sent to it but never received by a consumer.

Implementation options as to be discussed in qpid users mailing list:

1) Key feature:
- where to store/send the information about new message enqueue/dequeue?
  - store it in a configurable log-file (per queue? per broker?) - problem with 
format of binary data there
  - amend/modify replicated queues for this purpose - though replicated queues 
are designed not to replicate messages that are dequeued before they have been 
replicated
  - generate QMF event to be sent to 
qmf.default.topic/agent.ind.event.org_apache_qpid_broker.queue_name.audit.enqueue|dequeue
 topic - note this would have to change qpid.subject to route the message 
properly
  - have dedicated audit exchange for this purpose (of topic type, I expect) - 
again, qpid.subject would have to be changed

- how to trigger message auditing:
  - via QueueObserver (thanks Gordon for idea)


2) Options of auditing:
- audit enqueue+dequeue events only? or also acquire, release, reject?
- it should be possible to track only one from [enqueue|dequeue|acquire] 
events, or all of them
- event/message should contain:
  - timestamp
  - original message (or just its header? or configurable?)
  - type of event (enqueue/dequeue/..)
  - identification of consumer acquiring/dequeueing the message (and also 
producer?)


3) Provisioning/managing auditing:
- have the possibility to turn on/off auditing per queue (via QMF)
- have some x-declare arguments for the auditing when declaring the queue?




 [C++ broker] Add message auditing
 -

 Key: QPID-5619
 URL: https://issues.apache.org/jira/browse/QPID-5619
 Project: Qpid
  Issue Type: Improvement
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
  Labels: features

 There is a reasonable request to have message enqueue/dequeue audited. It can 
 help troubleshooting or monitoring situations when the broker is suspected 
 from discarding a message that was sent to it but never received by a 
 consumer.
 Implementation options as to be discussed in qpid users mailing list:
 1) Key feature:
 a) where to store/send the information about new message enqueue/dequeue?
   - store it in a configurable log-file (per queue? per broker?) - problem 
 with format of binary data there
   - amend/modify replicated queues for this purpose - though replicated 
 queues are designed not to replicate messages that are dequeued before they 
 have been replicated
   - generate QMF event to be sent to 
 qmf.default.topic/agent.ind.event.org_apache_qpid_broker.queue_name.audit.enqueue|dequeue
  topic - note this would have to change qpid.subject to route the message 
 properly
   - have dedicated audit exchange for this purpose (of topic type, I expect) 
 - again, 

[jira] [Created] (QPID-5621) [C++ broker] userId is not passed to ACL when DIGEST-MD5 is used while creating link

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5621:
---

 Summary: [C++ broker] userId is not passed to ACL when DIGEST-MD5 
is used while creating link
 Key: QPID-5621
 URL: https://issues.apache.org/jira/browse/QPID-5621
 Project: Qpid
  Issue Type: Improvement
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor


Description of problem:

With authentication enabled and using a SASL method requiring challenge sent to 
the client (DIGEST-MD5 or so), when creating a federation link there is no 
username/id passed into the ACL module, thus the link rules with particular 
username are silently passed by with no match, only matching are the 'all' 
rules.

Reproducer:

###QPIDD.CONF
auth=yes
#acl-file=/var/lib/qpidd/fed.acl
acl-file=/etc/qpid/fed.acl
#acl-file=/etc/qpid/qpidd.acl

log-to-file=/var/lib/qpidd/qpidd.log
log-enable=info+
log-enable=debug+:Acl

data-dir=/var/lib/qpidd


###FED.ACL
acl allow root@QPID all all

acl deny all all


### start 2 brokers with the above setting (one broker with different port and 
data-dir)

###Creating regular link from 1-5672
qpid-route link add root/root@localhost:1 root/root@localhost:5672 
DIGEST-MD5



Logs:
###DESTINATION QPIDD LOG (1)
2013-08-13 10:33:38 [Broker] info The Broker::connect() method will be removed 
in a future release of QPID. Please use the Broker::create() method with 
type='link' instead.
2013-08-13 10:33:38 [Broker] info The Broker::connect() method will be removed 
in a future release of QPID. Please use the Broker::create() method with 
type='link' instead.
2013-08-13 10:33:38 [System] info Connecting: [::1]:5672
2013-08-13 10:33:38 [System] info Connecting: [::1]:5672
2013-08-13 10:33:38 [Broker] info Inter-broker link connecting to localhost:5672
2013-08-13 10:33:38 [Broker] info Inter-broker link connecting to localhost:5672
2013-08-13 10:33:38 [Network] info Set TCP_NODELAY on connection to 
localhost:5672
2013-08-13 10:33:38 [Network] info Set TCP_NODELAY on connection to 
localhost:5672
2013-08-13 10:33:38 [Broker] info Inter-broker link established to 
localhost:5672
2013-08-13 10:33:38 [Broker] info Inter-broker link established to 
localhost:5672
2013-08-13 10:33:38 [Broker] warning Client closed connection with 320: ACL 
denied  creating a federation link (.. ConnectionHandler.cpp:205)
2013-08-13 10:33:38 [Broker] warning Client closed connection with 320: ACL 
denied  creating a federation link (.. ConnectionHandler.cpp:205)
2013-08-13 10:33:38 [Broker] info Inter-broker link disconnected from 
localhost:5672 Closed by peer
2013-08-13 10:33:38 [Broker] info Inter-broker link disconnected from 
localhost:5672 Closed by peer


###SOURCE QPID LOG (5672)
2013-08-13 10:33:26 [Broker] notice Shut down
2013-08-13 10:33:26 [Store] notice Journal TplStore: Destroyed
2013-08-13 10:33:26 [Broker] info Management enabled
2013-08-13 10:33:26 [Management] info ManagementAgent restored broker ID: 
1e1f0ae9-a2e3-435c-8f5e-366d93dd69bf
2013-08-13 10:33:26 [Broker] info Loaded protocol AMQP 1.0
2013-08-13 10:33:26 [Store] notice Journal TplStore: Created
2013-08-13 10:33:26 [Store] notice Store module initialized; 
store-dir=/var/lib/qpidd
2013-08-13 10:33:26 [Store] info  Default files per journal: 8
2013-08-13 10:33:26 [Store] info  Default journal file size: 24 (wpgs)
2013-08-13 10:33:26 [Store] info  Default write cache page size: 32 (KiB)
2013-08-13 10:33:26 [Store] info  Default number of write cache pages: 32
2013-08-13 10:33:26 [Store] info  TPL files per journal: 8
2013-08-13 10:33:26 [Store] info  TPL journal file size: 24 (wpgs)
2013-08-13 10:33:26 [Store] info  TPL write cache page size: 4 (KiB)
2013-08-13 10:33:26 [Store] info  TPL number of write cache pages: 64
2013-08-13 10:33:26 [Security] notice SSL plugin not enabled, you must set 
--ssl-cert-db to enable it.
2013-08-13 10:33:26 [Broker] info Registered xml exchange
2013-08-13 10:33:26 [Store] info Most recent persistence id found: 0x0
2013-08-13 10:33:26 [Store] info Recovered exchange amq.direct
2013-08-13 10:33:26 [Store] info Recovered exchange amq.topic
2013-08-13 10:33:26 [Store] info Recovered exchange amq.fanout
2013-08-13 10:33:26 [Store] info Recovered exchange amq.match
2013-08-13 10:33:26 [Security] info SASL: config path set to /etc/sasl2
2013-08-13 10:33:26 [Broker] info SASL enabled
2013-08-13 10:33:26 [Network] info Listening to: 0.0.0.0:5672
2013-08-13 10:33:26 [Network] info Listening to: [::]:5672
2013-08-13 10:33:26 [Network] notice Listening on TCP/TCP6 port 5672
2013-08-13 10:33:26 [Security] notice ACL: Read file /etc/qpid/fed.acl
2013-08-13 10:33:26 [Security] debug ACL: Group list: 0 groups found:
2013-08-13 10:33:26 [Security] debug ACL: name list: 2 names found:
2013-08-13 10:33:26 [Security] debug ACL:  * root@QPID
2013-08-13 10:33:26 [Security] debug ACL: Rule 

[jira] [Created] (QPID-5608) [amqp1.0] delete-on-close policy do not work for producers to exchanges

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5608:
---

 Summary:  [amqp1.0] delete-on-close policy do not work for 
producers to exchanges
 Key: QPID-5608
 URL: https://issues.apache.org/jira/browse/QPID-5608
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor


Description of problem:
The delete-on-close lifetime policy is not applied to producers when the 
exchange is in use.


Version-Release number of selected component (if applicable):
0.24 (incl. current upstream)


How reproducible:
100%


Steps to Reproduce:
qpid-send --connection-options {protocol:'amqp1.0'} -a 
exSend;{create:always, node:{type: topic, 
properties:{lifetime-policy:delete-on-close}}} -m 10 --send-rate=1 
exSendPID=$!
sleep 1
qpid-send --connection-options {protocol:'amqp1.0'} -a 
exSend;{create:always, node:{type: topic, 
properties:{lifetime-policy:delete-on-close}}} -m 10 --send-rate=1 
sleep 1
kill $exSendPID
qpid-config exchanges exSend

Actual results:
- not-killed qpid-send is still running
- qpid-config exchanges shows:
Type  Exchange Name  Attributes
=
topic exSend


Expected results:
- not-killed qpid-send should terminate after attempting to send to unkwnown 
exchange
- there should not be such exchange




--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Closed] (QPID-5608) [amqp1.0] delete-on-close policy do not work for producers to exchanges

[Pavel Moravec (JIRA)]

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

Pavel Moravec closed QPID-5608.
---

   Resolution: Fixed
Fix Version/s: 0.27

  [amqp1.0] delete-on-close policy do not work for producers to exchanges
 

 Key: QPID-5608
 URL: https://issues.apache.org/jira/browse/QPID-5608
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
 Fix For: 0.27


 Description of problem:
 The delete-on-close lifetime policy is not applied to producers when the 
 exchange is in use.
 Version-Release number of selected component (if applicable):
 0.24 (incl. current upstream)
 How reproducible:
 100%
 Steps to Reproduce:
 qpid-send --connection-options {protocol:'amqp1.0'} -a 
 exSend;{create:always, node:{type: topic, 
 properties:{lifetime-policy:delete-on-close}}} -m 10 --send-rate=1 
 exSendPID=$!
 sleep 1
 qpid-send --connection-options {protocol:'amqp1.0'} -a 
 exSend;{create:always, node:{type: topic, 
 properties:{lifetime-policy:delete-on-close}}} -m 10 --send-rate=1 
 sleep 1
 kill $exSendPID
 qpid-config exchanges exSend
 Actual results:
 - not-killed qpid-send is still running
 - qpid-config exchanges shows:
 Type  Exchange Name  Attributes
 =
 topic exSend
 Expected results:
 - not-killed qpid-send should terminate after attempting to send to unkwnown 
 exchange
 - there should not be such exchange



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Created] (QPID-5597) [C++ client] Topic subscriptions should not ignore auto-delete x-declare flag

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5597:
---

 Summary: [C++ client] Topic subscriptions should not ignore 
auto-delete x-declare flag
 Key: QPID-5597
 URL: https://issues.apache.org/jira/browse/QPID-5597
 Project: Qpid
  Issue Type: Bug
  Components: C++ Client
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Trivial


Description of problem:
As Python client allows, C++ client should also take into account auto-delete 
x-declare option when declaring topic subscription.


Version-Release number of selected component (if applicable):
0.24 (and current upstream)


How reproducible:
100%


Steps to Reproduce:
qpid-receive -a amq.direct/#; {link: {x-declare:{'auto-delete':False}}} -m 1 
--print-content=no -f 
qpid-stat -q | egrep '(queue|=|direct)'


Actual results:
  queuedur  autoDel  excl  msg   
msgIn  msgOut  bytes  bytesIn  bytesOut  cons  bind
  

  amq.direct_19c89381-ace4-4871-85d6-c87f4462999a   YY0 
0  0   0  00 1 2

(see the auxiliary subscription queue is auto-delete, despite we set it 
otherwise)


Expected results:
(non-auto-delete queue created)


Additional info:



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Closed] (QPID-5597) [C++ client] Topic subscriptions should not ignore auto-delete x-declare flag

[Pavel Moravec (JIRA)]

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

Pavel Moravec closed QPID-5597.
---

   Resolution: Fixed
Fix Version/s: 0.27

 [C++ client] Topic subscriptions should not ignore auto-delete x-declare flag
 -

 Key: QPID-5597
 URL: https://issues.apache.org/jira/browse/QPID-5597
 Project: Qpid
  Issue Type: Bug
  Components: C++ Client
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Trivial
 Fix For: 0.27


 Description of problem:
 As Python client allows, C++ client should also take into account auto-delete 
 x-declare option when declaring topic subscription.
 Version-Release number of selected component (if applicable):
 0.24 (and current upstream)
 How reproducible:
 100%
 Steps to Reproduce:
 qpid-receive -a amq.direct/#; {link: {x-declare:{'auto-delete':False}}} -m 
 1 --print-content=no -f 
 qpid-stat -q | egrep '(queue|=|direct)'
 Actual results:
   queuedur  autoDel  excl  msg   
 msgIn  msgOut  bytes  bytesIn  bytesOut  cons  bind
   
 
   amq.direct_19c89381-ace4-4871-85d6-c87f4462999a   YY0   
   0  0   0  00 1 2
 (see the auxiliary subscription queue is auto-delete, despite we set it 
 otherwise)
 Expected results:
 (non-auto-delete queue created)
 Additional info:



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (QPID-5595) LVQ (Last Value Queue) not working

[Pavel Moravec (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-5595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919493#comment-13919493
 ] 

Pavel Moravec commented on QPID-5595:
-

I know there were some changes to LVQ around 0.14 - 0.18.

How do you create the queue? Could you try:

qpid-config add queue myLVQueue --lvq-key=qpid.subject


or use address string like:

myLVQueue; {create:always, node:{ x-declare:{ arguments:{ 
'qpid.last_value_queue_key':'qpid.subject'

 LVQ (Last Value Queue) not working
 --

 Key: QPID-5595
 URL: https://issues.apache.org/jira/browse/QPID-5595
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.22
 Environment: C++ broker, windows 7
Reporter: Kathryn M Kowalski

 We are trying to upgrade from qpid version 0.10 to 0.22 with the broker  
 running on Windows 7.   Existing Python 2.7 code that makes use of last value 
 queues is not working.
 Queue is setup with qpid.last_value_key = qpid.subject and this was verified 
 with qpid_tool.  
 Using 0.22, when the queue is bound to an exchange that is getting messages 
 with one subject line and a heartbeat in the content the message depth 
 continues to increase.  Using 0.10 message depth stays a 1 or 0.  If you 
 drain the queue on the 0.22 broker all of the messages that should have been 
 overwritten are still there.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (QPID-5595) LVQ (Last Value Queue) not working

[Pavel Moravec (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-5595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919495#comment-13919495
 ] 

Pavel Moravec commented on QPID-5595:
-

(see the  'qpid.last_value_queue_key' property that differ from yours 
'qpid.last_value_key')

 LVQ (Last Value Queue) not working
 --

 Key: QPID-5595
 URL: https://issues.apache.org/jira/browse/QPID-5595
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.22
 Environment: C++ broker, windows 7
Reporter: Kathryn M Kowalski

 We are trying to upgrade from qpid version 0.10 to 0.22 with the broker  
 running on Windows 7.   Existing Python 2.7 code that makes use of last value 
 queues is not working.
 Queue is setup with qpid.last_value_key = qpid.subject and this was verified 
 with qpid_tool.  
 Using 0.22, when the queue is bound to an exchange that is getting messages 
 with one subject line and a heartbeat in the content the message depth 
 continues to increase.  Using 0.10 message depth stays a 1 or 0.  If you 
 drain the queue on the 0.22 broker all of the messages that should have been 
 overwritten are still there.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Created] (QPID-5587) QMF to track queue owner (userId)

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5587:
---

 Summary: QMF to track queue owner (userId)
 Key: QPID-5587
 URL: https://issues.apache.org/jira/browse/QPID-5587
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor


Due to QPID-4692, it is possible to set limits on queue created by an owner via 
ACL. But there is no way of checking the current limit.

The easiest way of doing so is to add to QMF queue object userId, that is the 
queue owner / creator.


How reproducible:
100%


Steps to Reproduce:
qpid-send -a testQueue; {create:always} 
--connection-options={sasl-mechanism:'PLAIN', username:guest, password:guest}
(try to check anywhere that guest@QPID owns/created the queue)


Actual results:
No way to see it.


Expected results:
E.g. qpid-tool - show queue_ID should provide that information


Additional info:



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Closed] (QPID-5565) [C++ broker] ACL queue create rules to take zero as unlimited value

[Pavel Moravec (JIRA)]

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

Pavel Moravec closed QPID-5565.
---


 [C++ broker] ACL queue create rules to take zero as unlimited value
 ---

 Key: QPID-5565
 URL: https://issues.apache.org/jira/browse/QPID-5565
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
 Fix For: 0.27


 When declaring queue with e.g. qpid.max_size=0, the zero is interpreted as 
 no limit in queue depth. While ACLs deal with zero as queue depth is 
 zero. Therefore:
 1) ACL rule like:
 acl allow all create queue queuemaxsizelowerlimit=10
 is not matched
 2) ACL rule like:
 acl allow all create queue queuemaxsizeupperlimit=1000
 is matched.
 While both is wrong.
 The same applies to any numerically-compared properties of ACL queue create 
 rule, specifically to:
 acl::PROP_MAXPAGES
 acl::PROP_MAXPAGEFACTOR
 acl::PROP_MAXQUEUECOUNT
 acl::PROP_MAXQUEUESIZE
 acl::PROP_MAXFILECOUNT
 acl::PROP_MAXFILESIZE
 There are two approaches how to fix it:
 1) in Broker.cpp, before calling ACL to authorize queue creation, replace 
 zero value by 9223372036854775807 (as hardcoded maximum for ACL numerical 
 value; see src/tests/Variant.cpp and/or src/tests/acl.py for more)
 2) Within ACL, deal zero value as unlimited
 The first approach would allow future parameters having 0 as real zero value. 
 But Broker class would mimic/workaround some ACL work.
 The second approach would resolve the problem in better place, but it would 
 enforce that zero is interpreted as infinity everytime (can't it break 
 something? or on the other side, can't it unify handling 
 connection-limit-per-ip or max-queues-per-user options?)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Created] (QPID-5565) [C++ broker] ACL queue create rules to take zero as unlimited value

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5565:
---

 Summary: [C++ broker] ACL queue create rules to take zero as 
unlimited value
 Key: QPID-5565
 URL: https://issues.apache.org/jira/browse/QPID-5565
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor


When declaring queue with e.g. qpid.max_size=0, the zero is interpreted as no 
limit in queue depth. While ACLs deal with zero as queue depth is zero. 
Therefore:

1) ACL rule like:

acl allow all create queue queuemaxsizelowerlimit=10

is not matched

2) ACL rule like:

acl allow all create queue queuemaxsizeupperlimit=1000

is matched.

While both is wrong.

The same applies to any numerically-compared properties of ACL queue create 
rule, specifically to:

acl::PROP_MAXPAGES
acl::PROP_MAXPAGEFACTOR
acl::PROP_MAXQUEUECOUNT
acl::PROP_MAXQUEUESIZE
acl::PROP_MAXFILECOUNT
acl::PROP_MAXFILESIZE


There are two approaches how to fix it:

1) in Broker.cpp, before calling ACL to authorize queue creation, replace zero 
value by 9223372036854775807 (as hardcoded maximum for ACL numerical value; see 
src/tests/Variant.cpp and/or src/tests/acl.py for more)

2) Within ACL, deal zero value as unlimited

The first approach would allow future parameters having 0 as real zero value. 
But Broker class would mimic/workaround some ACL work.

The second approach would resolve the problem in better place, but it would 
enforce that zero is interpreted as infinity everytime (can't it break 
something? or on the other side, can't it unify handling 
connection-limit-per-ip or max-queues-per-user options?)




--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (QPID-5561) C++ Broker queue creation ACL checks against wrong limit values

[Pavel Moravec (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13905590#comment-13905590
 ] 

Pavel Moravec commented on QPID-5561:
-

I think the two JIRAs point to different problems:

QPID-5561 to wrong limits passed to ACL
QPID-5565 to wrong interpretation of zero value in ACL

Anyway both can be dealt in a single JIRA so closing this is fine for me.

 C++ Broker queue creation ACL checks against wrong limit values
 ---

 Key: QPID-5561
 URL: https://issues.apache.org/jira/browse/QPID-5561
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.22
 Environment: any/all
Reporter: Chuck Rolke
Assignee: Pavel Moravec

 If a queue is created without specifying any parameters (like paging queue 
 without page_factor or pages_loaded set, or durable queue without filecount / 
 filesize set), the default values from broker configuration are used in the 
 actual queue creation. However, the ACL rules are in such case tested against 
 _zero_ values. That brings problems when e.g. ACLs require pages_loaded  10.
 How reproducible:
 100%
 Steps to Reproduce:
 1. Having ACL file like:
 {noformat}
 acl allow all create queue paging=true pageslowerlimit=1 pagesupperlimit=100 
 pagefactorlowerlimit=1 pagefactorlowerlimit=100
 acl allow all consume
 acl allow all access
 acl allow all bind
 acl deny all all
 {noformat}
 2. qpid-receive -a q1; {create:always, node:{type:queue, 
 x-declare:{arguments:{ 'qpid.paging':true 
 3. qpid-receive -a q2; {create:always, node:{type:queue, 
 x-declare:{arguments:{ 'qpid.paging':true, 'qpid.max_pages_loaded':4, 
 'qpid.page_factor':1 
 (note, qpid.max_pages_loaded has default value 4 and qpid.page_factor has 
 default value 1)
 Actual results:
 q1 is not created with ACL denied queue create request from anonymous@QPID
 q2 is created (though with the same parameters)
 Expected results:
 Both q1 and q2 to be created
 See [bz1066372|https://bugzilla.redhat.com/show_bug.cgi?id=1066372]



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Closed] (QPID-5531) [C++ broker] Set timeout for every DTX transaction

[Pavel Moravec (JIRA)]

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

Pavel Moravec closed QPID-5531.
---


 [C++ broker] Set timeout for every DTX transaction
 --

 Key: QPID-5531
 URL: https://issues.apache.org/jira/browse/QPID-5531
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
  Labels: patch
 Fix For: 0.27

 Attachments: QPID-5531.patch, qpid-txtest_modified.patch


 Description of problem:
 If an external Transaction Manager (TM) prepares a DTX transaction but 
 forgets, due to any reason, to commit or abort it, tpl journal has an 
 orphaned enqueue record forever (that in legacystore causes enqueue capacity 
 threshold exception after a while, preventing _any_ transaction to 
 commit/abort).
 To prevent such orphaned XID entries in tpl, every incoming DTX transaction 
 should have a default timeout set (while dtx.set-timeout AMQP 0-10 primitive 
 changes it).
 The timeout should be broker-wide parameter configurable via 
 --dtx-default-timeout option.
 Version-Release number of selected component (if applicable):
 any (incl upstream 0.26)
 How reproducible:
 100%
 Steps to Reproduce:
 1. Mimic an external TM that prepares a DTX but never commits or aborts it - 
 use e.g. _modified_ qpid-txtest (patch attached):
 qpid-txtest --queues=1 --total-messages=1 --dtx=1 --dtx-commit=no
 2. /usr/libexec/qpid/store_chk /var/lib/qpidd/rhm/tpl -b tpl
 Actual results:
 tpl journal keeps the unfinished transaction forever
 Expected results:
 sleeping for dtx-default-timeout, the transaction should be gone



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Resolved] (QPID-5531) [C++ broker] Set timeout for every DTX transaction

[Pavel Moravec (JIRA)]

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

Pavel Moravec resolved QPID-5531.
-

   Resolution: Fixed
Fix Version/s: 0.27

 [C++ broker] Set timeout for every DTX transaction
 --

 Key: QPID-5531
 URL: https://issues.apache.org/jira/browse/QPID-5531
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
  Labels: patch
 Fix For: 0.27

 Attachments: QPID-5531.patch, qpid-txtest_modified.patch


 Description of problem:
 If an external Transaction Manager (TM) prepares a DTX transaction but 
 forgets, due to any reason, to commit or abort it, tpl journal has an 
 orphaned enqueue record forever (that in legacystore causes enqueue capacity 
 threshold exception after a while, preventing _any_ transaction to 
 commit/abort).
 To prevent such orphaned XID entries in tpl, every incoming DTX transaction 
 should have a default timeout set (while dtx.set-timeout AMQP 0-10 primitive 
 changes it).
 The timeout should be broker-wide parameter configurable via 
 --dtx-default-timeout option.
 Version-Release number of selected component (if applicable):
 any (incl upstream 0.26)
 How reproducible:
 100%
 Steps to Reproduce:
 1. Mimic an external TM that prepares a DTX but never commits or aborts it - 
 use e.g. _modified_ qpid-txtest (patch attached):
 qpid-txtest --queues=1 --total-messages=1 --dtx=1 --dtx-commit=no
 2. /usr/libexec/qpid/store_chk /var/lib/qpidd/rhm/tpl -b tpl
 Actual results:
 tpl journal keeps the unfinished transaction forever
 Expected results:
 sleeping for dtx-default-timeout, the transaction should be gone



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (QPID-5531) [C++ broker] Set timeout for every DTX transaction

[Pavel Moravec (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-5531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889342#comment-13889342
 ] 

Pavel Moravec commented on QPID-5531:
-

Hi Jakub,
Reading 0-10 specification(*), broker has no ability to refuse client's 
timeout, whatever high it is. So the best the broker can do (to follow 
specification) is to log a warning/error.

With respect t that, I think the second broker option would be less required. 
Do you see it as sufficient to add test like:

if (client_setting_timeout  dtx-default-timeout)
QPID_LOG(warn, some warning);

?

(*) AMQP 1.0 does not have specified DTX at all, so far, so ignoring it here

 [C++ broker] Set timeout for every DTX transaction
 --

 Key: QPID-5531
 URL: https://issues.apache.org/jira/browse/QPID-5531
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
  Labels: patch
 Attachments: QPID-5531.patch, qpid-txtest_modified.patch


 Description of problem:
 If an external Transaction Manager (TM) prepares a DTX transaction but 
 forgets, due to any reason, to commit or abort it, tpl journal has an 
 orphaned enqueue record forever (that in legacystore causes enqueue capacity 
 threshold exception after a while, preventing _any_ transaction to 
 commit/abort).
 To prevent such orphaned XID entries in tpl, every incoming DTX transaction 
 should have a default timeout set (while dtx.set-timeout AMQP 0-10 primitive 
 changes it).
 The timeout should be broker-wide parameter configurable via 
 --dtx-default-timeout option.
 Version-Release number of selected component (if applicable):
 any (incl upstream 0.26)
 How reproducible:
 100%
 Steps to Reproduce:
 1. Mimic an external TM that prepares a DTX but never commits or aborts it - 
 use e.g. _modified_ qpid-txtest (patch attached):
 qpid-txtest --queues=1 --total-messages=1 --dtx=1 --dtx-commit=no
 2. /usr/libexec/qpid/store_chk /var/lib/qpidd/rhm/tpl -b tpl
 Actual results:
 tpl journal keeps the unfinished transaction forever
 Expected results:
 sleeping for dtx-default-timeout, the transaction should be gone



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Resolved] (QPID-5534) [C++ broker] Headers exchange can route a message to one queue multiple times

[Pavel Moravec (JIRA)]

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

Pavel Moravec resolved QPID-5534.
-

   Resolution: Fixed
Fix Version/s: 0.27

 [C++ broker] Headers exchange can route a message to one queue multiple times
 -

 Key: QPID-5534
 URL: https://issues.apache.org/jira/browse/QPID-5534
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
 Fix For: 0.27


 If a message sent to a headers exchange matches two bindings to one queue, it 
 is enqueued to that queue twice.
 Further, if the queue and the message are durable, journal raises error:
 JERR_MAP_DUPLICATE: Attempted to insert record into map using duplicate key.
 Reproducer:
 qpid-config add queue MyQueue --durable
 qpid-config bind amq.match MyQueue SomeKey any property1=value1
 qpid-config bind amq.match MyQueue OtherKey all property2=value2
 qpid-send -a amq.match -m 1 -P property1=value1 -P property2=value2 
 --durable=true



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Closed] (QPID-5534) [C++ broker] Headers exchange can route a message to one queue multiple times

[Pavel Moravec (JIRA)]

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

Pavel Moravec closed QPID-5534.
---


 [C++ broker] Headers exchange can route a message to one queue multiple times
 -

 Key: QPID-5534
 URL: https://issues.apache.org/jira/browse/QPID-5534
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
 Fix For: 0.27


 If a message sent to a headers exchange matches two bindings to one queue, it 
 is enqueued to that queue twice.
 Further, if the queue and the message are durable, journal raises error:
 JERR_MAP_DUPLICATE: Attempted to insert record into map using duplicate key.
 Reproducer:
 qpid-config add queue MyQueue --durable
 qpid-config bind amq.match MyQueue SomeKey any property1=value1
 qpid-config bind amq.match MyQueue OtherKey all property2=value2
 qpid-send -a amq.match -m 1 -P property1=value1 -P property2=value2 
 --durable=true



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Created] (QPID-5534) [C++ broker] Headers exchange can route a message to one queue multiple times

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5534:
---

 Summary: [C++ broker] Headers exchange can route a message to one 
queue multiple times
 Key: QPID-5534
 URL: https://issues.apache.org/jira/browse/QPID-5534
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor


If a message sent to a headers exchange matches two bindings to one queue, it 
is enqueued to that queue twice.

Further, if the queue and the message are durable, journal raises error:

JERR_MAP_DUPLICATE: Attempted to insert record into map using duplicate key.


Reproducer:

qpid-config add queue MyQueue --durable
qpid-config bind amq.match MyQueue SomeKey any property1=value1
qpid-config bind amq.match MyQueue OtherKey all property2=value2
qpid-send -a amq.match -m 1 -P property1=value1 -P property2=value2 
--durable=true




--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Resolved] (QPID-5121) Store module does not raise exception when attempting to enqueue a message bigger than the journal size

[Pavel Moravec (JIRA)]

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

Pavel Moravec resolved QPID-5121.
-

   Resolution: Fixed
Fix Version/s: Future
 Assignee: Pavel Moravec

 Store module does not raise exception when attempting to enqueue a message 
 bigger than the journal size
 ---

 Key: QPID-5121
 URL: https://issues.apache.org/jira/browse/QPID-5121
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.22
Reporter: Pavel Moravec
Assignee: Pavel Moravec
 Fix For: Future

 Attachments: QPID-5121.patch


 Description of problem:
 Whenever store module tries to write to a journal a message bigger than the 
 journal capacity is, it a) does not store the message (so far so good), but 
 b) it does _not_ raise an error (!!!). So the broker thinks the message was 
 enqueued.
 That is a big gotcha, as the durable message is kept in memory only.
 Version-Release number of selected component (if applicable):
 0.22
 How reproducible:
 100%
 Steps to Reproduce:
 rm -rf /var/lib/qpidd/* /var/lib/qpidd/.* 2 /dev/null
 service qpidd restart
 # create a durable queue with tiny journal and send there one huge message
 qpid-send -a DurableQueue4; {create:always, node:{durable:true, x-declare:{ 
 arguments:{'qpid.flow_stop_count':0, 'qpid.max_count':0, 'qpid.file_count':4, 
 'qpid.file_size':8, 'qpid.flow_resume_count':0, 'qpid.flow_stop_size':0, 
 'qpid.flow_resume_size':0, 'qpid.max_size':0  -m 1 
 --content-size=1 --durable=yes
 # check in stats the queue has the message enqueued
 qpid-stat -q 
 Queues
   queue dur  autoDel  excl  msg   msgIn  
 msgOut  bytes  bytesIn  bytesOut  cons  bind
   
 =
   7e553cc6-89d4-46b2-93fd-5ad7cf1f72a9:0.0   YY0 0
   0   0  00 1 2
   DurableQueue4 Y  1 1
   0 100m   100m   0 0 1
 # restart the broker and check queue stats
 service qpidd restart
 qpid-stat -q 
 Queues
   queue dur  autoDel  excl  msg   msgIn  
 msgOut  bytes  bytesIn  bytesOut  cons  bind
   
 =
   DurableQueue4 Y  0 0
   0   0  00 0 1
   cd53-5b98-4101-ad35-de71e038cd61:0.0   YY0 0
   0   0  00 1 2
 # ouch, where the _durable_ message went to???
 Actual results:
 1) generic reproducer for regular durable queue:
 - qpid-send/broker/store has not returned an error (THIS is the wrong)
 - after the broker restart, the queue has no message (this should be ok but 
 not after no error raised)
 Expected results:
 qpid-send should fail due to Enqueue capacity threshold error (and no 
 message should be kept in the broker later on).
 Additional info:
 - Optional/variant scenarios: send first some tiny message to the journal and 
 then the huge one.
 - Trivial patch to be added



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Closed] (QPID-5121) Store module does not raise exception when attempting to enqueue a message bigger than the journal size

[Pavel Moravec (JIRA)]

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

Pavel Moravec closed QPID-5121.
---


 Store module does not raise exception when attempting to enqueue a message 
 bigger than the journal size
 ---

 Key: QPID-5121
 URL: https://issues.apache.org/jira/browse/QPID-5121
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.22
Reporter: Pavel Moravec
Assignee: Pavel Moravec
 Fix For: Future

 Attachments: QPID-5121.patch


 Description of problem:
 Whenever store module tries to write to a journal a message bigger than the 
 journal capacity is, it a) does not store the message (so far so good), but 
 b) it does _not_ raise an error (!!!). So the broker thinks the message was 
 enqueued.
 That is a big gotcha, as the durable message is kept in memory only.
 Version-Release number of selected component (if applicable):
 0.22
 How reproducible:
 100%
 Steps to Reproduce:
 rm -rf /var/lib/qpidd/* /var/lib/qpidd/.* 2 /dev/null
 service qpidd restart
 # create a durable queue with tiny journal and send there one huge message
 qpid-send -a DurableQueue4; {create:always, node:{durable:true, x-declare:{ 
 arguments:{'qpid.flow_stop_count':0, 'qpid.max_count':0, 'qpid.file_count':4, 
 'qpid.file_size':8, 'qpid.flow_resume_count':0, 'qpid.flow_stop_size':0, 
 'qpid.flow_resume_size':0, 'qpid.max_size':0  -m 1 
 --content-size=1 --durable=yes
 # check in stats the queue has the message enqueued
 qpid-stat -q 
 Queues
   queue dur  autoDel  excl  msg   msgIn  
 msgOut  bytes  bytesIn  bytesOut  cons  bind
   
 =
   7e553cc6-89d4-46b2-93fd-5ad7cf1f72a9:0.0   YY0 0
   0   0  00 1 2
   DurableQueue4 Y  1 1
   0 100m   100m   0 0 1
 # restart the broker and check queue stats
 service qpidd restart
 qpid-stat -q 
 Queues
   queue dur  autoDel  excl  msg   msgIn  
 msgOut  bytes  bytesIn  bytesOut  cons  bind
   
 =
   DurableQueue4 Y  0 0
   0   0  00 0 1
   cd53-5b98-4101-ad35-de71e038cd61:0.0   YY0 0
   0   0  00 1 2
 # ouch, where the _durable_ message went to???
 Actual results:
 1) generic reproducer for regular durable queue:
 - qpid-send/broker/store has not returned an error (THIS is the wrong)
 - after the broker restart, the queue has no message (this should be ok but 
 not after no error raised)
 Expected results:
 qpid-send should fail due to Enqueue capacity threshold error (and no 
 message should be kept in the broker later on).
 Additional info:
 - Optional/variant scenarios: send first some tiny message to the journal and 
 then the huge one.
 - Trivial patch to be added



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Resolved] (QPID-5519) ACL property/properties for paged queues

[Pavel Moravec (JIRA)]

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

Pavel Moravec resolved QPID-5519.
-

   Resolution: Fixed
Fix Version/s: 0.27

 ACL property/properties for paged queues
 

 Key: QPID-5519
 URL: https://issues.apache.org/jira/browse/QPID-5519
 Project: Qpid
  Issue Type: Improvement
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
  Labels: improvement, patch
 Fix For: 0.27

 Attachments: QPID-5519.patch


 Description of problem:
 QPID-4339 adds paged queue but there is no corresponding ACL rule/property 
 limiting users in creating paged queues. As from system management point of 
 view, a paged queue (being backed up by a physical file) is very similar to a 
 durable queue.
 Therefore ACL should have property paging=true / paging=false in create 
 queue rule. Additionally, it has some (limited) sense to have limits for 
 max_pages_loaded and page_factor attributes. Those limits:
 - could limit memory usage (if the property would compare 
 max_pages_loaded*page_factor)
 - could limit maximal message size to be successfully enqueued (page_factor) 
 - though I dont see a big value of such ACL limit; please provide a business 
 justification if there is
 - could _indirectly_ limit maximal size of the underlying file (that upper 
 limit is   page_factor*value_of_(/proc/sys/vm/max_map_count)  ) - as 
 max_map_count is usually high, it is less usefull
 Version-Release number of selected component (if applicable):
 any (incl. qpid 0.26)
 How reproducible:
 100%
 Steps to Reproduce:
 any user can run:
 qpid-config add queue my-paged-queue --argument qpid.paging=True --argument 
 qpid.max_pages_loaded=1 --argument qpid.page_factor=1
 Actual results:
 Any user can create paged queue of arbitrary parameters (paged queue related).
 Expected results:
 ACL parameters could prevent so.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Closed] (QPID-5519) ACL property/properties for paged queues

[Pavel Moravec (JIRA)]

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

Pavel Moravec closed QPID-5519.
---


 ACL property/properties for paged queues
 

 Key: QPID-5519
 URL: https://issues.apache.org/jira/browse/QPID-5519
 Project: Qpid
  Issue Type: Improvement
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
  Labels: improvement, patch
 Fix For: 0.27

 Attachments: QPID-5519.patch


 Description of problem:
 QPID-4339 adds paged queue but there is no corresponding ACL rule/property 
 limiting users in creating paged queues. As from system management point of 
 view, a paged queue (being backed up by a physical file) is very similar to a 
 durable queue.
 Therefore ACL should have property paging=true / paging=false in create 
 queue rule. Additionally, it has some (limited) sense to have limits for 
 max_pages_loaded and page_factor attributes. Those limits:
 - could limit memory usage (if the property would compare 
 max_pages_loaded*page_factor)
 - could limit maximal message size to be successfully enqueued (page_factor) 
 - though I dont see a big value of such ACL limit; please provide a business 
 justification if there is
 - could _indirectly_ limit maximal size of the underlying file (that upper 
 limit is   page_factor*value_of_(/proc/sys/vm/max_map_count)  ) - as 
 max_map_count is usually high, it is less usefull
 Version-Release number of selected component (if applicable):
 any (incl. qpid 0.26)
 How reproducible:
 100%
 Steps to Reproduce:
 any user can run:
 qpid-config add queue my-paged-queue --argument qpid.paging=True --argument 
 qpid.max_pages_loaded=1 --argument qpid.page_factor=1
 Actual results:
 Any user can create paged queue of arbitrary parameters (paged queue related).
 Expected results:
 ACL parameters could prevent so.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Resolved] (QPID-5530) [legacystore] store_chk raises Operation on non-existent record: operation=unlock; rid=.. on aborted DTX transaction in TplStore

[Pavel Moravec (JIRA)]

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

Pavel Moravec resolved QPID-5530.
-

   Resolution: Fixed
Fix Version/s: 0.27
 Assignee: Pavel Moravec

 [legacystore] store_chk raises Operation on non-existent record: 
 operation=unlock; rid=.. on aborted DTX transaction in TplStore 
 ---

 Key: QPID-5530
 URL: https://issues.apache.org/jira/browse/QPID-5530
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Trivial
 Fix For: 0.27


 Description of problem:
 Having an aborted DTX transaction in TplStore, store_chk raises Operation on 
 non-existent record: operation=unlock; rid=.. error.
 Version-Release number of selected component (if applicable):
 any (incl. qpid 0.26)
 How reproducible:
 100%
 Steps to Reproduce:
 1. Prepare and abort a DTX transaction (e.g. by replacing dtxCommit by 
 dtxRollback in qpid-txtest.cpp, recompiling it and running it with --dtx=1 
 argument)
 2. /usr/libexec/qpid/store_chk /var/lib/qpidd/rhm/tpl -b tpl
 Actual results:
 Recovering journals .
 Operation on non-existent record: operation=unlock; rid=0x2311c
 Expected results:
 Journals recovered properly.
 Additional info:



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Closed] (QPID-5530) [legacystore] store_chk raises Operation on non-existent record: operation=unlock; rid=.. on aborted DTX transaction in TplStore

[Pavel Moravec (JIRA)]

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

Pavel Moravec closed QPID-5530.
---


 [legacystore] store_chk raises Operation on non-existent record: 
 operation=unlock; rid=.. on aborted DTX transaction in TplStore 
 ---

 Key: QPID-5530
 URL: https://issues.apache.org/jira/browse/QPID-5530
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Trivial
 Fix For: 0.27


 Description of problem:
 Having an aborted DTX transaction in TplStore, store_chk raises Operation on 
 non-existent record: operation=unlock; rid=.. error.
 Version-Release number of selected component (if applicable):
 any (incl. qpid 0.26)
 How reproducible:
 100%
 Steps to Reproduce:
 1. Prepare and abort a DTX transaction (e.g. by replacing dtxCommit by 
 dtxRollback in qpid-txtest.cpp, recompiling it and running it with --dtx=1 
 argument)
 2. /usr/libexec/qpid/store_chk /var/lib/qpidd/rhm/tpl -b tpl
 Actual results:
 Recovering journals .
 Operation on non-existent record: operation=unlock; rid=0x2311c
 Expected results:
 Journals recovered properly.
 Additional info:



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Updated] (QPID-5532) [C++ broker] Add debug log when timeouting DTX transaction

[Pavel Moravec (JIRA)]

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

Pavel Moravec updated QPID-5532:


Summary: [C++ broker] Add debug log when timeouting DTX transaction  (was: 
[C++ broker] Add ebug log when timeouting DTX transaction)

 [C++ broker] Add debug log when timeouting DTX transaction
 --

 Key: QPID-5532
 URL: https://issues.apache.org/jira/browse/QPID-5532
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Trivial
  Labels: easyfix, patch

 Any timeout-ed DTX transaction shall be logged. Especially once QPID-5531 is 
 implemented, as then every DTX will have some default timeout.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Resolved] (QPID-5532) [C++ broker] Add debug log when timeouting DTX transaction

[Pavel Moravec (JIRA)]

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

Pavel Moravec resolved QPID-5532.
-

   Resolution: Fixed
Fix Version/s: 0.27

 [C++ broker] Add debug log when timeouting DTX transaction
 --

 Key: QPID-5532
 URL: https://issues.apache.org/jira/browse/QPID-5532
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Trivial
  Labels: easyfix, patch
 Fix For: 0.27


 Any timeout-ed DTX transaction shall be logged. Especially once QPID-5531 is 
 implemented, as then every DTX will have some default timeout.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Closed] (QPID-5532) [C++ broker] Add debug log when timeouting DTX transaction

[Pavel Moravec (JIRA)]

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

Pavel Moravec closed QPID-5532.
---


 [C++ broker] Add debug log when timeouting DTX transaction
 --

 Key: QPID-5532
 URL: https://issues.apache.org/jira/browse/QPID-5532
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Trivial
  Labels: easyfix, patch
 Fix For: 0.27


 Any timeout-ed DTX transaction shall be logged. Especially once QPID-5531 is 
 implemented, as then every DTX will have some default timeout.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Created] (QPID-5533) [C++ broker] Linearstore to return any empty page to EPL

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5533:
---

 Summary: [C++ broker] Linearstore to return any empty page to EPL
 Key: QPID-5533
 URL: https://issues.apache.org/jira/browse/QPID-5533
 Project: Qpid
  Issue Type: Improvement
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Priority: Minor


Linear store should return to EPL _any_ empty file of a journal, not only the 
oldest one (once it gets emptied). As there can be corner cases where journal 
enqueue record sits in journal (almost) forever, while the journal gets next 
enqueue+dequeue records in parallel. In particular, basic scenarios cover 
message filters in consumers, priority queue (with message of lower priority 
never consumed), or tpl journal with orphaned transaction (until QPID-5531 is 
fixed).

One particular reproducer with priority queue:

qpid-config add queue testQueue --argument=x-qpid-priorities=10 --durable
qpid-send -a testQueue -m 1 --priority 1 --durable=yes
while true; do ./src/tests/qpid-send -a testQueue -m 5000 --priority 2 
--durable=yes; ./src/tests/qpid-receive -a testQueue -m 5000 
--print-content=no; qpid-stat -q; done

~/.qpidd/qls/jrnl/testQueue/ grows forever.

(I am fine to close it as WONTFIX if a potential fix would be too complex, 
compared to the probability of the corner cases)




--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Created] (QPID-5530) [legacystore] store_chk raises Operation on non-existent record: operation=unlock; rid=.. on aborted DTX transaction in TplStore

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5530:
---

 Summary: [legacystore] store_chk raises Operation on non-existent 
record: operation=unlock; rid=.. on aborted DTX transaction in TplStore 
 Key: QPID-5530
 URL: https://issues.apache.org/jira/browse/QPID-5530
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Priority: Trivial


Description of problem:
Having an aborted DTX transaction in TplStore, store_chk raises Operation on 
non-existent record: operation=unlock; rid=.. error.


Version-Release number of selected component (if applicable):
any (incl. qpid 0.26)


How reproducible:
100%


Steps to Reproduce:
1. Prepare and abort a DTX transaction (e.g. by replacing dtxCommit by 
dtxRollback in qpid-txtest.cpp, recompiling it and running it with --dtx=1 
argument)
2. /usr/libexec/qpid/store_chk /var/lib/qpidd/rhm/tpl -b tpl


Actual results:
Recovering journals .
Operation on non-existent record: operation=unlock; rid=0x2311c


Expected results:
Journals recovered properly.


Additional info:



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Created] (QPID-5531) [C++ broker] Set timeout for every DTX transaction

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5531:
---

 Summary: [C++ broker] Set timeout for every DTX transaction
 Key: QPID-5531
 URL: https://issues.apache.org/jira/browse/QPID-5531
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor


Description of problem:
If an external Transaction Manager (TM) prepares a DTX transaction but forgets, 
due to any reason, to commit or abort it, tpl journal has an orphaned enqueue 
record forever (that in legacystore causes enqueue capacity threshold exception 
after a while, preventing _any_ transaction to commit/abort).

To prevent such orphaned XID entries in tpl, every incoming DTX transaction 
should have a default timeout set (while dtx.set-timeout AMQP 0-10 primitive 
changes it).

The timeout should be broker-wide parameter configurable via 
--dtx-default-timeout option.


Version-Release number of selected component (if applicable):
any (incl upstream 0.26)


How reproducible:
100%


Steps to Reproduce:
1. Mimic an external TM that prepares a DTX but never commits or aborts it - 
use e.g. _modified_ qpid-txtest (patch attached):
qpid-txtest --queues=1 --total-messages=1 --dtx=1 --dtx-commit=no

2. /usr/libexec/qpid/store_chk /var/lib/qpidd/rhm/tpl -b tpl


Actual results:
tpl journal keeps the unfinished transaction forever


Expected results:
sleeping for dtx-default-timeout, the transaction should be gone



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Updated] (QPID-5531) [C++ broker] Set timeout for every DTX transaction

[Pavel Moravec (JIRA)]

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

Pavel Moravec updated QPID-5531:


Attachment: qpid-txtest_modified.patch

Patch for straightforward reproducer.

 [C++ broker] Set timeout for every DTX transaction
 --

 Key: QPID-5531
 URL: https://issues.apache.org/jira/browse/QPID-5531
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
  Labels: patch
 Attachments: qpid-txtest_modified.patch


 Description of problem:
 If an external Transaction Manager (TM) prepares a DTX transaction but 
 forgets, due to any reason, to commit or abort it, tpl journal has an 
 orphaned enqueue record forever (that in legacystore causes enqueue capacity 
 threshold exception after a while, preventing _any_ transaction to 
 commit/abort).
 To prevent such orphaned XID entries in tpl, every incoming DTX transaction 
 should have a default timeout set (while dtx.set-timeout AMQP 0-10 primitive 
 changes it).
 The timeout should be broker-wide parameter configurable via 
 --dtx-default-timeout option.
 Version-Release number of selected component (if applicable):
 any (incl upstream 0.26)
 How reproducible:
 100%
 Steps to Reproduce:
 1. Mimic an external TM that prepares a DTX but never commits or aborts it - 
 use e.g. _modified_ qpid-txtest (patch attached):
 qpid-txtest --queues=1 --total-messages=1 --dtx=1 --dtx-commit=no
 2. /usr/libexec/qpid/store_chk /var/lib/qpidd/rhm/tpl -b tpl
 Actual results:
 tpl journal keeps the unfinished transaction forever
 Expected results:
 sleeping for dtx-default-timeout, the transaction should be gone



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Updated] (QPID-5531) [C++ broker] Set timeout for every DTX transaction

[Pavel Moravec (JIRA)]

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

Pavel Moravec updated QPID-5531:


Attachment: QPID-5531.patch

Proposed patch

--dtx-default-timeout option added with default value 3600 seconds.

Tried the reproducer on broker with --dtx-default-timeout=60, and the 
transaction was gone after one minute.

NOT tested (even built) ms-sql and/or ms-clfs store.

 [C++ broker] Set timeout for every DTX transaction
 --

 Key: QPID-5531
 URL: https://issues.apache.org/jira/browse/QPID-5531
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
  Labels: patch
 Attachments: QPID-5531.patch, qpid-txtest_modified.patch


 Description of problem:
 If an external Transaction Manager (TM) prepares a DTX transaction but 
 forgets, due to any reason, to commit or abort it, tpl journal has an 
 orphaned enqueue record forever (that in legacystore causes enqueue capacity 
 threshold exception after a while, preventing _any_ transaction to 
 commit/abort).
 To prevent such orphaned XID entries in tpl, every incoming DTX transaction 
 should have a default timeout set (while dtx.set-timeout AMQP 0-10 primitive 
 changes it).
 The timeout should be broker-wide parameter configurable via 
 --dtx-default-timeout option.
 Version-Release number of selected component (if applicable):
 any (incl upstream 0.26)
 How reproducible:
 100%
 Steps to Reproduce:
 1. Mimic an external TM that prepares a DTX but never commits or aborts it - 
 use e.g. _modified_ qpid-txtest (patch attached):
 qpid-txtest --queues=1 --total-messages=1 --dtx=1 --dtx-commit=no
 2. /usr/libexec/qpid/store_chk /var/lib/qpidd/rhm/tpl -b tpl
 Actual results:
 tpl journal keeps the unfinished transaction forever
 Expected results:
 sleeping for dtx-default-timeout, the transaction should be gone



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Created] (QPID-5519) ACL property/properties for paged queues

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5519:
---

 Summary: ACL property/properties for paged queues
 Key: QPID-5519
 URL: https://issues.apache.org/jira/browse/QPID-5519
 Project: Qpid
  Issue Type: Improvement
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor


Description of problem:
QPID-4339 adds paged queue but there is no corresponding ACL rule/property 
limiting users in creating paged queues. As from system management point of 
view, a paged queue (being backed up by a physical file) is very similar to a 
durable queue.

Therefore ACL should have property paging=true / paging=false in create 
queue rule. Additionally, it has some (limited) sense to have limits for 
max_pages_loaded and page_factor attributes. Those limits:
- could limit memory usage (if the property would compare 
max_pages_loaded*page_factor)
- could limit maximal message size to be successfully enqueued (page_factor) - 
though I dont see a big value of such ACL limit; please provide a business 
justification if there is
- could _indirectly_ limit maximal size of the underlying file (that upper 
limit is   page_factor*value_of_(/proc/sys/vm/max_map_count)  ) - as 
max_map_count is usually high, it is less usefull


Version-Release number of selected component (if applicable):
any (incl. qpid 0.26)


How reproducible:
100%


Steps to Reproduce:
any user can run:
qpid-config add queue my-paged-queue --argument qpid.paging=True --argument 
qpid.max_pages_loaded=1 --argument qpid.page_factor=1


Actual results:
Any user can create paged queue of arbitrary parameters (paged queue related).


Expected results:
ACL parameters could prevent so.




--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Updated] (QPID-5519) ACL property/properties for paged queues

[Pavel Moravec (JIRA)]

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

Pavel Moravec updated QPID-5519:


Attachment: QPID-5519.patch

Attached patch sent to review (https://reviews.apache.org/r/17451/).

 ACL property/properties for paged queues
 

 Key: QPID-5519
 URL: https://issues.apache.org/jira/browse/QPID-5519
 Project: Qpid
  Issue Type: Improvement
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
  Labels: improvement, patch
 Attachments: QPID-5519.patch


 Description of problem:
 QPID-4339 adds paged queue but there is no corresponding ACL rule/property 
 limiting users in creating paged queues. As from system management point of 
 view, a paged queue (being backed up by a physical file) is very similar to a 
 durable queue.
 Therefore ACL should have property paging=true / paging=false in create 
 queue rule. Additionally, it has some (limited) sense to have limits for 
 max_pages_loaded and page_factor attributes. Those limits:
 - could limit memory usage (if the property would compare 
 max_pages_loaded*page_factor)
 - could limit maximal message size to be successfully enqueued (page_factor) 
 - though I dont see a big value of such ACL limit; please provide a business 
 justification if there is
 - could _indirectly_ limit maximal size of the underlying file (that upper 
 limit is   page_factor*value_of_(/proc/sys/vm/max_map_count)  ) - as 
 max_map_count is usually high, it is less usefull
 Version-Release number of selected component (if applicable):
 any (incl. qpid 0.26)
 How reproducible:
 100%
 Steps to Reproduce:
 any user can run:
 qpid-config add queue my-paged-queue --argument qpid.paging=True --argument 
 qpid.max_pages_loaded=1 --argument qpid.page_factor=1
 Actual results:
 Any user can create paged queue of arbitrary parameters (paged queue related).
 Expected results:
 ACL parameters could prevent so.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Updated] (QPID-5485) Deleting paged queue does not remove underlying file

[Pavel Moravec (JIRA)]

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

Pavel Moravec updated QPID-5485:


Attachment: QPID-5485-new.2.patch
QPID-5485-new.1.patch

Two versions of patch provided.

First version (QPID-5485-new.1.patch) creates pagedQueues directory on demand 
(only). However when --paging-dir broker option is specified, lock file is 
created in the directory automatically, due to BrokerDefaults / 
Broker::Options. (if the option is not specified, no lock file is created).

That sudden appearing of lock file is quite surprising for an end user, hence 
simplified version of the patch (QPID-5485-new.2.patch) relies on 
BrokerDefaults / Broker::Options purely, such that paging-dir is created 
everytime during broker startup, and the lock file is there every time. It 
can be rewritten / deleted by creating / deleting queue named lock without 
any issue (well, as the broker keeps link to the file from elsewhere, deleting 
the lock queue the file disappears but remains invisible).

Another solution would be to have hardcoded directory name for paged queues 
files, hardcoded like rhm or qls names are. With the option to have 
symbolic link from the directory to any disk partition. Then no lock file will 
appear. But this would break backward compatibility as --paging-dir would be 
obsolete.. So I prefer option 2.

Your thoughts?

  Deleting paged queue does not remove underlying file
 -

 Key: QPID-5485
 URL: https://issues.apache.org/jira/browse/QPID-5485
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
 Environment: (any posix system)
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
  Labels: easyfix, easytest, patch
 Fix For: 0.27

 Attachments: QPID-5485-new.1.patch, QPID-5485-new.2.patch


 Description of problem:
 When deleting a paged queue, the broker does not delete the underlying file 
 it created in /var/lib/qpidd directory.
 Version-Release number of selected component (if applicable):
 MRG-M 3.0 EA (qpid-cpp 0.22-29)
 How reproducible:
 100%
 Steps to Reproduce:
 0. service qpiddd restart
 1. qpid-send -a PagedQueue; {create:always, delete:always, node: { 
 x-declare: {arguments: {'qpid.paging':'True' 
 2. file /var/lib/qpidd/PagedQueue 
 Actual results:
 /var/lib/qpidd/PagedQueue: data
 Expected results:
 /var/lib/qpidd/PagedQueue: cannot open `/var/lib/qpidd/PagedQueue' (No such 
 file or directory)
 Additional info:



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (QPID-5485) Deleting paged queue does not remove underlying file

[Pavel Moravec (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-5485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879888#comment-13879888
 ] 

Pavel Moravec commented on QPID-5485:
-

Andrew's proposal makes sense to me - I am about to write a patch for it and 
post it for review. TBD withing few working days (depending on my load 
meantime).

  Deleting paged queue does not remove underlying file
 -

 Key: QPID-5485
 URL: https://issues.apache.org/jira/browse/QPID-5485
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
 Environment: (any posix system)
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
  Labels: easyfix, easytest, patch
 Fix For: 0.27


 Description of problem:
 When deleting a paged queue, the broker does not delete the underlying file 
 it created in /var/lib/qpidd directory.
 Version-Release number of selected component (if applicable):
 MRG-M 3.0 EA (qpid-cpp 0.22-29)
 How reproducible:
 100%
 Steps to Reproduce:
 0. service qpiddd restart
 1. qpid-send -a PagedQueue; {create:always, delete:always, node: { 
 x-declare: {arguments: {'qpid.paging':'True' 
 2. file /var/lib/qpidd/PagedQueue 
 Actual results:
 /var/lib/qpidd/PagedQueue: data
 Expected results:
 /var/lib/qpidd/PagedQueue: cannot open `/var/lib/qpidd/PagedQueue' (No such 
 file or directory)
 Additional info:



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Reopened] (QPID-5485) Deleting paged queue does not remove underlying file

[Pavel Moravec (JIRA)]

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

Pavel Moravec reopened QPID-5485:
-


Reopened due to ongoing discussion

  Deleting paged queue does not remove underlying file
 -

 Key: QPID-5485
 URL: https://issues.apache.org/jira/browse/QPID-5485
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
 Environment: (any posix system)
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
  Labels: easyfix, easytest, patch
 Fix For: 0.27


 Description of problem:
 When deleting a paged queue, the broker does not delete the underlying file 
 it created in /var/lib/qpidd directory.
 Version-Release number of selected component (if applicable):
 MRG-M 3.0 EA (qpid-cpp 0.22-29)
 How reproducible:
 100%
 Steps to Reproduce:
 0. service qpiddd restart
 1. qpid-send -a PagedQueue; {create:always, delete:always, node: { 
 x-declare: {arguments: {'qpid.paging':'True' 
 2. file /var/lib/qpidd/PagedQueue 
 Actual results:
 /var/lib/qpidd/PagedQueue: data
 Expected results:
 /var/lib/qpidd/PagedQueue: cannot open `/var/lib/qpidd/PagedQueue' (No such 
 file or directory)
 Additional info:



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (QPID-5485) Deleting paged queue does not remove underlying file

[Pavel Moravec (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-5485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875608#comment-13875608
 ] 

Pavel Moravec commented on QPID-5485:
-

FYI there is broker option --paging-dir available. Note that having approach 
don't ulink after creating and prevent file overwrite can cause infinite 
broker restart loop when:
1) broker abruptly died due to some reason, leaving the orphaned files
2) Broker set to automatically restart (i.e. due to rgmanager or whatever else 
way), but its kick-off is terminated when durable paged queue is to be restored


So what about the approach:

1) if paging-dir is set:
  - allow overwriting files (O_TRUNC), assuming the directory contains only 
paged queue files
  - don't ulink files just after created them (do so only when deleting the 
queue)
2) if paging-dir is _not_ set:
  - preventivelly disallow overwriting files (O_EXCL), to protect lock file, 
sasldb or so
  - ulink files just after created them - to prevent potential broker restart 
infinite loop as above

First option is for those admins who likely see everything on their place, the 
second option is for those who dont care (and want everything working somewhere 
on (not visible) background).

Or is the idea too complicated? (and also I need to review the code how easy to 
implement the is paging-dir set? test on the _right_ place)


  Deleting paged queue does not remove underlying file
 -

 Key: QPID-5485
 URL: https://issues.apache.org/jira/browse/QPID-5485
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
 Environment: (any posix system)
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
  Labels: easyfix, easytest, patch
 Fix For: 0.27


 Description of problem:
 When deleting a paged queue, the broker does not delete the underlying file 
 it created in /var/lib/qpidd directory.
 Version-Release number of selected component (if applicable):
 MRG-M 3.0 EA (qpid-cpp 0.22-29)
 How reproducible:
 100%
 Steps to Reproduce:
 0. service qpiddd restart
 1. qpid-send -a PagedQueue; {create:always, delete:always, node: { 
 x-declare: {arguments: {'qpid.paging':'True' 
 2. file /var/lib/qpidd/PagedQueue 
 Actual results:
 /var/lib/qpidd/PagedQueue: data
 Expected results:
 /var/lib/qpidd/PagedQueue: cannot open `/var/lib/qpidd/PagedQueue' (No such 
 file or directory)
 Additional info:



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (QPID-5485) Deleting paged queue does not remove underlying file

[Pavel Moravec (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-5485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874759#comment-13874759
 ] 

Pavel Moravec commented on QPID-5485:
-

So code like:

std::string MemoryMappedFile::open(const std::string name, const std::string 
directory)
{
std::string path = getFileName(name, directory);

int flags = O_CREAT | O_EXCL | O_RDWR;
int fd = ::open(path.c_str(), flags, S_IRUSR | S_IWUSR);
if (fd == -1) throw qpid::Exception(QPID_MSG(Failed to open memory mapped 
file   path  :   qpid::sys::strError(errno)   [flags=  flags  
]));
state-fd = fd;
::unlink(path.c_str());
return path;
}
void MemoryMappedFile::close(const std::string /*path*/)
{
::close(state-fd);
//::unlink(path.c_str());
}

is better? Checking it, I see no real file exists after creating PagedQueue as 
paged queue:

$ qpid-send -a PagedQueue; {create:always, node: { x-declare: {arguments: 
{'qpid.paging':'True'  -m 1000
$ file /home/pmoravec/.qpidd/PagedQueue
/home/pmoravec/.qpidd/PagedQueue: ERROR: cannot open 
`/home/pmoravec/.qpidd/PagedQueue' (No such file or directory)
$ lsof -p $(pgrep qpidd) | grep PagedQueue
qpidd   30992 pmoravec  DEL   REG   253,3  11407785 
/home/pmoravec/.qpidd/PagedQueue
qpidd   30992 pmoravec   13u  REG   253,3   131072 11407785 
/home/pmoravec/.qpidd/PagedQueue (deleted)
$

All operations I tried with the queue seem to work fine..

  Deleting paged queue does not remove underlying file
 -

 Key: QPID-5485
 URL: https://issues.apache.org/jira/browse/QPID-5485
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
 Environment: (any posix system)
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
  Labels: easyfix, easytest, patch
 Fix For: 0.27


 Description of problem:
 When deleting a paged queue, the broker does not delete the underlying file 
 it created in /var/lib/qpidd directory.
 Version-Release number of selected component (if applicable):
 MRG-M 3.0 EA (qpid-cpp 0.22-29)
 How reproducible:
 100%
 Steps to Reproduce:
 0. service qpiddd restart
 1. qpid-send -a PagedQueue; {create:always, delete:always, node: { 
 x-declare: {arguments: {'qpid.paging':'True' 
 2. file /var/lib/qpidd/PagedQueue 
 Actual results:
 /var/lib/qpidd/PagedQueue: data
 Expected results:
 /var/lib/qpidd/PagedQueue: cannot open `/var/lib/qpidd/PagedQueue' (No such 
 file or directory)
 Additional info:



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Created] (QPID-5485) Deleting paged queue does not remove underlying file

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5485:
---

 Summary:  Deleting paged queue does not remove underlying file
 Key: QPID-5485
 URL: https://issues.apache.org/jira/browse/QPID-5485
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
 Environment: (any posix system)
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor


Description of problem:
When deleting a paged queue, the broker does not delete the underlying file it 
created in /var/lib/qpidd directory.


Version-Release number of selected component (if applicable):
MRG-M 3.0 EA (qpid-cpp 0.22-29)


How reproducible:
100%


Steps to Reproduce:
0. service qpiddd restart
1. qpid-send -a PagedQueue; {create:always, delete:always, node: { x-declare: 
{arguments: {'qpid.paging':'True' 
2. file /var/lib/qpidd/PagedQueue 


Actual results:
/var/lib/qpidd/PagedQueue: data


Expected results:
/var/lib/qpidd/PagedQueue: cannot open `/var/lib/qpidd/PagedQueue' (No such 
file or directory)


Additional info:



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Resolved] (QPID-5485) Deleting paged queue does not remove underlying file

[Pavel Moravec (JIRA)]

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

Pavel Moravec resolved QPID-5485.
-

   Resolution: Fixed
Fix Version/s: 0.27

  Deleting paged queue does not remove underlying file
 -

 Key: QPID-5485
 URL: https://issues.apache.org/jira/browse/QPID-5485
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
 Environment: (any posix system)
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
  Labels: easyfix, easytest, patch
 Fix For: 0.27


 Description of problem:
 When deleting a paged queue, the broker does not delete the underlying file 
 it created in /var/lib/qpidd directory.
 Version-Release number of selected component (if applicable):
 MRG-M 3.0 EA (qpid-cpp 0.22-29)
 How reproducible:
 100%
 Steps to Reproduce:
 0. service qpiddd restart
 1. qpid-send -a PagedQueue; {create:always, delete:always, node: { 
 x-declare: {arguments: {'qpid.paging':'True' 
 2. file /var/lib/qpidd/PagedQueue 
 Actual results:
 /var/lib/qpidd/PagedQueue: data
 Expected results:
 /var/lib/qpidd/PagedQueue: cannot open `/var/lib/qpidd/PagedQueue' (No such 
 file or directory)
 Additional info:



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Closed] (QPID-5485) Deleting paged queue does not remove underlying file

[Pavel Moravec (JIRA)]

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

Pavel Moravec closed QPID-5485.
---


  Deleting paged queue does not remove underlying file
 -

 Key: QPID-5485
 URL: https://issues.apache.org/jira/browse/QPID-5485
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
 Environment: (any posix system)
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
  Labels: easyfix, easytest, patch
 Fix For: 0.27


 Description of problem:
 When deleting a paged queue, the broker does not delete the underlying file 
 it created in /var/lib/qpidd directory.
 Version-Release number of selected component (if applicable):
 MRG-M 3.0 EA (qpid-cpp 0.22-29)
 How reproducible:
 100%
 Steps to Reproduce:
 0. service qpiddd restart
 1. qpid-send -a PagedQueue; {create:always, delete:always, node: { 
 x-declare: {arguments: {'qpid.paging':'True' 
 2. file /var/lib/qpidd/PagedQueue 
 Actual results:
 /var/lib/qpidd/PagedQueue: data
 Expected results:
 /var/lib/qpidd/PagedQueue: cannot open `/var/lib/qpidd/PagedQueue' (No such 
 file or directory)
 Additional info:



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Created] (QPID-5486) Creating paged queue can overwrite existing qpidd files

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5486:
---

 Summary: Creating paged queue can overwrite existing qpidd files
 Key: QPID-5486
 URL: https://issues.apache.org/jira/browse/QPID-5486
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Trivial


Description of problem:
When creating paged queue, there is no check whether the file 
/var/lib/qpidd/queue_name exists or not. Hence it is possible to rewrite 
files like lock or systemId there.

(Severity of the bug depends on importance of these files for the broker, that 
apparently is fine to be started with the files overwritten)

Note that creating a file named e.g. rhm (that is directory in 
/var/lib/qpidd) is disallowed even now.


Version-Release number of selected component (if applicable):
0.27 (current upstream)


How reproducible:
100%


Steps to Reproduce:
qpid-send -a lock; {create:always, delete:always, node: { x-declare: 
{arguments: {'qpid.paging':'True' 
echo $?
qpid-send -a systemId; {create:always, delete:always, node: { x-declare: 
{arguments: {'qpid.paging':'True' 
echo $?

Actual results:
0
0


Expected results:
Both should return an error like:
qpid-send: framing-error: Attempting to re-write file 
/home/pmoravec/.qpidd/systemId for paged queue systemId 
(/home/pmoravec/qpid-trunk/qpid/cpp/src/qpid/sys/posix/MemoryMappedFile.cpp:68)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Closed] (QPID-5486) Creating paged queue can overwrite existing qpidd files

[Pavel Moravec (JIRA)]

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

Pavel Moravec closed QPID-5486.
---


 Creating paged queue can overwrite existing qpidd files
 ---

 Key: QPID-5486
 URL: https://issues.apache.org/jira/browse/QPID-5486
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Trivial
  Labels: easy, easyfix, easytest, patch
 Fix For: 0.27

   Original Estimate: 1h
  Remaining Estimate: 1h

 Description of problem:
 When creating paged queue, there is no check whether the file 
 /var/lib/qpidd/queue_name exists or not. Hence it is possible to rewrite 
 files like lock or systemId there.
 (Severity of the bug depends on importance of these files for the broker, 
 that apparently is fine to be started with the files overwritten)
 Note that creating a file named e.g. rhm (that is directory in 
 /var/lib/qpidd) is disallowed even now.
 Version-Release number of selected component (if applicable):
 0.27 (current upstream)
 How reproducible:
 100%
 Steps to Reproduce:
 qpid-send -a lock; {create:always, delete:always, node: { x-declare: 
 {arguments: {'qpid.paging':'True' 
 echo $?
 qpid-send -a systemId; {create:always, delete:always, node: { x-declare: 
 {arguments: {'qpid.paging':'True' 
 echo $?
 Actual results:
 0
 0
 Expected results:
 Both should return an error like:
 qpid-send: framing-error: Attempting to re-write file 
 /home/pmoravec/.qpidd/systemId for paged queue systemId 
 (/home/pmoravec/qpid-trunk/qpid/cpp/src/qpid/sys/posix/MemoryMappedFile.cpp:68)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Resolved] (QPID-5486) Creating paged queue can overwrite existing qpidd files

[Pavel Moravec (JIRA)]

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

Pavel Moravec resolved QPID-5486.
-

   Resolution: Fixed
Fix Version/s: 0.27

 Creating paged queue can overwrite existing qpidd files
 ---

 Key: QPID-5486
 URL: https://issues.apache.org/jira/browse/QPID-5486
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Trivial
  Labels: easy, easyfix, easytest, patch
 Fix For: 0.27

   Original Estimate: 1h
  Remaining Estimate: 1h

 Description of problem:
 When creating paged queue, there is no check whether the file 
 /var/lib/qpidd/queue_name exists or not. Hence it is possible to rewrite 
 files like lock or systemId there.
 (Severity of the bug depends on importance of these files for the broker, 
 that apparently is fine to be started with the files overwritten)
 Note that creating a file named e.g. rhm (that is directory in 
 /var/lib/qpidd) is disallowed even now.
 Version-Release number of selected component (if applicable):
 0.27 (current upstream)
 How reproducible:
 100%
 Steps to Reproduce:
 qpid-send -a lock; {create:always, delete:always, node: { x-declare: 
 {arguments: {'qpid.paging':'True' 
 echo $?
 qpid-send -a systemId; {create:always, delete:always, node: { x-declare: 
 {arguments: {'qpid.paging':'True' 
 echo $?
 Actual results:
 0
 0
 Expected results:
 Both should return an error like:
 qpid-send: framing-error: Attempting to re-write file 
 /home/pmoravec/.qpidd/systemId for paged queue systemId 
 (/home/pmoravec/qpid-trunk/qpid/cpp/src/qpid/sys/posix/MemoryMappedFile.cpp:68)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Created] (QPID-5424) [C++ broker] [AMQP 1.0] wrong encoding/decoding of boolean type

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5424:
---

 Summary: [C++ broker] [AMQP 1.0] wrong encoding/decoding of 
boolean type
 Key: QPID-5424
 URL: https://issues.apache.org/jira/browse/QPID-5424
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker, C++ Client
Affects Versions: 0.24, 0.22
Reporter: Pavel Moravec


Both encoding/decoding AMQP 1.0 boolean primitive type seems to be wrong - it 
lacks specifying type constructor (0x56).

E.g. taking tcpdump of a client communication, I got PDU:

008e025312d0007e000aa12d6d795175657565325f66373562326532622d613930392d343063612d393832652d653236303862343936365200415002505328d0001a000ba1086d79517565756532520040520042404040404040005329d000160007a1086d79517565756532520040520042404040405200

that is disassembled to:

008e = size(142)
0200 = rest of header
00(descriptor_constructor) 53(fixed_one) 12(attach performative)
d0 = compound-four, i.e. list32
  007e(size=126)
  000a(count=10)
  (Name):  a1(str8) 2d(len=45) 
6d795175657565325f66373562326532622d613930392d343063612d393832652d65323630386234393636(myQueue2_f75b2e2b-a909-40ca-982e-e2608ffb4966)
  (Handle):  52(smalluint) 00(0)
  (Role):  41.. = boolean value???


I see this reoccuring in any tcpdump I take - sometimes with Role 0x41 
(true), sometimes 0x42 (false), depending on receiver/sender role of the 
peer.

As the bug is present both in encode and decode, neither broker or client 
complains of malformed PDU.

I see it in 0.22 while assume it in upstream as well (no change in relevant 
source code since that).




--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

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

[jira] [Assigned] (QPID-5281) Creating a queue with invalid settings results in no queue but only its management object exists

[Pavel Moravec (JIRA)]

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

Pavel Moravec reassigned QPID-5281:
---

Assignee: Pavel Moravec

 Creating a queue with invalid settings results in no queue but only its 
 management object exists
 

 Key: QPID-5281
 URL: https://issues.apache.org/jira/browse/QPID-5281
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor

 Description of problem:
 An attempt to create a queue with invalid settings (like max-queue-count  
 flow-stop-count) returns a QMF error and the queue is not created (can't send 
 messages there or subscribe a consumer to it). But relevant QMF object is 
 still present (listing all queues finds it).
 Version-Release number of selected component (if applicable):
 any (incl. 0.24 and upstream)
 How reproducible:
 100%
 Steps to Reproduce:
 0. rm -rf /var/lib/qpidd/* /var/lib/qpidd/.*; service qpidd restart
 1. qpid-config add queue WrongQueue1 --max-queue-count=1 
 --flow-stop-count=100 --durable
 2. qpid-send -a WrongQueue1 -m1
 3. qpid-config queues WrongQueue1
 Actual results:
 1. returns:
 Failed: Exception: Exception from Agent: {u'error_code': 7, u'error_text': 
 'invalid-argument: Queue WrongQueue1: qpid.flow_stop_count=100 must be less 
 than qpid.max_count=1 
 (/builddir/build/BUILD/qpid-0.24/cpp/src/qpid/broker/QueueFlowLimit.cpp:58)'}
 2. returns:
 2013-10-30 07:57:18 [Client] warning Exception received from broker: 
 not-found: not-found: Queue not found: WrongQueue1 
 (/builddir/build/BUILD/qpid-0.24/cpp/src/qpid/broker/QueueRegistry.cpp:127) 
 [caused by 2 \x08:\x01]
 qpid-send: Queue WrongQueue1 does not exist
 3. returns:
 Queue Name   Attributes
 ===
 WrongQueue1  --durable --max-queue-count=1 --flow-stop-count=100 
 Expected results:
 1. and 2. as actual results, but 3. should return no such queue
 Additional info:
 Continuing in the reproducer, restarting the broker and running qpid-config 
 queues WrongQueue1 again shows no such queue exists - despite the queue was 
 attempted to be created as durable. That just supports the theory that Queue 
 object has not been created but its Management version was.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Closed] (QPID-5278) Queue flow limit validation ignores size parameters

[Pavel Moravec (JIRA)]

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

Pavel Moravec closed QPID-5278.
---


 Queue flow limit validation ignores size parameters
 ---

 Key: QPID-5278
 URL: https://issues.apache.org/jira/browse/QPID-5278
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
 Fix For: Future


 Broker allows a queue creation with --max-queue-size=1 --flow-stop-size=100.
 Further, creating a queue with max-queue-(count|size) and _bigger_ 
 flow-resume-(count|size) (and no flow-stop set) is allowed as well:
 I.e. from commands:
 qpid-config add queue WrongQueue1 --max-queue-count=1 --flow-stop-count=100 
 --durable
 qpid-config add queue WrongQueue2 --max-queue-count=1 --flow-resume-count=100 
 --durable
 qpid-config add queue WrongQueue3 --max-queue-size=1 --flow-stop-size=100 
 --durable
 qpid-config add queue WrongQueue4 --max-queue-size=1 --flow-resume-size=100 
 --durable
 All queues except the first one are created.
 (it is discutable if e.g. max-queue-count=1 flow-resume-count=100 should be 
 allowed or not, as the logic is flow control defaults are changed only if 
 flow-stop-* parameter is used)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Resolved] (QPID-5281) Creating a queue with invalid settings results in no queue but only its management object exists

[Pavel Moravec (JIRA)]

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

Pavel Moravec resolved QPID-5281.
-

   Resolution: Fixed
Fix Version/s: Future

Fixed by commit r1543449.

 Creating a queue with invalid settings results in no queue but only its 
 management object exists
 

 Key: QPID-5281
 URL: https://issues.apache.org/jira/browse/QPID-5281
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
 Fix For: Future


 Description of problem:
 An attempt to create a queue with invalid settings (like max-queue-count  
 flow-stop-count) returns a QMF error and the queue is not created (can't send 
 messages there or subscribe a consumer to it). But relevant QMF object is 
 still present (listing all queues finds it).
 Version-Release number of selected component (if applicable):
 any (incl. 0.24 and upstream)
 How reproducible:
 100%
 Steps to Reproduce:
 0. rm -rf /var/lib/qpidd/* /var/lib/qpidd/.*; service qpidd restart
 1. qpid-config add queue WrongQueue1 --max-queue-count=1 
 --flow-stop-count=100 --durable
 2. qpid-send -a WrongQueue1 -m1
 3. qpid-config queues WrongQueue1
 Actual results:
 1. returns:
 Failed: Exception: Exception from Agent: {u'error_code': 7, u'error_text': 
 'invalid-argument: Queue WrongQueue1: qpid.flow_stop_count=100 must be less 
 than qpid.max_count=1 
 (/builddir/build/BUILD/qpid-0.24/cpp/src/qpid/broker/QueueFlowLimit.cpp:58)'}
 2. returns:
 2013-10-30 07:57:18 [Client] warning Exception received from broker: 
 not-found: not-found: Queue not found: WrongQueue1 
 (/builddir/build/BUILD/qpid-0.24/cpp/src/qpid/broker/QueueRegistry.cpp:127) 
 [caused by 2 \x08:\x01]
 qpid-send: Queue WrongQueue1 does not exist
 3. returns:
 Queue Name   Attributes
 ===
 WrongQueue1  --durable --max-queue-count=1 --flow-stop-count=100 
 Expected results:
 1. and 2. as actual results, but 3. should return no such queue
 Additional info:
 Continuing in the reproducer, restarting the broker and running qpid-config 
 queues WrongQueue1 again shows no such queue exists - despite the queue was 
 attempted to be created as durable. That just supports the theory that Queue 
 object has not been created but its Management version was.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Resolved] (QPID-5278) Queue flow limit validation ignores size parameters

[Pavel Moravec (JIRA)]

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

Pavel Moravec resolved QPID-5278.
-

   Resolution: Fixed
Fix Version/s: Future

Fixed by commit r1543449.

 Queue flow limit validation ignores size parameters
 ---

 Key: QPID-5278
 URL: https://issues.apache.org/jira/browse/QPID-5278
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
 Fix For: Future


 Broker allows a queue creation with --max-queue-size=1 --flow-stop-size=100.
 Further, creating a queue with max-queue-(count|size) and _bigger_ 
 flow-resume-(count|size) (and no flow-stop set) is allowed as well:
 I.e. from commands:
 qpid-config add queue WrongQueue1 --max-queue-count=1 --flow-stop-count=100 
 --durable
 qpid-config add queue WrongQueue2 --max-queue-count=1 --flow-resume-count=100 
 --durable
 qpid-config add queue WrongQueue3 --max-queue-size=1 --flow-stop-size=100 
 --durable
 qpid-config add queue WrongQueue4 --max-queue-size=1 --flow-resume-size=100 
 --durable
 All queues except the first one are created.
 (it is discutable if e.g. max-queue-count=1 flow-resume-count=100 should be 
 allowed or not, as the logic is flow control defaults are changed only if 
 flow-stop-* parameter is used)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Closed] (QPID-5281) Creating a queue with invalid settings results in no queue but only its management object exists

[Pavel Moravec (JIRA)]

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

Pavel Moravec closed QPID-5281.
---


 Creating a queue with invalid settings results in no queue but only its 
 management object exists
 

 Key: QPID-5281
 URL: https://issues.apache.org/jira/browse/QPID-5281
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
 Fix For: Future


 Description of problem:
 An attempt to create a queue with invalid settings (like max-queue-count  
 flow-stop-count) returns a QMF error and the queue is not created (can't send 
 messages there or subscribe a consumer to it). But relevant QMF object is 
 still present (listing all queues finds it).
 Version-Release number of selected component (if applicable):
 any (incl. 0.24 and upstream)
 How reproducible:
 100%
 Steps to Reproduce:
 0. rm -rf /var/lib/qpidd/* /var/lib/qpidd/.*; service qpidd restart
 1. qpid-config add queue WrongQueue1 --max-queue-count=1 
 --flow-stop-count=100 --durable
 2. qpid-send -a WrongQueue1 -m1
 3. qpid-config queues WrongQueue1
 Actual results:
 1. returns:
 Failed: Exception: Exception from Agent: {u'error_code': 7, u'error_text': 
 'invalid-argument: Queue WrongQueue1: qpid.flow_stop_count=100 must be less 
 than qpid.max_count=1 
 (/builddir/build/BUILD/qpid-0.24/cpp/src/qpid/broker/QueueFlowLimit.cpp:58)'}
 2. returns:
 2013-10-30 07:57:18 [Client] warning Exception received from broker: 
 not-found: not-found: Queue not found: WrongQueue1 
 (/builddir/build/BUILD/qpid-0.24/cpp/src/qpid/broker/QueueRegistry.cpp:127) 
 [caused by 2 \x08:\x01]
 qpid-send: Queue WrongQueue1 does not exist
 3. returns:
 Queue Name   Attributes
 ===
 WrongQueue1  --durable --max-queue-count=1 --flow-stop-count=100 
 Expected results:
 1. and 2. as actual results, but 3. should return no such queue
 Additional info:
 Continuing in the reproducer, restarting the broker and running qpid-config 
 queues WrongQueue1 again shows no such queue exists - despite the queue was 
 attempted to be created as durable. That just supports the theory that Queue 
 object has not been created but its Management version was.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Updated] (QPID-5278) Queue flow limit validation ignores size parameters

[Pavel Moravec (JIRA)]

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

Pavel Moravec updated QPID-5278:


Description: 
Broker allows a queue creation with --max-queue-size=1 --flow-stop-size=100.

Further, creating a queue with max-queue-(count|size) and _bigger_ 
flow-resume-(count|size) (and no flow-stop set) is allowed as well:

I.e. from commands:
qpid-config add queue WrongQueue1 --max-queue-count=1 --flow-stop-count=100 
--durable
qpid-config add queue WrongQueue2 --max-queue-count=1 --flow-resume-count=100 
--durable
qpid-config add queue WrongQueue3 --max-queue-size=1 --flow-stop-size=100 
--durable
qpid-config add queue WrongQueue4 --max-queue-size=1 --flow-resume-size=100 
--durable

All queues except the first one are created.

(it is discutable if e.g. max-queue-count=1 flow-resume-count=100 should be 
allowed or not, as the logic is flow control defaults are changed only if 
flow-stop-* parameter is used)




  was:
Broker allows a queue creation with --max-queue-size=1 --flow-stop-size=100.

Further, creating a queue with max-queue-[count|size] and _bigger_ 
flow-resume-[count|size] (and no flow-stop set) is allowed as well:

I.e. from commands:
qpid-config add queue WrongQueue1 --max-queue-count=1 --flow-stop-count=100 
--durable
qpid-config add queue WrongQueue2 --max-queue-count=1 --flow-resume-count=100 
--durable
qpid-config add queue WrongQueue3 --max-queue-size=1 --flow-stop-size=100 
--durable
qpid-config add queue WrongQueue4 --max-queue-size=1 --flow-resume-size=100 
--durable

All queues except the first one are created.

(it is discutable if e.g. max-queue-count=1 flow-resume-count=100 should be 
allowed or not, as the logic is flow control defaults are changed only if 
flow-stop-* parameter is used)





 Queue flow limit validation ignores size parameters
 ---

 Key: QPID-5278
 URL: https://issues.apache.org/jira/browse/QPID-5278
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor

 Broker allows a queue creation with --max-queue-size=1 --flow-stop-size=100.
 Further, creating a queue with max-queue-(count|size) and _bigger_ 
 flow-resume-(count|size) (and no flow-stop set) is allowed as well:
 I.e. from commands:
 qpid-config add queue WrongQueue1 --max-queue-count=1 --flow-stop-count=100 
 --durable
 qpid-config add queue WrongQueue2 --max-queue-count=1 --flow-resume-count=100 
 --durable
 qpid-config add queue WrongQueue3 --max-queue-size=1 --flow-stop-size=100 
 --durable
 qpid-config add queue WrongQueue4 --max-queue-size=1 --flow-resume-size=100 
 --durable
 All queues except the first one are created.
 (it is discutable if e.g. max-queue-count=1 flow-resume-count=100 should be 
 allowed or not, as the logic is flow control defaults are changed only if 
 flow-stop-* parameter is used)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Updated] (QPID-5278) Queue flow limit validation ignores size parameters

[Pavel Moravec (JIRA)]

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

Pavel Moravec updated QPID-5278:


Description: 
Broker allows a queue creation with --max-queue-size=1 --flow-stop-size=100.

Further, creating a queue with max-queue-[count|size] and _bigger_ 
flow-resume-[count|size] (and no flow-stop set) is allowed as well:

I.e. from commands:
qpid-config add queue WrongQueue1 --max-queue-count=1 --flow-stop-count=100 
--durable
qpid-config add queue WrongQueue2 --max-queue-count=1 --flow-resume-count=100 
--durable
qpid-config add queue WrongQueue3 --max-queue-size=1 --flow-stop-size=100 
--durable
qpid-config add queue WrongQueue4 --max-queue-size=1 --flow-resume-size=100 
--durable

All queues except the first one are created.

(it is discutable if e.g. max-queue-count=1 flow-resume-count=100 should be 
allowed or not, as the logic is flow control defaults are changed only if 
flow-stop-* parameter is used)




  was:
Broker allows a queue creation with --max-queue-size=1 --flow-stop-size=100.

Further, creating a queue with max-queue-[count|size] and _bigger_ 
flow-resume-[count|size] (and no flow-stop set) is allowed as well:

I.e. from commands:
qpid-config add queue WrongQueue1 --max-queue-count=1 --flow-stop-count=100 
--durable
qpid-config add queue WrongQueue2 --max-queue-count=1 --flow-resume-count=100 
--durable
qpid-config add queue WrongQueue3 --max-queue-size=1 --flow-stop-size=100 
--durable
qpid-config add queue WrongQueue4 --max-queue-size=1 --flow-resume-size=100 
--durable

All queues except the first one are created.

(it is discutable if e.g. --max-queue-count=1 --flow-resume-count=100 should 
be allowed or not, as the logic is flow control defaults are changed only if 
flow-stop-* parameter is used)





 Queue flow limit validation ignores size parameters
 ---

 Key: QPID-5278
 URL: https://issues.apache.org/jira/browse/QPID-5278
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor

 Broker allows a queue creation with --max-queue-size=1 --flow-stop-size=100.
 Further, creating a queue with max-queue-[count|size] and _bigger_ 
 flow-resume-[count|size] (and no flow-stop set) is allowed as well:
 I.e. from commands:
 qpid-config add queue WrongQueue1 --max-queue-count=1 --flow-stop-count=100 
 --durable
 qpid-config add queue WrongQueue2 --max-queue-count=1 --flow-resume-count=100 
 --durable
 qpid-config add queue WrongQueue3 --max-queue-size=1 --flow-stop-size=100 
 --durable
 qpid-config add queue WrongQueue4 --max-queue-size=1 --flow-resume-size=100 
 --durable
 All queues except the first one are created.
 (it is discutable if e.g. max-queue-count=1 flow-resume-count=100 should be 
 allowed or not, as the logic is flow control defaults are changed only if 
 flow-stop-* parameter is used)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Created] (QPID-5281) Creating a queue with invalid settings results in no queue but only its management object exists

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5281:
---

 Summary: Creating a queue with invalid settings results in no 
queue but only its management object exists
 Key: QPID-5281
 URL: https://issues.apache.org/jira/browse/QPID-5281
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Priority: Minor


Description of problem:
An attempt to create a queue with invalid settings (like max-queue-count  
flow-stop-count) returns a QMF error and the queue is not created (can't send 
messages there or subscribe a consumer to it). But relevant QMF object is still 
present (listing all queues finds it).


Version-Release number of selected component (if applicable):
any (incl. 0.24 and upstream)


How reproducible:
100%


Steps to Reproduce:
0. rm -rf /var/lib/qpidd/* /var/lib/qpidd/.*; service qpidd restart
1. qpid-config add queue WrongQueue1 --max-queue-count=1 --flow-stop-count=100 
--durable
2. qpid-send -a WrongQueue1 -m1
3. qpid-config queues WrongQueue1


Actual results:
1. returns:
Failed: Exception: Exception from Agent: {u'error_code': 7, u'error_text': 
'invalid-argument: Queue WrongQueue1: qpid.flow_stop_count=100 must be less 
than qpid.max_count=1 
(/builddir/build/BUILD/qpid-0.24/cpp/src/qpid/broker/QueueFlowLimit.cpp:58)'}

2. returns:
2013-10-30 07:57:18 [Client] warning Exception received from broker: not-found: 
not-found: Queue not found: WrongQueue1 
(/builddir/build/BUILD/qpid-0.24/cpp/src/qpid/broker/QueueRegistry.cpp:127) 
[caused by 2 \x08:\x01]
qpid-send: Queue WrongQueue1 does not exist

3. returns:
Queue Name   Attributes
===
WrongQueue1  --durable --max-queue-count=1 --flow-stop-count=100 


Expected results:
1. and 2. as actual results, but 3. should return no such queue


Additional info:
Continuing in the reproducer, restarting the broker and running qpid-config 
queues WrongQueue1 again shows no such queue exists - despite the queue was 
attempted to be created as durable. That just supports the theory that Queue 
object has not been created but its Management version was.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Created] (QPID-5278) Queue flow limit validation ignores size parameters

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5278:
---

 Summary: Queue flow limit validation ignores size parameters
 Key: QPID-5278
 URL: https://issues.apache.org/jira/browse/QPID-5278
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor


Broker allows a queue creation with --max-queue-size=1 --flow-stop-size=100.

Further, creating a queue with max-queue-[count|size] and _bigger_ 
flow-resume-[count|size] (and no flow-stop set) is allowed as well:

I.e. from commands:
qpid-config add queue WrongQueue1 --max-queue-count=1 --flow-stop-count=100 
--durable
qpid-config add queue WrongQueue2 --max-queue-count=1 --flow-resume-count=100 
--durable
qpid-config add queue WrongQueue3 --max-queue-size=1 --flow-stop-size=100 
--durable
qpid-config add queue WrongQueue4 --max-queue-size=1 --flow-resume-size=100 
--durable

All queues except the first one are created.

(it is discutable if e.g. --max-queue-count=1 --flow-resume-count=100 should 
be allowed or not, as the logic is flow control defaults are changed only if 
flow-stop-* parameter is used)






--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (QPID-5203) Python client unexpected exception after ACL denial

[Pavel Moravec (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-5203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13807893#comment-13807893
 ] 

Pavel Moravec commented on QPID-5203:
-

I agree with Gordon's proposal. Patch is fine, simplier than mine and works 
properly.

 Python client unexpected exception after ACL denial
 ---

 Key: QPID-5203
 URL: https://issues.apache.org/jira/browse/QPID-5203
 Project: Qpid
  Issue Type: Bug
  Components: Python Client
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
 Fix For: 0.25

 Attachments: bz974940.py, QPID-5203-suggested.patch


 Description of problem:
 After ACL denies a command from qpid Python client, an attempt to close 
 either session or connection raises unexpected exception (relevant to ACL, 
 though). While at that time, session is properly closed and connection is 
 working fine.
 Version-Release number of selected component (if applicable):
 every
 How reproducible:
 100%
 Steps to Reproduce:
 1. Have ACL file:
 acl deny all consume all
 acl allow all all
 2. Run attached script.
 Actual results:
 
 Create receiver failed with exception
 Traceback (most recent call last):
   File ACL_denial_session-hang.py, line 13, in module
 recv = session.receiver('testQ; {create:always}')
   File string, line 6, in receiver
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 616, in receiver
 receiver._ewait(lambda: receiver.linked)
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 973, in _ewait
 result = self.session._ewait(lambda: self.error or predicate(), timeout)
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 567, in _ewait
 self.check_error()
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 556, in check_error
 raise self.error
 UnauthorizedAccess: unauthorized-access: ACL denied Queue subscribe request 
 from guest@QPID (qpid/broker/SessionAdapter.cpp:399)(403)
 
 Session close failed with exception
 Traceback (most recent call last):
   File ACL_denial_session-hang.py, line 19, in module
 session.close()
   File string, line 6, in close
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 739, in close
 self.sync(timeout=timeout)
   File string, line 6, in sync
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 731, in sync
 if not self._ewait(lambda: not self.outgoing and not self.acked, 
 timeout=timeout):
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 567, in _ewait
 self.check_error()
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 556, in check_error
 raise self.error
 UnauthorizedAccess: unauthorized-access: ACL denied Queue subscribe request 
 from guest@QPID (qpid/broker/SessionAdapter.cpp:399)(403)
 
 Connection close failed with exception
 Traceback (most recent call last):
   File ACL_denial_session-hang.py, line 25, in module
 connection.close()
   File string, line 6, in close
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 316, in close
 ssn.close(timeout=timeout)
   File string, line 6, in close
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 739, in close
 self.sync(timeout=timeout)
   File string, line 6, in sync
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 731, in sync
 if not self._ewait(lambda: not self.outgoing and not self.acked, 
 timeout=timeout):
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 567, in _ewait
 self.check_error()
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 556, in check_error
 raise self.error
 UnauthorizedAccess: unauthorized-access: ACL denied Queue subscribe request 
 from guest@QPID (qpid/broker/SessionAdapter.cpp:399)(403)
 Expected results:
 Just the first exception is printed - when the session.receiver fails due 
 to ACL.
 Additional info:
 Some hints for fixing it:
 - session object is properly closed. Just an attempt to close it again raises 
 that exception. When trying to close a closed session without an ACL deny, no 
 exception is raised
 - connection object is properly working and closing it really closes the AMQP 
 connection. And the connection object can be normally used later on.
 - it seems to me like:
 

[jira] [Resolved] (QPID-5203) Python client unexpected exception after ACL denial

[Pavel Moravec (JIRA)]

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

Pavel Moravec resolved QPID-5203.
-

   Resolution: Fixed
Fix Version/s: 0.25

Committed in r1534643.

 Python client unexpected exception after ACL denial
 ---

 Key: QPID-5203
 URL: https://issues.apache.org/jira/browse/QPID-5203
 Project: Qpid
  Issue Type: Bug
  Components: Python Client
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
 Fix For: 0.25

 Attachments: bz974940.py


 Description of problem:
 After ACL denies a command from qpid Python client, an attempt to close 
 either session or connection raises unexpected exception (relevant to ACL, 
 though). While at that time, session is properly closed and connection is 
 working fine.
 Version-Release number of selected component (if applicable):
 every
 How reproducible:
 100%
 Steps to Reproduce:
 1. Have ACL file:
 acl deny all consume all
 acl allow all all
 2. Run attached script.
 Actual results:
 
 Create receiver failed with exception
 Traceback (most recent call last):
   File ACL_denial_session-hang.py, line 13, in module
 recv = session.receiver('testQ; {create:always}')
   File string, line 6, in receiver
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 616, in receiver
 receiver._ewait(lambda: receiver.linked)
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 973, in _ewait
 result = self.session._ewait(lambda: self.error or predicate(), timeout)
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 567, in _ewait
 self.check_error()
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 556, in check_error
 raise self.error
 UnauthorizedAccess: unauthorized-access: ACL denied Queue subscribe request 
 from guest@QPID (qpid/broker/SessionAdapter.cpp:399)(403)
 
 Session close failed with exception
 Traceback (most recent call last):
   File ACL_denial_session-hang.py, line 19, in module
 session.close()
   File string, line 6, in close
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 739, in close
 self.sync(timeout=timeout)
   File string, line 6, in sync
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 731, in sync
 if not self._ewait(lambda: not self.outgoing and not self.acked, 
 timeout=timeout):
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 567, in _ewait
 self.check_error()
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 556, in check_error
 raise self.error
 UnauthorizedAccess: unauthorized-access: ACL denied Queue subscribe request 
 from guest@QPID (qpid/broker/SessionAdapter.cpp:399)(403)
 
 Connection close failed with exception
 Traceback (most recent call last):
   File ACL_denial_session-hang.py, line 25, in module
 connection.close()
   File string, line 6, in close
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 316, in close
 ssn.close(timeout=timeout)
   File string, line 6, in close
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 739, in close
 self.sync(timeout=timeout)
   File string, line 6, in sync
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 731, in sync
 if not self._ewait(lambda: not self.outgoing and not self.acked, 
 timeout=timeout):
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 567, in _ewait
 self.check_error()
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 556, in check_error
 raise self.error
 UnauthorizedAccess: unauthorized-access: ACL denied Queue subscribe request 
 from guest@QPID (qpid/broker/SessionAdapter.cpp:399)(403)
 Expected results:
 Just the first exception is printed - when the session.receiver fails due 
 to ACL.
 Additional info:
 Some hints for fixing it:
 - session object is properly closed. Just an attempt to close it again raises 
 that exception. When trying to close a closed session without an ACL deny, no 
 exception is raised
 - connection object is properly working and closing it really closes the AMQP 
 connection. And the connection object can be normally used later on.
 - it seems to me like:
 a) exception raised and stored somewhere
 b) program catches it
 c) Python library should delete 

[jira] [Closed] (QPID-5203) Python client unexpected exception after ACL denial

[Pavel Moravec (JIRA)]

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

Pavel Moravec closed QPID-5203.
---


 Python client unexpected exception after ACL denial
 ---

 Key: QPID-5203
 URL: https://issues.apache.org/jira/browse/QPID-5203
 Project: Qpid
  Issue Type: Bug
  Components: Python Client
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
 Fix For: 0.25

 Attachments: bz974940.py


 Description of problem:
 After ACL denies a command from qpid Python client, an attempt to close 
 either session or connection raises unexpected exception (relevant to ACL, 
 though). While at that time, session is properly closed and connection is 
 working fine.
 Version-Release number of selected component (if applicable):
 every
 How reproducible:
 100%
 Steps to Reproduce:
 1. Have ACL file:
 acl deny all consume all
 acl allow all all
 2. Run attached script.
 Actual results:
 
 Create receiver failed with exception
 Traceback (most recent call last):
   File ACL_denial_session-hang.py, line 13, in module
 recv = session.receiver('testQ; {create:always}')
   File string, line 6, in receiver
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 616, in receiver
 receiver._ewait(lambda: receiver.linked)
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 973, in _ewait
 result = self.session._ewait(lambda: self.error or predicate(), timeout)
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 567, in _ewait
 self.check_error()
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 556, in check_error
 raise self.error
 UnauthorizedAccess: unauthorized-access: ACL denied Queue subscribe request 
 from guest@QPID (qpid/broker/SessionAdapter.cpp:399)(403)
 
 Session close failed with exception
 Traceback (most recent call last):
   File ACL_denial_session-hang.py, line 19, in module
 session.close()
   File string, line 6, in close
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 739, in close
 self.sync(timeout=timeout)
   File string, line 6, in sync
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 731, in sync
 if not self._ewait(lambda: not self.outgoing and not self.acked, 
 timeout=timeout):
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 567, in _ewait
 self.check_error()
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 556, in check_error
 raise self.error
 UnauthorizedAccess: unauthorized-access: ACL denied Queue subscribe request 
 from guest@QPID (qpid/broker/SessionAdapter.cpp:399)(403)
 
 Connection close failed with exception
 Traceback (most recent call last):
   File ACL_denial_session-hang.py, line 25, in module
 connection.close()
   File string, line 6, in close
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 316, in close
 ssn.close(timeout=timeout)
   File string, line 6, in close
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 739, in close
 self.sync(timeout=timeout)
   File string, line 6, in sync
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 731, in sync
 if not self._ewait(lambda: not self.outgoing and not self.acked, 
 timeout=timeout):
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 567, in _ewait
 self.check_error()
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 556, in check_error
 raise self.error
 UnauthorizedAccess: unauthorized-access: ACL denied Queue subscribe request 
 from guest@QPID (qpid/broker/SessionAdapter.cpp:399)(403)
 Expected results:
 Just the first exception is printed - when the session.receiver fails due 
 to ACL.
 Additional info:
 Some hints for fixing it:
 - session object is properly closed. Just an attempt to close it again raises 
 that exception. When trying to close a closed session without an ACL deny, no 
 exception is raised
 - connection object is properly working and closing it really closes the AMQP 
 connection. And the connection object can be normally used later on.
 - it seems to me like:
 a) exception raised and stored somewhere
 b) program catches it
 c) Python library should delete it from the stored place / variable but it 
 does not do so
 d) any action 

[jira] [Created] (QPID-5252) [C++ broker] log-enable option ignored in config file when used also in command line

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5252:
---

 Summary: [C++ broker] log-enable option ignored in config file 
when used also in command line
 Key: QPID-5252
 URL: https://issues.apache.org/jira/browse/QPID-5252
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Priority: Minor


Description of problem:
When specifying log-enable option both in command line and in configuration 
file, the option in command line is silently ignored.

This is low severity but high priority bug, as it delays customer problem 
investigation due to troubleshooting why adding the option to config file does 
not enable the desire logging.


Version-Release number of selected component (if applicable):
any (checked on 0.22-19 and 0.18-14)


How reproducible:
100%


Steps to Reproduce:
echo log-enable=trace+  qpidd.conf
qpidd --config qpidd.conf --log-enable info+ 21 | grep trace


Actual results:
no output


Expected results:
trace logs like:
2013-10-23 06:44:00 [Model] trace Mgmt create memory. id:amqp-broker

to appear


Additional info:
moving the option from config.file to command line causes it is applied properly



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Closed] (QPID-5252) [C++ broker] log-enable option ignored in config file when used also in command line

[Pavel Moravec (JIRA)]

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

Pavel Moravec closed QPID-5252.
---


I agree, I havent realized the behaviour of command line precedence applies 
also to the `log-enable` option that can be specified multiple times.

 [C++ broker] log-enable option ignored in config file when used also in 
 command line
 

 Key: QPID-5252
 URL: https://issues.apache.org/jira/browse/QPID-5252
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Ted Ross
Priority: Minor
  Labels: easytest

 Description of problem:
 When specifying log-enable option both in command line and in configuration 
 file, the option in command line is silently ignored.
 This is low severity but high priority bug, as it delays customer problem 
 investigation due to troubleshooting why adding the option to config file 
 does not enable the desire logging.
 Version-Release number of selected component (if applicable):
 any (checked on 0.22-19 and 0.18-14)
 How reproducible:
 100%
 Steps to Reproduce:
 echo log-enable=trace+  qpidd.conf
 qpidd --config qpidd.conf --log-enable info+ 21 | grep trace
 Actual results:
 no output
 Expected results:
 trace logs like:
 2013-10-23 06:44:00 [Model] trace Mgmt create memory. id:amqp-broker
 to appear
 Additional info:
 moving the option from config.file to command line causes it is applied 
 properly



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Created] (QPID-5214) [C++ broker] Memory leak in legacystore when raising RHM_IORES_ENQCAPTHRESH

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5214:
---

 Summary: [C++ broker] Memory leak in legacystore when raising 
RHM_IORES_ENQCAPTHRESH
 Key: QPID-5214
 URL: https://issues.apache.org/jira/browse/QPID-5214
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Priority: Minor


There is a memory leak when legacystore raises RHM_IORES_ENQCAPTHRESH: Enqueue 
capacity threshold exceeded on queue ... For reproducer, let try to send 
durable messages to a tiny journal queue in a loop.

Valgrind showed me:

==632== 2,288 (208 direct, 2,080 indirect) bytes in 2 blocks are definitely 
lost in loss record 115 of 116
==632==at 0x4A075BC: operator new(unsigned long) (vg_replace_malloc.c:298)
==632==by 0x60D76AB: 
mrg::msgstore::MessageStoreImpl::store(qpid::broker::PersistableQueue const*, 
mrg::msgstore::TxnCtxt*, boost::intrusive_ptrqpid::broker::PersistableMessage 
const, bool) (in /data_xfs/qpid-trunk/cpp/BLD/src/legacystore.so)
==632==by 0x60D7165: 
mrg::msgstore::MessageStoreImpl::enqueue(qpid::broker::TransactionContext*, 
boost::intrusive_ptrqpid::broker::PersistableMessage const, 
qpid::broker::PersistableQueue const) (in 
/data_xfs/qpid-trunk/cpp/BLD/src/legacystore.so)
==632==by 0x5023568: 
qpid::broker::MessageStoreModule::enqueue(qpid::broker::TransactionContext*, 
boost::intrusive_ptrqpid::broker::PersistableMessage const, 
qpid::broker::PersistableQueue const) (in 
/data_xfs/qpid-trunk/cpp/BLD/src/libqpidbroker.so.2.0.0)
==632==by 0x4F9BAC8: 
qpid::broker::Queue::enqueue(qpid::broker::TransactionContext*, 
qpid::broker::Message) (in 
/data_xfs/qpid-trunk/cpp/BLD/src/libqpidbroker.so.2.0.0)

Some further debugging showed the line with new call is:

void MessageStoreImpl::store(..
..
if (queue) {
boost::intrusive_ptrDataTokenImpl dtokp(new DataTokenImpl);
dtokp-addRef();
..


I tried to fix the leak, but I see nothing wrong in code that could trigger it. 
As:
1) dtokp is a local variable declared there, while its content is not copied or 
referenced anywhere later on
2) even catching StoreException and explicitly calling dtokp-reset(); dtokp = 
boost::intrusive_ptrDataTokenImpl(); does not prevent the mem.leak

What exactly is executed at the time RHM_IORES_ENQCAPTHRESH to be raised within 
MessageStoreImpl::store call:

1) ./lib/MessageStoreImpl.cpp:
MessageStoreImpl::store

boost::intrusive_ptrDataTokenImpl dtokp(new DataTokenImpl);
dtokp-addRef();
dtokp-setSourceMessage(message);
dtokp-set_external_rid(true);
dtokp-set_rid(message-getPersistenceId()); // set the messageID 
into the Journal header (record-id)

JournalImpl* jc = 
static_castJournalImpl*(queue-getExternalQueueStore());
if (txn-getXid().empty()) {
if (message-isContentReleased()) {
jc-enqueue_extern_data_record(size, dtokp.get(), 
!message-isPersistent());
} else {
jc-enqueue_data_record(buff[0], size, size, dtokp.get(), 
!message-isPersistent());
}


2) enqueue_data_record called from:
./lib/JournalImpl.cpp
JournalImpl::enqueue_data_record

JournalImpl::enqueue_data_record(const void* const data_buff, const size_t 
tot_data_len,
const size_t this_data_len, data_tok* dtokp, const bool transient)
{
handleIoResult(jcntl::enqueue_data_record(data_buff, tot_data_len, 
this_data_len, dtokp, transient));


3) nested enqueue_data_record called from:
./lib/jrnl/jcntl.cpp:
jcntl::enqueue_data_record(const void* const data_buff, const std::size_t 
tot_data_len,
const std::size_t this_data_len, data_tok* dtokp, const bool transient)

while (handle_aio_wait(_wmgr.enqueue(data_buff, tot_data_len, 
this_data_len, dtokp, 0, 0, transient, false), r,
dtokp)) ;


4) _wmgr.enqueue called from:
./lib/jrnl/wmgr.cpp:
wmgr::enqueue(const void* const data_buff, const std::size_t tot_data_len,
const std::size_t this_data_len, data_tok* dtokp, const void* const 
xid_ptr,
const std::size_t xid_len, const bool transient, const bool external)

iores res = pre_write_check(WMGR_ENQUEUE, dtokp, xid_len, tot_data_len, 
external);
if (res != RHM_IORES_SUCCESS)
return res;


5) pre_write_check called from ./lib/jrnl/wmgr.cpp as well:

wmgr::pre_write_check(const _op_type op, const data_tok* const dtokp,
const std::size_t xidsize, const std::size_t dsize, const bool external
) const

if (!_wrfc.is_wr_reset())
{
if (!_wrfc.wr_reset())
return RHM_IORES_FULL;
}

// Check status of current page is ok for writing
if (_page_cb_arr[_pg_index]._state != IN_USE)
{
if (_page_cb_arr[_pg_index]._state == UNUSED)

[jira] [Resolved] (QPID-5072) [C++ broker] SessionManager does not forget sessions when broker drops connection after journal error, leading to memory leak

[Pavel Moravec (JIRA)]

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

Pavel Moravec resolved QPID-5072.
-

   Resolution: Fixed
Fix Version/s: 0.25
 Assignee: Pavel Moravec  (was: Kim van der Riet)

This issue does not exhibit in upstream qpid (revision 1528730 checked), where 
the broker allows the new session to be attached (but disconnects the 
connection as attempting to enqueue to full journal). Some independent change 
since 0.22 apparently fixed the issue, in another way than my proposed patch.

There is a false alarm/error observed here, as errors error Channel 
exception: not-attached: Channel 2 is not attached are still raised. But that 
is proper behaviour, as:

1) client sends session.attach
2) immediatelly it sends some messages
3) it sets its command point
4) ..
5) broker gets the frames in one bunch, so it:
  a) attaches the session,
  b) gets some command point update (ok)
  c) gets some message - and drops the connection due to journal full
  d) gets another session-related data but on already detached channel - so now 
the error is raised

The 5d) producing the errors should not be fixed in not raising the errors. 
As the sequence could be also:
1) client sends some message
2) broker drops the connection
3) clients sends something more

The broker can't distinguish between these two scenarios, so it makes sense to 
raise the error log in every such case.

 [C++ broker] SessionManager does not forget sessions when broker drops 
 connection after journal error, leading to memory leak
 -

 Key: QPID-5072
 URL: https://issues.apache.org/jira/browse/QPID-5072
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.22
Reporter: Pavel Moravec
Assignee: Pavel Moravec
 Fix For: 0.25

 Attachments: bz991413.patch, memoryLeak-in-sessionManager.sh, 
 test_00903524_threaded.java


 Description of problem:
 Broker rejects session re-subscription (on a new AMQP+TCP connection) after 
 the previous was dropped due to a journal error. This bug in broker:
 - is in fact a memory leak, as session manager map is not cleared when 
 requested
 - it affects Java client during failover, when original journal problem has 
 been already resolved, but the client can't even attach the same session.
 Version-Release number of selected component (if applicable):
 any (teste 0.18 and also 0.22 broker)
 How reproducible:
 100%
 Steps to Reproduce:
 1) run attached Java reproducer on a fresh broker:
 java test_00903524_threaded 1
 2) check qpidd logs for errors
 Actual results:
 2013-08-02 11:39:04 [Protocol] error Unexpected exception: Enqueue capacity 
 threshold exceeded on queue testQueue. 
 (/builddir/build/BUILD/qpid-0.22/cpp/src/qpid/legacystore/JournalImpl.cpp:594)
 2013-08-02 11:39:04 [Protocol] error Connection 
 qpid.10.34.1.141:5672-10.34.1.141:42635 closed by error: Enqueue capacity 
 threshold exceeded on queue testQueue. 
 (/builddir/build/BUILD/qpid-0.22/cpp/src/qpid/legacystore/JournalImpl.cpp:594)(501)
 2013-08-02 11:39:14 [Protocol] error Channel exception: session-busy: Session 
 already attached: guest@QPID.36332225-5c5b-4077-b8ec-820555253a89 
 (/builddir/build/BUILD/qpid-0.22/cpp/src/qpid/broker/SessionManager.cpp:55)
 2013-08-02 11:39:14 [Protocol] error Channel exception: not-attached: Channel 
 1 is not attached 
 (/builddir/build/BUILD/qpid-0.22/cpp/src/qpid/amqp_0_10/SessionHandler.cpp:39)
 ..
 (few thousands of the latest error)
 Expected results:
 just the journal error be seen (and multiple times), not the Session already 
 attached one or Channel 1 is not attached one.
 Additional info:
 The broker management _deletes_ the session, as the broker logs:
 2013-08-02 11:39:04 [Management] trace Management object marked deleted: 
 org.apache.qpid.broker:session:36332225-5c5b-4077-b8ec-820555253a89
org.apache.qpid.broker:session:36332225-5c5b-4077-b8ec-820555253a89 
 (deleted)
 2013-08-02 11:39:10 [Management] trace Deleting V1 properties 
 0-68-1--14(org.apache.qpid.broker:session:36332225-5c5b-4077-b8ec-820555253a89)
  len=164
 2013-08-02 11:39:10 [Management] trace Deleting V1 statistics 
 0-68-1--14(org.apache.qpid.broker:session:36332225-5c5b-4077-b8ec-820555253a89)
  len=127
 2013-08-02 11:39:10 [Management] trace Deleting V2 
 map={_create_ts:1375436343054221056, _delete_ts:1375436344249095890, 
 _object_id:{_agent_epoch:68, 
 _object_name:org.apache.qpid.broker:session:36332225-5c5b-4077-b8ec-820555253a89},
  _schema_id:{_class_name:session, _hash:1aaa08d0-c118-ff78-0956-47b9ac9c6849, 
 _package_name:org.apache.qpid.broker, _type:_data}, 
 _update_ts:1375436343054221056, _values:{TxnCommits:0, TxnCount:0, 
 TxnRejects:0, 

[jira] [Closed] (QPID-5072) [C++ broker] SessionManager does not forget sessions when broker drops connection after journal error, leading to memory leak

[Pavel Moravec (JIRA)]

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

Pavel Moravec closed QPID-5072.
---


Closing it. I found a memory leak in store plugin during verification, that I 
will log as independent JIRA.

 [C++ broker] SessionManager does not forget sessions when broker drops 
 connection after journal error, leading to memory leak
 -

 Key: QPID-5072
 URL: https://issues.apache.org/jira/browse/QPID-5072
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.22
Reporter: Pavel Moravec
Assignee: Pavel Moravec
 Fix For: 0.25

 Attachments: bz991413.patch, memoryLeak-in-sessionManager.sh, 
 test_00903524_threaded.java


 Description of problem:
 Broker rejects session re-subscription (on a new AMQP+TCP connection) after 
 the previous was dropped due to a journal error. This bug in broker:
 - is in fact a memory leak, as session manager map is not cleared when 
 requested
 - it affects Java client during failover, when original journal problem has 
 been already resolved, but the client can't even attach the same session.
 Version-Release number of selected component (if applicable):
 any (teste 0.18 and also 0.22 broker)
 How reproducible:
 100%
 Steps to Reproduce:
 1) run attached Java reproducer on a fresh broker:
 java test_00903524_threaded 1
 2) check qpidd logs for errors
 Actual results:
 2013-08-02 11:39:04 [Protocol] error Unexpected exception: Enqueue capacity 
 threshold exceeded on queue testQueue. 
 (/builddir/build/BUILD/qpid-0.22/cpp/src/qpid/legacystore/JournalImpl.cpp:594)
 2013-08-02 11:39:04 [Protocol] error Connection 
 qpid.10.34.1.141:5672-10.34.1.141:42635 closed by error: Enqueue capacity 
 threshold exceeded on queue testQueue. 
 (/builddir/build/BUILD/qpid-0.22/cpp/src/qpid/legacystore/JournalImpl.cpp:594)(501)
 2013-08-02 11:39:14 [Protocol] error Channel exception: session-busy: Session 
 already attached: guest@QPID.36332225-5c5b-4077-b8ec-820555253a89 
 (/builddir/build/BUILD/qpid-0.22/cpp/src/qpid/broker/SessionManager.cpp:55)
 2013-08-02 11:39:14 [Protocol] error Channel exception: not-attached: Channel 
 1 is not attached 
 (/builddir/build/BUILD/qpid-0.22/cpp/src/qpid/amqp_0_10/SessionHandler.cpp:39)
 ..
 (few thousands of the latest error)
 Expected results:
 just the journal error be seen (and multiple times), not the Session already 
 attached one or Channel 1 is not attached one.
 Additional info:
 The broker management _deletes_ the session, as the broker logs:
 2013-08-02 11:39:04 [Management] trace Management object marked deleted: 
 org.apache.qpid.broker:session:36332225-5c5b-4077-b8ec-820555253a89
org.apache.qpid.broker:session:36332225-5c5b-4077-b8ec-820555253a89 
 (deleted)
 2013-08-02 11:39:10 [Management] trace Deleting V1 properties 
 0-68-1--14(org.apache.qpid.broker:session:36332225-5c5b-4077-b8ec-820555253a89)
  len=164
 2013-08-02 11:39:10 [Management] trace Deleting V1 statistics 
 0-68-1--14(org.apache.qpid.broker:session:36332225-5c5b-4077-b8ec-820555253a89)
  len=127
 2013-08-02 11:39:10 [Management] trace Deleting V2 
 map={_create_ts:1375436343054221056, _delete_ts:1375436344249095890, 
 _object_id:{_agent_epoch:68, 
 _object_name:org.apache.qpid.broker:session:36332225-5c5b-4077-b8ec-820555253a89},
  _schema_id:{_class_name:session, _hash:1aaa08d0-c118-ff78-0956-47b9ac9c6849, 
 _package_name:org.apache.qpid.broker, _type:_data}, 
 _update_ts:1375436343054221056, _values:{TxnCommits:0, TxnCount:0, 
 TxnRejects:0, TxnStarts:0, attached:True, channelId:0, clientCredit:0, 
 connectionRef:{_agent_epoch:68, 
 _object_name:org.apache.qpid.broker:connection:qpid.10.34.1.141:5672-10.34.1.141:42635},
  detachedLifespan:0, name:36332225-5c5b-4077-b8ec-820555253a89, 
 unackedMessages:0, 
 vhostRef:{_object_name:org.apache.qpid.broker:vhost:org.apache.qpid.broker:broker:amqp-broker,/}}}
 But session manager inside does not forget the sessions/channels..
 Reproduction for memory leak:
 run attached script
 Weird is, even fixing the bug for Java client, some steady memory increase is 
 still present..



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Created] (QPID-5203) Python client unexpected exception after ACL denial

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5203:
---

 Summary: Python client unexpected exception after ACL denial
 Key: QPID-5203
 URL: https://issues.apache.org/jira/browse/QPID-5203
 Project: Qpid
  Issue Type: Bug
  Components: Python Client
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor


Description of problem:
After ACL denies a command from qpid Python client, an attempt to close either 
session or connection raises unexpected exception (relevant to ACL, though). 
While at that time, session is properly closed and connection is working fine.


Version-Release number of selected component (if applicable):
every

How reproducible:
100%


Steps to Reproduce:
1. Have ACL file:
acl deny all consume all
acl allow all all

2. Run attached script.


Actual results:

Create receiver failed with exception
Traceback (most recent call last):
  File ACL_denial_session-hang.py, line 13, in module
recv = session.receiver('testQ; {create:always}')
  File string, line 6, in receiver
  File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
616, in receiver
receiver._ewait(lambda: receiver.linked)
  File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
973, in _ewait
result = self.session._ewait(lambda: self.error or predicate(), timeout)
  File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
567, in _ewait
self.check_error()
  File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
556, in check_error
raise self.error
UnauthorizedAccess: unauthorized-access: ACL denied Queue subscribe request 
from guest@QPID (qpid/broker/SessionAdapter.cpp:399)(403)

Session close failed with exception
Traceback (most recent call last):
  File ACL_denial_session-hang.py, line 19, in module
session.close()
  File string, line 6, in close
  File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
739, in close
self.sync(timeout=timeout)
  File string, line 6, in sync
  File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
731, in sync
if not self._ewait(lambda: not self.outgoing and not self.acked, 
timeout=timeout):
  File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
567, in _ewait
self.check_error()
  File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
556, in check_error
raise self.error
UnauthorizedAccess: unauthorized-access: ACL denied Queue subscribe request 
from guest@QPID (qpid/broker/SessionAdapter.cpp:399)(403)

Connection close failed with exception
Traceback (most recent call last):
  File ACL_denial_session-hang.py, line 25, in module
connection.close()
  File string, line 6, in close
  File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
316, in close
ssn.close(timeout=timeout)
  File string, line 6, in close
  File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
739, in close
self.sync(timeout=timeout)
  File string, line 6, in sync
  File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
731, in sync
if not self._ewait(lambda: not self.outgoing and not self.acked, 
timeout=timeout):
  File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
567, in _ewait
self.check_error()
  File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
556, in check_error
raise self.error
UnauthorizedAccess: unauthorized-access: ACL denied Queue subscribe request 
from guest@QPID (qpid/broker/SessionAdapter.cpp:399)(403)


Expected results:
Just the first exception is printed - when the session.receiver fails due to 
ACL.


Additional info:
Some hints for fixing it:
- session object is properly closed. Just an attempt to close it again raises 
that exception. When trying to close a closed session without an ACL deny, no 
exception is raised
- connection object is properly working and closing it really closes the AMQP 
connection. And the connection object can be normally used later on.
- it seems to me like:
a) exception raised and stored somewhere
b) program catches it
c) Python library should delete it from the stored place / variable but it does 
not do so
d) any action on affected session/connection first checks for the stored 
exception, finds it so re-raises it

Workaround:
try:
# this should fail - ACL does not allow this
recv = session.receiver('testQ; {create:always}')
except Exception as e1:
try:
session.close()

[jira] [Updated] (QPID-5203) Python client unexpected exception after ACL denial

[Pavel Moravec (JIRA)]

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

Pavel Moravec updated QPID-5203:


Attachment: bz974940.py

reproducer

 Python client unexpected exception after ACL denial
 ---

 Key: QPID-5203
 URL: https://issues.apache.org/jira/browse/QPID-5203
 Project: Qpid
  Issue Type: Bug
  Components: Python Client
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
 Attachments: bz974940.py


 Description of problem:
 After ACL denies a command from qpid Python client, an attempt to close 
 either session or connection raises unexpected exception (relevant to ACL, 
 though). While at that time, session is properly closed and connection is 
 working fine.
 Version-Release number of selected component (if applicable):
 every
 How reproducible:
 100%
 Steps to Reproduce:
 1. Have ACL file:
 acl deny all consume all
 acl allow all all
 2. Run attached script.
 Actual results:
 
 Create receiver failed with exception
 Traceback (most recent call last):
   File ACL_denial_session-hang.py, line 13, in module
 recv = session.receiver('testQ; {create:always}')
   File string, line 6, in receiver
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 616, in receiver
 receiver._ewait(lambda: receiver.linked)
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 973, in _ewait
 result = self.session._ewait(lambda: self.error or predicate(), timeout)
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 567, in _ewait
 self.check_error()
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 556, in check_error
 raise self.error
 UnauthorizedAccess: unauthorized-access: ACL denied Queue subscribe request 
 from guest@QPID (qpid/broker/SessionAdapter.cpp:399)(403)
 
 Session close failed with exception
 Traceback (most recent call last):
   File ACL_denial_session-hang.py, line 19, in module
 session.close()
   File string, line 6, in close
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 739, in close
 self.sync(timeout=timeout)
   File string, line 6, in sync
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 731, in sync
 if not self._ewait(lambda: not self.outgoing and not self.acked, 
 timeout=timeout):
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 567, in _ewait
 self.check_error()
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 556, in check_error
 raise self.error
 UnauthorizedAccess: unauthorized-access: ACL denied Queue subscribe request 
 from guest@QPID (qpid/broker/SessionAdapter.cpp:399)(403)
 
 Connection close failed with exception
 Traceback (most recent call last):
   File ACL_denial_session-hang.py, line 25, in module
 connection.close()
   File string, line 6, in close
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 316, in close
 ssn.close(timeout=timeout)
   File string, line 6, in close
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 739, in close
 self.sync(timeout=timeout)
   File string, line 6, in sync
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 731, in sync
 if not self._ewait(lambda: not self.outgoing and not self.acked, 
 timeout=timeout):
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 567, in _ewait
 self.check_error()
   File /usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py, line 
 556, in check_error
 raise self.error
 UnauthorizedAccess: unauthorized-access: ACL denied Queue subscribe request 
 from guest@QPID (qpid/broker/SessionAdapter.cpp:399)(403)
 Expected results:
 Just the first exception is printed - when the session.receiver fails due 
 to ACL.
 Additional info:
 Some hints for fixing it:
 - session object is properly closed. Just an attempt to close it again raises 
 that exception. When trying to close a closed session without an ACL deny, no 
 exception is raised
 - connection object is properly working and closing it really closes the AMQP 
 connection. And the connection object can be normally used later on.
 - it seems to me like:
 a) exception raised and stored somewhere
 b) program catches it
 c) Python library should delete it from the stored place / variable but it 
 does not do so
 

[jira] [Created] (QPID-5183) Python client does not release acquired messages on consumer close when session persists

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5183:
---

 Summary: Python client does not release acquired messages on 
consumer close when session persists
 Key: QPID-5183
 URL: https://issues.apache.org/jira/browse/QPID-5183
 Project: Qpid
  Issue Type: Bug
  Components: Python Client
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor


When closing a receiver on a session with multiple receivers open to the same 
destination, the receiver/session does not release acquired messages. Other 
consumers on the session then can't access the messages then.

See https://bugzilla.redhat.com/show_bug.cgi?id=852067 for more details.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (QPID-5183) Python client does not release acquired messages on consumer close when session persists

[Pavel Moravec (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-5183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13779895#comment-13779895
 ] 

Pavel Moravec commented on QPID-5183:
-

Comment to the patch to be committed:

Two code changes were required:

1) When receiving a message for a receiver that is closing or closed, release 
them back. That is the change in do_message_transfer method.

2) The key one: when closing receiver (and sending message.cancel), check for 
received messages for this receiver not fetched by the application yet - and 
release them back as well. That is the change in do_unlink.

There are two gotchas, however:
a) code in do_unlink is quite inefficient (esp. repetitive calling 
rcv.session._pop(rcv) that is inefficient for bigger session.incoming list 
where first items of the list are checked every time; there should be a method 
pop_messages_for_receiver in Session class that traverses incoming list just 
once. Anyway there are usually just very few messages in the list at that time, 
hence no need to improve the code
b) I still *think* the below interleaving of code execution could lead to the 
same issue:
  - thread1 starts do_message_transfer and passes if rcv.closing or 
rcv.closed: test
  - thread2 executes whole receiver closing, for that there is still no message 
in session.incoming list
  - thread1 continues in its method do_message_transfer and adds the message to 
session.incoming

Now, the message sits in session.incoming forever and again is never released.

 Python client does not release acquired messages on consumer close when 
 session persists
 

 Key: QPID-5183
 URL: https://issues.apache.org/jira/browse/QPID-5183
 Project: Qpid
  Issue Type: Bug
  Components: Python Client
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor

 When closing a receiver on a session with multiple receivers open to the same 
 destination, the receiver/session does not release acquired messages. Other 
 consumers on the session then can't access the messages then.
 See https://bugzilla.redhat.com/show_bug.cgi?id=852067 for more details.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (QPID-5183) Python client does not release acquired messages on consumer close when session persists

[Pavel Moravec (JIRA)]

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

Pavel Moravec resolved QPID-5183.
-

   Resolution: Fixed
Fix Version/s: 0.25

 Python client does not release acquired messages on consumer close when 
 session persists
 

 Key: QPID-5183
 URL: https://issues.apache.org/jira/browse/QPID-5183
 Project: Qpid
  Issue Type: Bug
  Components: Python Client
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
Priority: Minor
 Fix For: 0.25


 When closing a receiver on a session with multiple receivers open to the same 
 destination, the receiver/session does not release acquired messages. Other 
 consumers on the session then can't access the messages then.
 See https://bugzilla.redhat.com/show_bug.cgi?id=852067 for more details.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (QPID-5124) durable LVQ raises journal error when only transient messages are sent

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5124:
---

 Summary: durable LVQ raises journal error when only transient 
messages are sent
 Key: QPID-5124
 URL: https://issues.apache.org/jira/browse/QPID-5124
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec


Description of problem:
Sending+consuming transient messages to/from a durable LVQ queue raises 
Dequeuing message with null persistence Id journal error on producer.


Version-Release number of selected component (if applicable):
0.24


How reproducible:
100%


Steps to Reproduce:
1. In the first terminal:
qpid-receive -a myLVQ; {create:always, node:{ durable:true, x-declare: { 
arguments:{'qpid.flow_stop_count':0, 'qpid.max_count':0, 
'qpid.last_value_queue':True, 'qpid.last_value_queue_key':'qpid.LVQ_key', 
'qpid.file_count':64, 'qpid.policy_type':'reject', 'qpid.file_size':16, 
'qpid.flow_resume_count':0, 'qpid.flow_stop_size':0, 'qpid.max_size':104857600, 
'qpid.flow_resume_size':0 -f -m 10 --print-content=no

2. In the second terminal:
qpid-send -a myLVQ -m 100 --group-key=qpid.LVQ_key --group-size=10 
--content-size=100


Actual results:
qpid-send is disconnected by the broker with error:
2013-09-09 21:24:59 [Client] warning Broker closed connection: 501, Queue 
myLVQ: Dequeuing message with null persistence Id. 
(/root/rpmbuild/BUILD/qpid-0.22/cpp/src/qpid/legacystore/MessageStoreImpl.cpp:1370)


Expected results:
No such error.


Additional info:
- everytime, the queue has these stats after the error:
acquires:3, bindingCount:1, bindingCountHigh:1, bindingCountLow:1, 
byteDepth:100, byteFtdDepth:0, byteFtdDequeues:0, byteFtdEnqueues:0, 
bytePersistDequeues:0, bytePersistEnqueues:0, byteTotalDequeues:100, 
byteTotalEnqueues:200, byteTxnDequeues:0, byteTxnEnqueues:0, consumerCount:0, 
consumerCountHigh:0, consumerCountLow:0, discardsLvq:1, discardsOverflow:0, 
discardsPurge:0, discardsRing:0, discardsSubscriber:0, discardsTtl:0, 
flowStopped:False, flowStoppedCount:0, messageLatencyAvg:0, 
messageLatencyCount:0, messageLatencyMax:0, messageLatencyMin:0, msgDepth:1, 
msgFtdDepth:0, msgFtdDequeues:0, msgFtdEnqueues:0, msgPersistDequeues:0, 
msgPersistEnqueues:0, msgTotalDequeues:1, msgTotalEnqueues:2, msgTxnDequeues:0, 
msgTxnEnqueues:0, redirectPeer:, redirectSource:False, releases:1, reroutes:0, 
unackedMessages:0, unackedMessagesHigh:0, unackedMessagesLow:0

I.e. one msg discarded due to LVQ, 2 enqueues, 1 dequeue (the discard), BUT 3 
acquires???


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (QPID-5124) durable LVQ raises journal error when only transient messages are sent

[Pavel Moravec (JIRA)]

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

Pavel Moravec updated QPID-5124:


Attachment: QPID-5124.patch

Trivial patch

When removing old message from LVQ due to push of a new one with same LVQ key 
value, call dequeueFromStore for the old message _only_ if the old message is 
durable ;-)

 durable LVQ raises journal error when only transient messages are sent
 --

 Key: QPID-5124
 URL: https://issues.apache.org/jira/browse/QPID-5124
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
  Labels: easyfix, patch
 Attachments: QPID-5124.patch


 Description of problem:
 Sending+consuming transient messages to/from a durable LVQ queue raises 
 Dequeuing message with null persistence Id journal error on producer.
 Version-Release number of selected component (if applicable):
 0.24
 How reproducible:
 100%
 Steps to Reproduce:
 1. In the first terminal:
 qpid-receive -a myLVQ; {create:always, node:{ durable:true, x-declare: { 
 arguments:{'qpid.flow_stop_count':0, 'qpid.max_count':0, 
 'qpid.last_value_queue':True, 'qpid.last_value_queue_key':'qpid.LVQ_key', 
 'qpid.file_count':64, 'qpid.policy_type':'reject', 'qpid.file_size':16, 
 'qpid.flow_resume_count':0, 'qpid.flow_stop_size':0, 
 'qpid.max_size':104857600, 'qpid.flow_resume_size':0 -f -m 10 
 --print-content=no
 2. In the second terminal:
 qpid-send -a myLVQ -m 100 --group-key=qpid.LVQ_key --group-size=10 
 --content-size=100
 Actual results:
 qpid-send is disconnected by the broker with error:
 2013-09-09 21:24:59 [Client] warning Broker closed connection: 501, Queue 
 myLVQ: Dequeuing message with null persistence Id. 
 (/root/rpmbuild/BUILD/qpid-0.22/cpp/src/qpid/legacystore/MessageStoreImpl.cpp:1370)
 Expected results:
 No such error.
 Additional info:
 - everytime, the queue has these stats after the error:
 acquires:3, bindingCount:1, bindingCountHigh:1, bindingCountLow:1, 
 byteDepth:100, byteFtdDepth:0, byteFtdDequeues:0, byteFtdEnqueues:0, 
 bytePersistDequeues:0, bytePersistEnqueues:0, byteTotalDequeues:100, 
 byteTotalEnqueues:200, byteTxnDequeues:0, byteTxnEnqueues:0, consumerCount:0, 
 consumerCountHigh:0, consumerCountLow:0, discardsLvq:1, discardsOverflow:0, 
 discardsPurge:0, discardsRing:0, discardsSubscriber:0, discardsTtl:0, 
 flowStopped:False, flowStoppedCount:0, messageLatencyAvg:0, 
 messageLatencyCount:0, messageLatencyMax:0, messageLatencyMin:0, msgDepth:1, 
 msgFtdDepth:0, msgFtdDequeues:0, msgFtdEnqueues:0, msgPersistDequeues:0, 
 msgPersistEnqueues:0, msgTotalDequeues:1, msgTotalEnqueues:2, 
 msgTxnDequeues:0, msgTxnEnqueues:0, redirectPeer:, redirectSource:False, 
 releases:1, reroutes:0, unackedMessages:0, unackedMessagesHigh:0, 
 unackedMessagesLow:0
 I.e. one msg discarded due to LVQ, 2 enqueues, 1 dequeue (the discard), BUT 3 
 acquires???

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Assigned] (QPID-5124) durable LVQ raises journal error when only transient messages are sent

[Pavel Moravec (JIRA)]

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

Pavel Moravec reassigned QPID-5124:
---

Assignee: Pavel Moravec

 durable LVQ raises journal error when only transient messages are sent
 --

 Key: QPID-5124
 URL: https://issues.apache.org/jira/browse/QPID-5124
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
  Labels: easyfix, patch
 Attachments: QPID-5124.patch


 Description of problem:
 Sending+consuming transient messages to/from a durable LVQ queue raises 
 Dequeuing message with null persistence Id journal error on producer.
 Version-Release number of selected component (if applicable):
 0.24
 How reproducible:
 100%
 Steps to Reproduce:
 1. In the first terminal:
 qpid-receive -a myLVQ; {create:always, node:{ durable:true, x-declare: { 
 arguments:{'qpid.flow_stop_count':0, 'qpid.max_count':0, 
 'qpid.last_value_queue':True, 'qpid.last_value_queue_key':'qpid.LVQ_key', 
 'qpid.file_count':64, 'qpid.policy_type':'reject', 'qpid.file_size':16, 
 'qpid.flow_resume_count':0, 'qpid.flow_stop_size':0, 
 'qpid.max_size':104857600, 'qpid.flow_resume_size':0 -f -m 10 
 --print-content=no
 2. In the second terminal:
 qpid-send -a myLVQ -m 100 --group-key=qpid.LVQ_key --group-size=10 
 --content-size=100
 Actual results:
 qpid-send is disconnected by the broker with error:
 2013-09-09 21:24:59 [Client] warning Broker closed connection: 501, Queue 
 myLVQ: Dequeuing message with null persistence Id. 
 (/root/rpmbuild/BUILD/qpid-0.22/cpp/src/qpid/legacystore/MessageStoreImpl.cpp:1370)
 Expected results:
 No such error.
 Additional info:
 - everytime, the queue has these stats after the error:
 acquires:3, bindingCount:1, bindingCountHigh:1, bindingCountLow:1, 
 byteDepth:100, byteFtdDepth:0, byteFtdDequeues:0, byteFtdEnqueues:0, 
 bytePersistDequeues:0, bytePersistEnqueues:0, byteTotalDequeues:100, 
 byteTotalEnqueues:200, byteTxnDequeues:0, byteTxnEnqueues:0, consumerCount:0, 
 consumerCountHigh:0, consumerCountLow:0, discardsLvq:1, discardsOverflow:0, 
 discardsPurge:0, discardsRing:0, discardsSubscriber:0, discardsTtl:0, 
 flowStopped:False, flowStoppedCount:0, messageLatencyAvg:0, 
 messageLatencyCount:0, messageLatencyMax:0, messageLatencyMin:0, msgDepth:1, 
 msgFtdDepth:0, msgFtdDequeues:0, msgFtdEnqueues:0, msgPersistDequeues:0, 
 msgPersistEnqueues:0, msgTotalDequeues:1, msgTotalEnqueues:2, 
 msgTxnDequeues:0, msgTxnEnqueues:0, redirectPeer:, redirectSource:False, 
 releases:1, reroutes:0, unackedMessages:0, unackedMessagesHigh:0, 
 unackedMessagesLow:0
 I.e. one msg discarded due to LVQ, 2 enqueues, 1 dequeue (the discard), BUT 3 
 acquires???

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (QPID-5124) durable LVQ raises journal error when only transient messages are sent

[Pavel Moravec (JIRA)]

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

Pavel Moravec resolved QPID-5124.
-

   Resolution: Fixed
Fix Version/s: 0.25

Resolved by commit r1521391. Both me and Gordon checked that all other calls of 
dequeueFromStore method have either direct or indirect test of message 
persistency, hence no need to further fix.

 durable LVQ raises journal error when only transient messages are sent
 --

 Key: QPID-5124
 URL: https://issues.apache.org/jira/browse/QPID-5124
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.24
Reporter: Pavel Moravec
Assignee: Pavel Moravec
  Labels: easyfix, patch
 Fix For: 0.25

 Attachments: QPID-5124.patch


 Description of problem:
 Sending+consuming transient messages to/from a durable LVQ queue raises 
 Dequeuing message with null persistence Id journal error on producer.
 Version-Release number of selected component (if applicable):
 0.24
 How reproducible:
 100%
 Steps to Reproduce:
 1. In the first terminal:
 qpid-receive -a myLVQ; {create:always, node:{ durable:true, x-declare: { 
 arguments:{'qpid.flow_stop_count':0, 'qpid.max_count':0, 
 'qpid.last_value_queue':True, 'qpid.last_value_queue_key':'qpid.LVQ_key', 
 'qpid.file_count':64, 'qpid.policy_type':'reject', 'qpid.file_size':16, 
 'qpid.flow_resume_count':0, 'qpid.flow_stop_size':0, 
 'qpid.max_size':104857600, 'qpid.flow_resume_size':0 -f -m 10 
 --print-content=no
 2. In the second terminal:
 qpid-send -a myLVQ -m 100 --group-key=qpid.LVQ_key --group-size=10 
 --content-size=100
 Actual results:
 qpid-send is disconnected by the broker with error:
 2013-09-09 21:24:59 [Client] warning Broker closed connection: 501, Queue 
 myLVQ: Dequeuing message with null persistence Id. 
 (/root/rpmbuild/BUILD/qpid-0.22/cpp/src/qpid/legacystore/MessageStoreImpl.cpp:1370)
 Expected results:
 No such error.
 Additional info:
 - everytime, the queue has these stats after the error:
 acquires:3, bindingCount:1, bindingCountHigh:1, bindingCountLow:1, 
 byteDepth:100, byteFtdDepth:0, byteFtdDequeues:0, byteFtdEnqueues:0, 
 bytePersistDequeues:0, bytePersistEnqueues:0, byteTotalDequeues:100, 
 byteTotalEnqueues:200, byteTxnDequeues:0, byteTxnEnqueues:0, consumerCount:0, 
 consumerCountHigh:0, consumerCountLow:0, discardsLvq:1, discardsOverflow:0, 
 discardsPurge:0, discardsRing:0, discardsSubscriber:0, discardsTtl:0, 
 flowStopped:False, flowStoppedCount:0, messageLatencyAvg:0, 
 messageLatencyCount:0, messageLatencyMax:0, messageLatencyMin:0, msgDepth:1, 
 msgFtdDepth:0, msgFtdDequeues:0, msgFtdEnqueues:0, msgPersistDequeues:0, 
 msgPersistEnqueues:0, msgTotalDequeues:1, msgTotalEnqueues:2, 
 msgTxnDequeues:0, msgTxnEnqueues:0, redirectPeer:, redirectSource:False, 
 releases:1, reroutes:0, unackedMessages:0, unackedMessagesHigh:0, 
 unackedMessagesLow:0
 I.e. one msg discarded due to LVQ, 2 enqueues, 1 dequeue (the discard), BUT 3 
 acquires???

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (QPID-5121) Store module does not raise exception when attempting to enqueue a message bigger than the journal size

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5121:
---

 Summary: Store module does not raise exception when attempting to 
enqueue a message bigger than the journal size
 Key: QPID-5121
 URL: https://issues.apache.org/jira/browse/QPID-5121
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.22
Reporter: Pavel Moravec
 Attachments: QPID-5121.patch

Description of problem:
Whenever store module tries to write to a journal a message bigger than the 
journal capacity is, it a) does not store the message (so far so good), but b) 
it does _not_ raise an error (!!!). So the broker thinks the message was 
enqueued.

That is a big gotcha, as the durable message is kept in memory only.


Version-Release number of selected component (if applicable):
0.22


How reproducible:
100%


Steps to Reproduce:
rm -rf /var/lib/qpidd/* /var/lib/qpidd/.* 2 /dev/null
service qpidd restart

# create a durable queue with tiny journal and send there one huge message
qpid-send -a DurableQueue4; {create:always, node:{durable:true, x-declare:{ 
arguments:{'qpid.flow_stop_count':0, 'qpid.max_count':0, 'qpid.file_count':4, 
'qpid.file_size':8, 'qpid.flow_resume_count':0, 'qpid.flow_stop_size':0, 
'qpid.flow_resume_size':0, 'qpid.max_size':0  -m 1 
--content-size=1 --durable=yes

# check in stats the queue has the message enqueued
qpid-stat -q 
Queues
  queue dur  autoDel  excl  msg   msgIn  
msgOut  bytes  bytesIn  bytesOut  cons  bind
  
=
  7e553cc6-89d4-46b2-93fd-5ad7cf1f72a9:0.0   YY0 0  
0   0  00 1 2
  DurableQueue4 Y  1 1  
0 100m   100m   0 0 1

# restart the broker and check queue stats
service qpidd restart
qpid-stat -q 
Queues
  queue dur  autoDel  excl  msg   msgIn  
msgOut  bytes  bytesIn  bytesOut  cons  bind
  
=
  DurableQueue4 Y  0 0  
0   0  00 0 1
  cd53-5b98-4101-ad35-de71e038cd61:0.0   YY0 0  
0   0  00 1 2

# ouch, where the _durable_ message went to???


Actual results:
1) generic reproducer for regular durable queue:
- qpid-send/broker/store has not returned an error (THIS is the wrong)
- after the broker restart, the queue has no message (this should be ok but not 
after no error raised)


Expected results:
qpid-send should fail due to Enqueue capacity threshold error (and no message 
should be kept in the broker later on).


Additional info:
- Optional/variant scenarios: send first some tiny message to the journal and 
then the huge one.
- Trivial patch to be added



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (QPID-5108) session statistics Tx* not updated any time

[Pavel Moravec (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-5108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758859#comment-13758859
 ] 

Pavel Moravec commented on QPID-5108:
-

Commited in r1520245.

 session statistics Tx* not updated any time
 ---

 Key: QPID-5108
 URL: https://issues.apache.org/jira/browse/QPID-5108
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.22
Reporter: Pavel Moravec
Priority: Minor
  Labels: patch
 Attachments: QPID-5108-improved.patch, QPID-5108.patch

   Original Estimate: 3h
  Remaining Estimate: 3h

 Description of problem:
 Tx* counters of Session QMF object are everytime zero, regardless if 
 transactions are/have been used or not.
 Version-Release number of selected component (if applicable):
 0.22
 How reproducible:
 100%
 Steps to Reproduce:
 echo log-to-file=/tmp/qpidd.log  /etc/qpid/qpidd.conf
 echo auth=no  /etc/qpid/qpidd.conf
 echo trace=yes  /etc/qpid/qpidd.conf
 rm -rf /tmp/qpidd.log 
 service qpidd restart
 qpid-send -m 20 -a myQueue; {create:always} --tx 2 --rollback-frequency 2
 sleep 10
 grep Tx /tmp/qpidd.log | grep session
 (optionally, check the the session statistics in qpid-tool)
 Actual results:
 2013-08-30 10:22:38 [Model] trace Mgmt delete session. 
 id:18f9a28a-f5b0-4e9d-9fe7-dc49a1463e6a Statistics: {TxnCommits:0, 
 TxnCount:0, TxnRejects:0, TxnStarts:0, clientCredit:0, unackedMessages:0}
 2013-08-30 10:22:38 [Management] trace Deleting V2 
 map={_create_ts:1377850955102035092, _delete_ts:1377850955109735713, 
 _object_id:{_agent_epoch:1, 
 _object_name:org.apache.qpid.broker:session:18f9a28a-f5b0-4e9d-9fe7-dc49a1463e6a},
  _schema_id:{_class_name:session, _hash:1aaa08d0-c118-ff78-0956-47b9ac9c6849, 
 _package_name:org.apache.qpid.broker, _type:_data}, 
 _update_ts:1377850955102035092, _values:{TxnCommits:0, TxnCount:0, 
 TxnRejects:0, TxnStarts:0, attached:False, channelId:1, clientCredit:0, 
 connectionRef:{_agent_epoch:1, 
 _object_name:org.apache.qpid.broker:connection:127.0.0.1:5672-127.0.0.1:52255},
  detachedLifespan:0, name:18f9a28a-f5b0-4e9d-9fe7-dc49a1463e6a, 
 unackedMessages:0, 
 vhostRef:{_object_name:org.apache.qpid.broker:vhost:org.apache.qpid.broker:broker:amqp-broker,/}}}
 See TxnCommits:0, TxnCount:0, TxnRejects:0, TxnStarts:0 in both trace logs 
 / qpid-tool
 Expected results:
 TxnCommits:6, TxnCount:11, TxnRejects:5, TxnStarts:1
 (10 transactions, every 2nd rejected, plus one extra at the end)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (QPID-5108) session statistics Tx* not updated any time

[Pavel Moravec (JIRA)]

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

Pavel Moravec resolved QPID-5108.
-

   Resolution: Fixed
Fix Version/s: 0.25

 session statistics Tx* not updated any time
 ---

 Key: QPID-5108
 URL: https://issues.apache.org/jira/browse/QPID-5108
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.22
Reporter: Pavel Moravec
Priority: Minor
  Labels: patch
 Fix For: 0.25

 Attachments: QPID-5108-improved.patch, QPID-5108.patch

   Original Estimate: 3h
  Remaining Estimate: 3h

 Description of problem:
 Tx* counters of Session QMF object are everytime zero, regardless if 
 transactions are/have been used or not.
 Version-Release number of selected component (if applicable):
 0.22
 How reproducible:
 100%
 Steps to Reproduce:
 echo log-to-file=/tmp/qpidd.log  /etc/qpid/qpidd.conf
 echo auth=no  /etc/qpid/qpidd.conf
 echo trace=yes  /etc/qpid/qpidd.conf
 rm -rf /tmp/qpidd.log 
 service qpidd restart
 qpid-send -m 20 -a myQueue; {create:always} --tx 2 --rollback-frequency 2
 sleep 10
 grep Tx /tmp/qpidd.log | grep session
 (optionally, check the the session statistics in qpid-tool)
 Actual results:
 2013-08-30 10:22:38 [Model] trace Mgmt delete session. 
 id:18f9a28a-f5b0-4e9d-9fe7-dc49a1463e6a Statistics: {TxnCommits:0, 
 TxnCount:0, TxnRejects:0, TxnStarts:0, clientCredit:0, unackedMessages:0}
 2013-08-30 10:22:38 [Management] trace Deleting V2 
 map={_create_ts:1377850955102035092, _delete_ts:1377850955109735713, 
 _object_id:{_agent_epoch:1, 
 _object_name:org.apache.qpid.broker:session:18f9a28a-f5b0-4e9d-9fe7-dc49a1463e6a},
  _schema_id:{_class_name:session, _hash:1aaa08d0-c118-ff78-0956-47b9ac9c6849, 
 _package_name:org.apache.qpid.broker, _type:_data}, 
 _update_ts:1377850955102035092, _values:{TxnCommits:0, TxnCount:0, 
 TxnRejects:0, TxnStarts:0, attached:False, channelId:1, clientCredit:0, 
 connectionRef:{_agent_epoch:1, 
 _object_name:org.apache.qpid.broker:connection:127.0.0.1:5672-127.0.0.1:52255},
  detachedLifespan:0, name:18f9a28a-f5b0-4e9d-9fe7-dc49a1463e6a, 
 unackedMessages:0, 
 vhostRef:{_object_name:org.apache.qpid.broker:vhost:org.apache.qpid.broker:broker:amqp-broker,/}}}
 See TxnCommits:0, TxnCount:0, TxnRejects:0, TxnStarts:0 in both trace logs 
 / qpid-tool
 Expected results:
 TxnCommits:6, TxnCount:11, TxnRejects:5, TxnStarts:1
 (10 transactions, every 2nd rejected, plus one extra at the end)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (QPID-5116) QMF method queueMoveMessages loses one message when moving to full queue

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5116:
---

 Summary: QMF method queueMoveMessages loses one message when 
moving to full queue
 Key: QPID-5116
 URL: https://issues.apache.org/jira/browse/QPID-5116
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.22
Reporter: Pavel Moravec
Priority: Minor


Invoking QMF method queueMoveMessages where destination queue can't handle 
all moved messages due to its capacity, one message is lost.

Reproducer:

$ qpid-receive -a tinyQueue; {create:always, node:{ x-declare:{ 
arguments:{'qpid.max_count':100
$ qpid-send -a fromQueue; {create:always} -m 1000
$ qpid-tool
Management Tool for QPID
qpid: list broker
Object Summary:
ID   Created   Destroyed  Index
===
117  08:11:52  -  amqp-broker
qpid: call 117 queueMoveMessages fromQueue tinyQueue 300 {}
qpid: resource-limit-exceeded: Policy exceeded on tinyQueue, policy: size: 
max=104857600, current=1000; count: max=100, current=100; type=reject 
(qpid/broker/QueuePolicy.cpp:92) (7) - {}
qpid: quit
Exiting...
$ qpid-stat -q
Queues
  queue dur  autoDel  excl  msg   msgIn  
msgOut  bytes  bytesIn  bytesOut  cons  bind
  
=
  3d03d063-4f1e-4cc2-822f-00d95d7e42e9:0.0   YY0 0  
0   0  00 1 2
  fromQueue  899  1.00k   
1018.99k  10.0k1.01k0 1
  tinyQueue  100   100  
01.00k  1.00k   0 0 1
$

See fromQueue has dequeued 101 messages while tinyQueue enqueued just 100.

(relevant discussion: 
http://qpid.2158936.n2.nabble.com/QMF-method-quot-queueMoveMessages-quot-can-loose-one-message-td7597804.html)


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (QPID-5116) QMF method queueMoveMessages loses one message when moving to full queue

[Pavel Moravec (JIRA)]

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

Pavel Moravec updated QPID-5116:


Attachment: QPID-5116.patch

Patch proposal. Though it works for the provided scenario (fromQueue has 900 
messages at the end), I am not sure if it does not break anything else.

I tested it also with durable queues  messages to check if removed dequeue 
has proper messages in, to call dequeueFromStore only to really moved messages. 
This was ok.

 QMF method queueMoveMessages loses one message when moving to full queue
 --

 Key: QPID-5116
 URL: https://issues.apache.org/jira/browse/QPID-5116
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.22
Reporter: Pavel Moravec
Priority: Minor
 Attachments: QPID-5116.patch


 Invoking QMF method queueMoveMessages where destination queue can't handle 
 all moved messages due to its capacity, one message is lost.
 Reproducer:
 $ qpid-receive -a tinyQueue; {create:always, node:{ x-declare:{ 
 arguments:{'qpid.max_count':100
 $ qpid-send -a fromQueue; {create:always} -m 1000
 $ qpid-tool
 Management Tool for QPID
 qpid: list broker
 Object Summary:
 ID   Created   Destroyed  Index
 ===
 117  08:11:52  -  amqp-broker
 qpid: call 117 queueMoveMessages fromQueue tinyQueue 300 {}
 qpid: resource-limit-exceeded: Policy exceeded on tinyQueue, policy: size: 
 max=104857600, current=1000; count: max=100, current=100; type=reject 
 (qpid/broker/QueuePolicy.cpp:92) (7) - {}
 qpid: quit
 Exiting...
 $ qpid-stat -q
 Queues
   queue dur  autoDel  excl  msg   msgIn  
 msgOut  bytes  bytesIn  bytesOut  cons  bind
   
 =
   3d03d063-4f1e-4cc2-822f-00d95d7e42e9:0.0   YY0 0
   0   0  00 1 2
   fromQueue  899  1.00k   
 1018.99k  10.0k1.01k0 1
   tinyQueue  100   100
   01.00k  1.00k   0 0 1
 $
 See fromQueue has dequeued 101 messages while tinyQueue enqueued just 100.
 (relevant discussion: 
 http://qpid.2158936.n2.nabble.com/QMF-method-quot-queueMoveMessages-quot-can-loose-one-message-td7597804.html)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (QPID-5117) Java client deadlocks if connection is closed while onMessage() is creating a session

[Pavel Moravec (JIRA)]

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

Pavel Moravec updated QPID-5117:


Attachment: test_QPID5117.java

.. and I have (nondeterministic) reproducer.

java test_QPID5117 50

sometimes hungs in the deadlock (not printing out Finishing.) with jstack:

2013-09-05 16:33:11
Full thread dump OpenJDK 64-Bit Server VM (20.0-b12 mixed mode):

Attach Listener daemon prio=10 tid=0x7f3ca8001000 nid=0x799f waiting on 
condition [0x]
   java.lang.Thread.State: RUNNABLE

Dispatcher-0-Conn-1 prio=10 tid=0x7f3cd030d000 nid=0x798f waiting for 
monitor entry [0x7f3cca6e4000]
   java.lang.Thread.State: BLOCKED (on object monitor)
at 
org.apache.qpid.client.AMQConnection.createSession(AMQConnection.java:666)
- waiting to lock 0xf2a90d30 (a java.lang.Object)
at 
org.apache.qpid.client.AMQConnection.createSession(AMQConnection.java:658)
at 
org.apache.qpid.client.AMQConnection.createSession(AMQConnection.java:652)
at 
org.apache.qpid.client.AMQConnection.createSession(AMQConnection.java:84)
at test_QPID5117$1.onMessage(test_QPID5117.java:45)
at 
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:744)
at 
org.apache.qpid.client.BasicMessageConsumer_0_10.notifyMessage(BasicMessageConsumer_0_10.java:141)
at 
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:718)
at 
org.apache.qpid.client.BasicMessageConsumer_0_10.notifyMessage(BasicMessageConsumer_0_10.java:187)
at 
org.apache.qpid.client.BasicMessageConsumer_0_10.notifyMessage(BasicMessageConsumer_0_10.java:53)
at 
org.apache.qpid.client.AMQSession$Dispatcher.notifyConsumer(AMQSession.java:3362)
at 
org.apache.qpid.client.AMQSession$Dispatcher.dispatchMessage(AMQSession.java:3301)
- locked 0xf23c0580 (a java.lang.Object)
- locked 0xf25147f8 (a java.lang.Object)
at 
org.apache.qpid.client.AMQSession$Dispatcher.access$900(AMQSession.java:3088)
at org.apache.qpid.client.AMQSession.dispatch(AMQSession.java:3081)
at 
org.apache.qpid.client.message.UnprocessedMessage.dispatch(UnprocessedMessage.java:54)
at 
org.apache.qpid.client.AMQSession$Dispatcher.run(AMQSession.java:3224)
at java.lang.Thread.run(Thread.java:679)

ack-flusher daemon prio=10 tid=0x7f3cd022e000 nid=0x798e in Object.wait() 
[0x7f3cca7e5000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xf23514b0 (a java.util.TaskQueue)
at java.util.TimerThread.mainLoop(Timer.java:531)
- locked 0xf23514b0 (a java.util.TaskQueue)
at java.util.TimerThread.run(Timer.java:484)

IoReceiver - localhost/127.0.0.1:5672 daemon prio=10 tid=0x7f3cd01f9000 
nid=0x798d runnable [0x7f3ccaaed000]
   java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:146)
at 
org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:156)
at java.lang.Thread.run(Thread.java:679)

IoSender - localhost/127.0.0.1:5672 daemon prio=10 tid=0x7f3cd017c800 
nid=0x798c in Object.wait() [0x7f3ccabee000]
   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xf2a90120 (a java.lang.Object)
at java.lang.Object.wait(Object.java:502)
at org.apache.qpid.transport.network.io.IoSender.run(IoSender.java:284)
- locked 0xf2a90120 (a java.lang.Object)
at java.lang.Thread.run(Thread.java:679)

Low Memory Detector daemon prio=10 tid=0x7f3cd00a nid=0x7988 runnable 
[0x]
   java.lang.Thread.State: RUNNABLE

C2 CompilerThread1 daemon prio=10 tid=0x7f3cd009e000 nid=0x7987 waiting 
on condition [0x]
   java.lang.Thread.State: RUNNABLE

C2 CompilerThread0 daemon prio=10 tid=0x7f3cd0098800 nid=0x7986 waiting 
on condition [0x]
   java.lang.Thread.State: RUNNABLE

Signal Dispatcher daemon prio=10 tid=0x7f3cd008a800 nid=0x7985 runnable 
[0x]
   java.lang.Thread.State: RUNNABLE

Finalizer daemon prio=10 tid=0x7f3cd0078000 nid=0x7984 in Object.wait() 
[0x7f3ccb5d7000]
   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xf2a903b0 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:133)
- locked 0xf2a903b0 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:149)
at 

[jira] [Updated] (QPID-5108) session statistics Tx* not updated any time

[Pavel Moravec (JIRA)]

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

Pavel Moravec updated QPID-5108:


Attachment: QPID-5108-improved.patch

Based on gsim's advice, I moved the statistics update from SemanticsState to 
SessionState, to get rid of the re-casting issue. SemanticState just calls the 
SessionState methods updating the stats directly.

 session statistics Tx* not updated any time
 ---

 Key: QPID-5108
 URL: https://issues.apache.org/jira/browse/QPID-5108
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.22
Reporter: Pavel Moravec
Priority: Minor
  Labels: patch
 Attachments: QPID-5108-improved.patch, QPID-5108.patch

   Original Estimate: 3h
  Remaining Estimate: 3h

 Description of problem:
 Tx* counters of Session QMF object are everytime zero, regardless if 
 transactions are/have been used or not.
 Version-Release number of selected component (if applicable):
 0.22
 How reproducible:
 100%
 Steps to Reproduce:
 echo log-to-file=/tmp/qpidd.log  /etc/qpid/qpidd.conf
 echo auth=no  /etc/qpid/qpidd.conf
 echo trace=yes  /etc/qpid/qpidd.conf
 rm -rf /tmp/qpidd.log 
 service qpidd restart
 qpid-send -m 20 -a myQueue; {create:always} --tx 2 --rollback-frequency 2
 sleep 10
 grep Tx /tmp/qpidd.log | grep session
 (optionally, check the the session statistics in qpid-tool)
 Actual results:
 2013-08-30 10:22:38 [Model] trace Mgmt delete session. 
 id:18f9a28a-f5b0-4e9d-9fe7-dc49a1463e6a Statistics: {TxnCommits:0, 
 TxnCount:0, TxnRejects:0, TxnStarts:0, clientCredit:0, unackedMessages:0}
 2013-08-30 10:22:38 [Management] trace Deleting V2 
 map={_create_ts:1377850955102035092, _delete_ts:1377850955109735713, 
 _object_id:{_agent_epoch:1, 
 _object_name:org.apache.qpid.broker:session:18f9a28a-f5b0-4e9d-9fe7-dc49a1463e6a},
  _schema_id:{_class_name:session, _hash:1aaa08d0-c118-ff78-0956-47b9ac9c6849, 
 _package_name:org.apache.qpid.broker, _type:_data}, 
 _update_ts:1377850955102035092, _values:{TxnCommits:0, TxnCount:0, 
 TxnRejects:0, TxnStarts:0, attached:False, channelId:1, clientCredit:0, 
 connectionRef:{_agent_epoch:1, 
 _object_name:org.apache.qpid.broker:connection:127.0.0.1:5672-127.0.0.1:52255},
  detachedLifespan:0, name:18f9a28a-f5b0-4e9d-9fe7-dc49a1463e6a, 
 unackedMessages:0, 
 vhostRef:{_object_name:org.apache.qpid.broker:vhost:org.apache.qpid.broker:broker:amqp-broker,/}}}
 See TxnCommits:0, TxnCount:0, TxnRejects:0, TxnStarts:0 in both trace logs 
 / qpid-tool
 Expected results:
 TxnCommits:6, TxnCount:11, TxnRejects:5, TxnStarts:1
 (10 transactions, every 2nd rejected, plus one extra at the end)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (QPID-5107) Trace queuesession deletion statistics show zero values for some counters everytime

[Pavel Moravec (JIRA)]

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

Pavel Moravec updated QPID-5107:


Attachment: QPID-5107_debugStats.patch

Chuck's enhancement makes sense, though having the drawback in explicitly 
calling debugStats at the beginning of destructor/closing method of every 
manageable object. As generic Class.cpp destructor can't call debugStats method 
since queue and session stats are already wrong (over-updated).

Also, as different exchange types might over-update statistics in future, I 
decided to call the debugStats() method from individual destructors of all 
exchange types and not from 

QPID_BROKER_INLINE_EXTERN virtual qpid::broker::Exchange::~Exchange();

Attached is a patch for that. It lacks calling debugStats for memory, as the 
class qpid::sys::posix::MemStat does not have management object declared, just 
provided in method argument. Anyway, there is imho no need to fix this as 
memory statistics are empty now (check current trace Mgmt delete memory. 
id:amqp-broker Statistics: {}).

Leaving both variants of the patches to let upstream to chose.

 Trace queuesession deletion statistics show zero values for some counters 
 everytime
 

 Key: QPID-5107
 URL: https://issues.apache.org/jira/browse/QPID-5107
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.22
Reporter: Pavel Moravec
Priority: Minor
  Labels: easyfix, easytest, patch
 Attachments: QPID-5107_debugStats.patch, QPID-5107.patch

   Original Estimate: 2h
  Remaining Estimate: 2h

 Description of problem:
 qpid trace/logs statistics about object deletion. However some of these data 
 are wrong. In particular msgDepth for a queue is everytime zero (and 
 msgTotalDequeues equals to msgTotalEnqueues despite no consumer was 
 subscribed to the queue), or unackedMessages for a session is zero everytime 
 as well.
 Version-Release number of selected component (if applicable):
 qpid 0.22
 How reproducible:
 100%
 Steps to Reproduce:
 1) msgDepth:0 for queue:
 echo auth=no  /etc/qpid/qpidd.conf
 echo trace=yes  /etc/qpid/qpidd.conf
 echo log-to-file=/tmp/qpidd.log  /etc/qpid/qpidd.conf
 rm -rf /var/lib/qpidd/* /tmp/qpidd.log
 service qpidd restart
 qpid-send -m 123 -a testQueue; {create:always, delete:always}
 sleep 10  # just to let periodic processing to run  print out the stats
 grep Mgmt delete queue /tmp/qpidd.log
 Actual results:
 2013-08-29 14:05:38 [Model] trace Mgmt delete queue. id:testQueue Statistics: 
 {acquires:123, bindingCount:0, bindingCountHigh:0, bindingCountLow:0, 
 byteDepth:0, byteFtdDepth:0, byteFtdDequeues:0, byteFtdEnqueues:0, 
 bytePersistDequeues:0, bytePersistEnqueues:0, byteTotalDequeues:0, 
 byteTotalEnqueues:0, byteTxnDequeues:0, byteTxnEnqueues:0, consumerCount:0, 
 consumerCountHigh:0, consumerCountLow:0, discardsLvq:0, discardsOverflow:0, 
 discardsPurge:0, discardsRing:0, discardsSubscriber:0, discardsTtl:0, 
 flowStopped:False, flowStoppedCount:0, messageLatencyAvg:0, 
 messageLatencyCount:0, messageLatencyMax:0, messageLatencyMin:0, msgDepth:0, 
 msgFtdDepth:0, msgFtdDequeues:0, msgFtdEnqueues:0, msgPersistDequeues:0, 
 msgPersistEnqueues:0, msgTotalDequeues:123, msgTotalEnqueues:123, 
 msgTxnDequeues:0, msgTxnEnqueues:0, releases:0, reroutes:0, 
 unackedMessages:0, unackedMessagesHigh:0, unackedMessagesLow:0}
 Expected results:
 acquires:0
 msgTotalDequeues:0
 (several other counters are supposed to be wrong as well like byteFtdDequeues)
 2) Reproducer for unackedMessages:0 for session:
 qpid-send -m 11 -a myQueue; {create:always}
 qpid-receive -m 100 -a myQueue; {create:always} -f
 (in another terminal)
 qpid-tool
 list connection
 call ID_of_qpid-receive-connection close
 and now check result:
 grep Tx /tmp/qpidd.log | grep session
 should return unackedMessages:11 but returns zero.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (QPID-5107) Trace queuesession deletion statistics show zero values for some counters everytime

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5107:
---

 Summary: Trace queuesession deletion statistics show zero values 
for some counters everytime
 Key: QPID-5107
 URL: https://issues.apache.org/jira/browse/QPID-5107
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.22
Reporter: Pavel Moravec
Priority: Minor


Description of problem:
qpid trace/logs statistics about object deletion. However some of these data 
are wrong. In particular msgDepth for a queue is everytime zero (and 
msgTotalDequeues equals to msgTotalEnqueues despite no consumer was subscribed 
to the queue), or unackedMessages for a session is zero everytime as well.


Version-Release number of selected component (if applicable):
qpid 0.22


How reproducible:
100%


Steps to Reproduce:
1) msgDepth:0 for queue:
echo auth=no  /etc/qpid/qpidd.conf
echo trace=yes  /etc/qpid/qpidd.conf
echo log-to-file=/tmp/qpidd.log  /etc/qpid/qpidd.conf
rm -rf /var/lib/qpidd/* /tmp/qpidd.log
service qpidd restart
qpid-send -m 123 -a testQueue; {create:always, delete:always}
sleep 10  # just to let periodic processing to run  print out the stats
grep Mgmt delete queue /tmp/qpidd.log


Actual results:
2013-08-29 14:05:38 [Model] trace Mgmt delete queue. id:testQueue Statistics: 
{acquires:123, bindingCount:0, bindingCountHigh:0, bindingCountLow:0, 
byteDepth:0, byteFtdDepth:0, byteFtdDequeues:0, byteFtdEnqueues:0, 
bytePersistDequeues:0, bytePersistEnqueues:0, byteTotalDequeues:0, 
byteTotalEnqueues:0, byteTxnDequeues:0, byteTxnEnqueues:0, consumerCount:0, 
consumerCountHigh:0, consumerCountLow:0, discardsLvq:0, discardsOverflow:0, 
discardsPurge:0, discardsRing:0, discardsSubscriber:0, discardsTtl:0, 
flowStopped:False, flowStoppedCount:0, messageLatencyAvg:0, 
messageLatencyCount:0, messageLatencyMax:0, messageLatencyMin:0, msgDepth:0, 
msgFtdDepth:0, msgFtdDequeues:0, msgFtdEnqueues:0, msgPersistDequeues:0, 
msgPersistEnqueues:0, msgTotalDequeues:123, msgTotalEnqueues:123, 
msgTxnDequeues:0, msgTxnEnqueues:0, releases:0, reroutes:0, unackedMessages:0, 
unackedMessagesHigh:0, unackedMessagesLow:0}


Expected results:
acquires:0
msgTotalDequeues:0
(several other counters are supposed to be wrong as well like byteFtdDequeues)



2) Reproducer for unackedMessages:0 for session:
qpid-send -m 11 -a myQueue; {create:always}
qpid-receive -m 100 -a myQueue; {create:always} -f

(in another terminal)
qpid-tool
list connection
call ID_of_qpid-receive-connection close

and now check result:

grep Tx /tmp/qpidd.log | grep session

should return unackedMessages:11 but returns zero.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (QPID-5107) Trace queuesession deletion statistics show zero values for some counters everytime

[Pavel Moravec (JIRA)]

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

Pavel Moravec updated QPID-5107:


Attachment: QPID-5107.patch

Patch proposal: tricky suppressing management stats updates during destroying 
queue and/or session.

 Trace queuesession deletion statistics show zero values for some counters 
 everytime
 

 Key: QPID-5107
 URL: https://issues.apache.org/jira/browse/QPID-5107
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.22
Reporter: Pavel Moravec
Priority: Minor
  Labels: easyfix, easytest, patch
 Attachments: QPID-5107.patch

   Original Estimate: 2h
  Remaining Estimate: 2h

 Description of problem:
 qpid trace/logs statistics about object deletion. However some of these data 
 are wrong. In particular msgDepth for a queue is everytime zero (and 
 msgTotalDequeues equals to msgTotalEnqueues despite no consumer was 
 subscribed to the queue), or unackedMessages for a session is zero everytime 
 as well.
 Version-Release number of selected component (if applicable):
 qpid 0.22
 How reproducible:
 100%
 Steps to Reproduce:
 1) msgDepth:0 for queue:
 echo auth=no  /etc/qpid/qpidd.conf
 echo trace=yes  /etc/qpid/qpidd.conf
 echo log-to-file=/tmp/qpidd.log  /etc/qpid/qpidd.conf
 rm -rf /var/lib/qpidd/* /tmp/qpidd.log
 service qpidd restart
 qpid-send -m 123 -a testQueue; {create:always, delete:always}
 sleep 10  # just to let periodic processing to run  print out the stats
 grep Mgmt delete queue /tmp/qpidd.log
 Actual results:
 2013-08-29 14:05:38 [Model] trace Mgmt delete queue. id:testQueue Statistics: 
 {acquires:123, bindingCount:0, bindingCountHigh:0, bindingCountLow:0, 
 byteDepth:0, byteFtdDepth:0, byteFtdDequeues:0, byteFtdEnqueues:0, 
 bytePersistDequeues:0, bytePersistEnqueues:0, byteTotalDequeues:0, 
 byteTotalEnqueues:0, byteTxnDequeues:0, byteTxnEnqueues:0, consumerCount:0, 
 consumerCountHigh:0, consumerCountLow:0, discardsLvq:0, discardsOverflow:0, 
 discardsPurge:0, discardsRing:0, discardsSubscriber:0, discardsTtl:0, 
 flowStopped:False, flowStoppedCount:0, messageLatencyAvg:0, 
 messageLatencyCount:0, messageLatencyMax:0, messageLatencyMin:0, msgDepth:0, 
 msgFtdDepth:0, msgFtdDequeues:0, msgFtdEnqueues:0, msgPersistDequeues:0, 
 msgPersistEnqueues:0, msgTotalDequeues:123, msgTotalEnqueues:123, 
 msgTxnDequeues:0, msgTxnEnqueues:0, releases:0, reroutes:0, 
 unackedMessages:0, unackedMessagesHigh:0, unackedMessagesLow:0}
 Expected results:
 acquires:0
 msgTotalDequeues:0
 (several other counters are supposed to be wrong as well like byteFtdDequeues)
 2) Reproducer for unackedMessages:0 for session:
 qpid-send -m 11 -a myQueue; {create:always}
 qpid-receive -m 100 -a myQueue; {create:always} -f
 (in another terminal)
 qpid-tool
 list connection
 call ID_of_qpid-receive-connection close
 and now check result:
 grep Tx /tmp/qpidd.log | grep session
 should return unackedMessages:11 but returns zero.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (QPID-5108) session statistics Tx* not updated any time

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5108:
---

 Summary: session statistics Tx* not updated any time
 Key: QPID-5108
 URL: https://issues.apache.org/jira/browse/QPID-5108
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.22
Reporter: Pavel Moravec
Priority: Minor


Description of problem:
Tx* counters of Session QMF object are everytime zero, regardless if 
transactions are/have been used or not.


Version-Release number of selected component (if applicable):
0.22


How reproducible:
100%


Steps to Reproduce:
echo log-to-file=/tmp/qpidd.log  /etc/qpid/qpidd.conf
echo auth=no  /etc/qpid/qpidd.conf
echo trace=yes  /etc/qpid/qpidd.conf
rm -rf /tmp/qpidd.log 
service qpidd restart
qpid-send -m 20 -a myQueue; {create:always} --tx 2 --rollback-frequency 2
sleep 10
grep Tx /tmp/qpidd.log | grep session

(optionally, check the the session statistics in qpid-tool)


Actual results:
2013-08-30 10:22:38 [Model] trace Mgmt delete session. 
id:18f9a28a-f5b0-4e9d-9fe7-dc49a1463e6a Statistics: {TxnCommits:0, TxnCount:0, 
TxnRejects:0, TxnStarts:0, clientCredit:0, unackedMessages:0}
2013-08-30 10:22:38 [Management] trace Deleting V2 
map={_create_ts:1377850955102035092, _delete_ts:1377850955109735713, 
_object_id:{_agent_epoch:1, 
_object_name:org.apache.qpid.broker:session:18f9a28a-f5b0-4e9d-9fe7-dc49a1463e6a},
 _schema_id:{_class_name:session, _hash:1aaa08d0-c118-ff78-0956-47b9ac9c6849, 
_package_name:org.apache.qpid.broker, _type:_data}, 
_update_ts:1377850955102035092, _values:{TxnCommits:0, TxnCount:0, 
TxnRejects:0, TxnStarts:0, attached:False, channelId:1, clientCredit:0, 
connectionRef:{_agent_epoch:1, 
_object_name:org.apache.qpid.broker:connection:127.0.0.1:5672-127.0.0.1:52255}, 
detachedLifespan:0, name:18f9a28a-f5b0-4e9d-9fe7-dc49a1463e6a, 
unackedMessages:0, 
vhostRef:{_object_name:org.apache.qpid.broker:vhost:org.apache.qpid.broker:broker:amqp-broker,/}}}

See TxnCommits:0, TxnCount:0, TxnRejects:0, TxnStarts:0 in both trace logs / 
qpid-tool

Expected results:
TxnCommits:6, TxnCount:11, TxnRejects:5, TxnStarts:1
(10 transactions, every 2nd rejected, plus one extra at the end)


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (QPID-5108) session statistics Tx* not updated any time

[Pavel Moravec (JIRA)]

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

Pavel Moravec updated QPID-5108:


Attachment: QPID-5108.patch

Guessing that TxnStarts counter stands for number of tx.select messages sent on 
the session, the counter can be at most one.

Guessing that TxnCount=TxnCommits+TxnRejects.

Based on that, see attached patch.

The patch does not calculate DTX transactions as I was unable to match DTX 
methods to the stats counters.

 session statistics Tx* not updated any time
 ---

 Key: QPID-5108
 URL: https://issues.apache.org/jira/browse/QPID-5108
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.22
Reporter: Pavel Moravec
Priority: Minor
  Labels: patch
 Attachments: QPID-5108.patch

   Original Estimate: 3h
  Remaining Estimate: 3h

 Description of problem:
 Tx* counters of Session QMF object are everytime zero, regardless if 
 transactions are/have been used or not.
 Version-Release number of selected component (if applicable):
 0.22
 How reproducible:
 100%
 Steps to Reproduce:
 echo log-to-file=/tmp/qpidd.log  /etc/qpid/qpidd.conf
 echo auth=no  /etc/qpid/qpidd.conf
 echo trace=yes  /etc/qpid/qpidd.conf
 rm -rf /tmp/qpidd.log 
 service qpidd restart
 qpid-send -m 20 -a myQueue; {create:always} --tx 2 --rollback-frequency 2
 sleep 10
 grep Tx /tmp/qpidd.log | grep session
 (optionally, check the the session statistics in qpid-tool)
 Actual results:
 2013-08-30 10:22:38 [Model] trace Mgmt delete session. 
 id:18f9a28a-f5b0-4e9d-9fe7-dc49a1463e6a Statistics: {TxnCommits:0, 
 TxnCount:0, TxnRejects:0, TxnStarts:0, clientCredit:0, unackedMessages:0}
 2013-08-30 10:22:38 [Management] trace Deleting V2 
 map={_create_ts:1377850955102035092, _delete_ts:1377850955109735713, 
 _object_id:{_agent_epoch:1, 
 _object_name:org.apache.qpid.broker:session:18f9a28a-f5b0-4e9d-9fe7-dc49a1463e6a},
  _schema_id:{_class_name:session, _hash:1aaa08d0-c118-ff78-0956-47b9ac9c6849, 
 _package_name:org.apache.qpid.broker, _type:_data}, 
 _update_ts:1377850955102035092, _values:{TxnCommits:0, TxnCount:0, 
 TxnRejects:0, TxnStarts:0, attached:False, channelId:1, clientCredit:0, 
 connectionRef:{_agent_epoch:1, 
 _object_name:org.apache.qpid.broker:connection:127.0.0.1:5672-127.0.0.1:52255},
  detachedLifespan:0, name:18f9a28a-f5b0-4e9d-9fe7-dc49a1463e6a, 
 unackedMessages:0, 
 vhostRef:{_object_name:org.apache.qpid.broker:vhost:org.apache.qpid.broker:broker:amqp-broker,/}}}
 See TxnCommits:0, TxnCount:0, TxnRejects:0, TxnStarts:0 in both trace logs 
 / qpid-tool
 Expected results:
 TxnCommits:6, TxnCount:11, TxnRejects:5, TxnStarts:1
 (10 transactions, every 2nd rejected, plus one extra at the end)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (QPID-5057) Delivery properties expiration and timestamp are in milliseconds instead of seconds

[Pavel Moravec (JIRA)]

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

Pavel Moravec updated QPID-5057:


Attachment: (was: bz995079.patch)

 Delivery properties expiration and timestamp are in milliseconds instead 
 of seconds
 ---

 Key: QPID-5057
 URL: https://issues.apache.org/jira/browse/QPID-5057
 Project: Qpid
  Issue Type: Bug
  Components: Java Client
Affects Versions: 0.22
Reporter: Pavel Moravec
Priority: Minor
 Attachments: SendMsgTimestamp.java


 Per AMQP 0.10 specification, message delivery properties  expiration and 
 timestamp are of type datetime, that is 64 bit POSIX time_t format, i.e. 
 seconds since Epoch.
 But Java client implementation of both 0.8 and 0.10 protocol versions encodes 
 the properties in milliseconds. See e.g. 
 org/apache/qpid/client/BasicMessageProducer_0_10.java:
 long currentTime = 0;
 if (timeToLive  0 || !isDisableTimestamps())
 {
 currentTime = System.currentTimeMillis();
 }
 if (timeToLive  0)
 {
 deliveryProp.setTtl(timeToLive);
 message.setJMSExpiration(currentTime + timeToLive);
 }
 if (!isDisableTimestamps())
 {
 deliveryProp.setTimestamp(currentTime);
 message.setJMSTimestamp(currentTime);
 }
 I.e. there should be currentTime = System.currentTimeMillis()/1000;, rather.
 The same is in 0.8 client as well (while AMQP 0.8 specification does not know 
 either of the two delivery properties).
 I could propose a trivial patch for the 0.8 and 0.10 client, but I am not 
 sure how this affects:
 - AMQP 1.0 implementation I am not familiar with
 - (Java only?) broker or other clients utilizing the properties

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (QPID-5057) Delivery properties expiration and timestamp are in milliseconds instead of seconds

[Pavel Moravec (JIRA)]

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

Pavel Moravec updated QPID-5057:


Attachment: QPID-5057.patch

Patch for correcting the expiration+timestamp formats.

 Delivery properties expiration and timestamp are in milliseconds instead 
 of seconds
 ---

 Key: QPID-5057
 URL: https://issues.apache.org/jira/browse/QPID-5057
 Project: Qpid
  Issue Type: Bug
  Components: Java Client
Affects Versions: 0.22
Reporter: Pavel Moravec
Priority: Minor
 Attachments: QPID-5057.patch, SendMsgTimestamp.java


 Per AMQP 0.10 specification, message delivery properties  expiration and 
 timestamp are of type datetime, that is 64 bit POSIX time_t format, i.e. 
 seconds since Epoch.
 But Java client implementation of both 0.8 and 0.10 protocol versions encodes 
 the properties in milliseconds. See e.g. 
 org/apache/qpid/client/BasicMessageProducer_0_10.java:
 long currentTime = 0;
 if (timeToLive  0 || !isDisableTimestamps())
 {
 currentTime = System.currentTimeMillis();
 }
 if (timeToLive  0)
 {
 deliveryProp.setTtl(timeToLive);
 message.setJMSExpiration(currentTime + timeToLive);
 }
 if (!isDisableTimestamps())
 {
 deliveryProp.setTimestamp(currentTime);
 message.setJMSTimestamp(currentTime);
 }
 I.e. there should be currentTime = System.currentTimeMillis()/1000;, rather.
 The same is in 0.8 client as well (while AMQP 0.8 specification does not know 
 either of the two delivery properties).
 I could propose a trivial patch for the 0.8 and 0.10 client, but I am not 
 sure how this affects:
 - AMQP 1.0 implementation I am not familiar with
 - (Java only?) broker or other clients utilizing the properties

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (QPID-5057) Delivery properties expiration and timestamp are in milliseconds instead of seconds

[Pavel Moravec (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-5057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13740795#comment-13740795
 ] 

Pavel Moravec commented on QPID-5057:
-

Thanks for comments. I uploaded a new version of the patch that fixes just the 
format, and does not allow re-writing timestamp.

The timestamp setting would be another issue and moreover not valid one. As 
quoting JMS spec for setJMSTimestamp 
(http://docs.oracle.com/javaee/6/api/javax/jms/Message.html#setJMSTimestamp%28long%29):
 This method can be used to change the value for a message that has been 
received. So no word about senders.

I checked neither expiration or timestamp is mentioned in consumers in Java 
client, hence no reverse conversion is required to be added to the patch.

From the reproducer, 3rd message should be ignored (it tests setting 
timestamp).

 Delivery properties expiration and timestamp are in milliseconds instead 
 of seconds
 ---

 Key: QPID-5057
 URL: https://issues.apache.org/jira/browse/QPID-5057
 Project: Qpid
  Issue Type: Bug
  Components: Java Client
Affects Versions: 0.22
Reporter: Pavel Moravec
Priority: Minor
 Attachments: QPID-5057.patch, SendMsgTimestamp.java


 Per AMQP 0.10 specification, message delivery properties  expiration and 
 timestamp are of type datetime, that is 64 bit POSIX time_t format, i.e. 
 seconds since Epoch.
 But Java client implementation of both 0.8 and 0.10 protocol versions encodes 
 the properties in milliseconds. See e.g. 
 org/apache/qpid/client/BasicMessageProducer_0_10.java:
 long currentTime = 0;
 if (timeToLive  0 || !isDisableTimestamps())
 {
 currentTime = System.currentTimeMillis();
 }
 if (timeToLive  0)
 {
 deliveryProp.setTtl(timeToLive);
 message.setJMSExpiration(currentTime + timeToLive);
 }
 if (!isDisableTimestamps())
 {
 deliveryProp.setTimestamp(currentTime);
 message.setJMSTimestamp(currentTime);
 }
 I.e. there should be currentTime = System.currentTimeMillis()/1000;, rather.
 The same is in 0.8 client as well (while AMQP 0.8 specification does not know 
 either of the two delivery properties).
 I could propose a trivial patch for the 0.8 and 0.10 client, but I am not 
 sure how this affects:
 - AMQP 1.0 implementation I am not familiar with
 - (Java only?) broker or other clients utilizing the properties

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (QPID-5057) Delivery properties expiration and timestamp are in milliseconds instead of seconds

[Pavel Moravec (JIRA)]

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

Pavel Moravec updated QPID-5057:


Attachment: SendMsgTimestamp.java

Reproducer that sends 4 messages to DurableQueue, one after another having:
- expiration set 10 seconds in advance (this wont cause the message to expire 
though, see AMQP 0.10 specification for reasoning)
- default one
- timestamp set 100 seconds in advance
- TTL set to 10 seconds

See e.g. in tcpdump what is really sent.

Current behaviour:
- 1st message has proper timestamp in year 45588 or so and 
expiration=currentTime+10
- 2nd message has timestamp in year 45588 or so
- 3rd message has timestamp in year 45588 or so
- 4th message has timestamp in year 45588 or so,  expiration=timestamp+10 (also 
too far in future) and TTL=10

Expected behaviour:
- 1st message has proper timestamp=currentTime and expiration=currentTime+10
- 2nd message has timestamp=currentTime
- 3rd message has timestamp=currentTime+100
- 4th message has timestamp=currentTime, expiration=currentTime+10 and TTL=10

 Delivery properties expiration and timestamp are in milliseconds instead 
 of seconds
 ---

 Key: QPID-5057
 URL: https://issues.apache.org/jira/browse/QPID-5057
 Project: Qpid
  Issue Type: Bug
  Components: Java Client
Affects Versions: 0.22
Reporter: Pavel Moravec
Priority: Minor
 Attachments: bz995079.patch, SendMsgTimestamp.java


 Per AMQP 0.10 specification, message delivery properties  expiration and 
 timestamp are of type datetime, that is 64 bit POSIX time_t format, i.e. 
 seconds since Epoch.
 But Java client implementation of both 0.8 and 0.10 protocol versions encodes 
 the properties in milliseconds. See e.g. 
 org/apache/qpid/client/BasicMessageProducer_0_10.java:
 long currentTime = 0;
 if (timeToLive  0 || !isDisableTimestamps())
 {
 currentTime = System.currentTimeMillis();
 }
 if (timeToLive  0)
 {
 deliveryProp.setTtl(timeToLive);
 message.setJMSExpiration(currentTime + timeToLive);
 }
 if (!isDisableTimestamps())
 {
 deliveryProp.setTimestamp(currentTime);
 message.setJMSTimestamp(currentTime);
 }
 I.e. there should be currentTime = System.currentTimeMillis()/1000;, rather.
 The same is in 0.8 client as well (while AMQP 0.8 specification does not know 
 either of the two delivery properties).
 I could propose a trivial patch for the 0.8 and 0.10 client, but I am not 
 sure how this affects:
 - AMQP 1.0 implementation I am not familiar with
 - (Java only?) broker or other clients utilizing the properties

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (QPID-5057) Delivery properties expiration and timestamp are in milliseconds instead of seconds

[Pavel Moravec (JIRA)]

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

Pavel Moravec updated QPID-5057:


Attachment: bz995079.patch

Patch proposal fixing two bugs, in fact:

1) expiration and timestamp delivery properties sent in proper format (datetime 
in seconds, not in ms).

2) ability to re-write timestamp (i.e. set timestamp automatically only if it 
hasn't been already set)

 Delivery properties expiration and timestamp are in milliseconds instead 
 of seconds
 ---

 Key: QPID-5057
 URL: https://issues.apache.org/jira/browse/QPID-5057
 Project: Qpid
  Issue Type: Bug
  Components: Java Client
Affects Versions: 0.22
Reporter: Pavel Moravec
Priority: Minor
 Attachments: bz995079.patch, SendMsgTimestamp.java


 Per AMQP 0.10 specification, message delivery properties  expiration and 
 timestamp are of type datetime, that is 64 bit POSIX time_t format, i.e. 
 seconds since Epoch.
 But Java client implementation of both 0.8 and 0.10 protocol versions encodes 
 the properties in milliseconds. See e.g. 
 org/apache/qpid/client/BasicMessageProducer_0_10.java:
 long currentTime = 0;
 if (timeToLive  0 || !isDisableTimestamps())
 {
 currentTime = System.currentTimeMillis();
 }
 if (timeToLive  0)
 {
 deliveryProp.setTtl(timeToLive);
 message.setJMSExpiration(currentTime + timeToLive);
 }
 if (!isDisableTimestamps())
 {
 deliveryProp.setTimestamp(currentTime);
 message.setJMSTimestamp(currentTime);
 }
 I.e. there should be currentTime = System.currentTimeMillis()/1000;, rather.
 The same is in 0.8 client as well (while AMQP 0.8 specification does not know 
 either of the two delivery properties).
 I could propose a trivial patch for the 0.8 and 0.10 client, but I am not 
 sure how this affects:
 - AMQP 1.0 implementation I am not familiar with
 - (Java only?) broker or other clients utilizing the properties

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (QPID-5072) [C++ broker] SessionManager does not forget sessions when broker drops connection after journal error, leading to memory leak

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-5072:
---

 Summary: [C++ broker] SessionManager does not forget sessions when 
broker drops connection after journal error, leading to memory leak
 Key: QPID-5072
 URL: https://issues.apache.org/jira/browse/QPID-5072
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.22
Reporter: Pavel Moravec


Description of problem:
Broker rejects session re-subscription (on a new AMQP+TCP connection) after the 
previous was dropped due to a journal error. This bug in broker:
- is in fact a memory leak, as session manager map is not cleared when requested
- it affects Java client during failover, when original journal problem has 
been already resolved, but the client can't even attach the same session.


Version-Release number of selected component (if applicable):
any (teste 0.18 and also 0.22 broker)


How reproducible:
100%


Steps to Reproduce:
1) run attached Java reproducer on a fresh broker:
java test_00903524_threaded 1

2) check qpidd logs for errors


Actual results:
2013-08-02 11:39:04 [Protocol] error Unexpected exception: Enqueue capacity 
threshold exceeded on queue testQueue. 
(/builddir/build/BUILD/qpid-0.22/cpp/src/qpid/legacystore/JournalImpl.cpp:594)
2013-08-02 11:39:04 [Protocol] error Connection 
qpid.10.34.1.141:5672-10.34.1.141:42635 closed by error: Enqueue capacity 
threshold exceeded on queue testQueue. 
(/builddir/build/BUILD/qpid-0.22/cpp/src/qpid/legacystore/JournalImpl.cpp:594)(501)
2013-08-02 11:39:14 [Protocol] error Channel exception: session-busy: Session 
already attached: guest@QPID.36332225-5c5b-4077-b8ec-820555253a89 
(/builddir/build/BUILD/qpid-0.22/cpp/src/qpid/broker/SessionManager.cpp:55)
2013-08-02 11:39:14 [Protocol] error Channel exception: not-attached: Channel 1 
is not attached 
(/builddir/build/BUILD/qpid-0.22/cpp/src/qpid/amqp_0_10/SessionHandler.cpp:39)
..
(few thousands of the latest error)


Expected results:
just the journal error be seen (and multiple times), not the Session already 
attached one or Channel 1 is not attached one.


Additional info:
The broker management _deletes_ the session, as the broker logs:

2013-08-02 11:39:04 [Management] trace Management object marked deleted: 
org.apache.qpid.broker:session:36332225-5c5b-4077-b8ec-820555253a89
   org.apache.qpid.broker:session:36332225-5c5b-4077-b8ec-820555253a89 (deleted)
2013-08-02 11:39:10 [Management] trace Deleting V1 properties 
0-68-1--14(org.apache.qpid.broker:session:36332225-5c5b-4077-b8ec-820555253a89) 
len=164
2013-08-02 11:39:10 [Management] trace Deleting V1 statistics 
0-68-1--14(org.apache.qpid.broker:session:36332225-5c5b-4077-b8ec-820555253a89) 
len=127
2013-08-02 11:39:10 [Management] trace Deleting V2 
map={_create_ts:1375436343054221056, _delete_ts:1375436344249095890, 
_object_id:{_agent_epoch:68, 
_object_name:org.apache.qpid.broker:session:36332225-5c5b-4077-b8ec-820555253a89},
 _schema_id:{_class_name:session, _hash:1aaa08d0-c118-ff78-0956-47b9ac9c6849, 
_package_name:org.apache.qpid.broker, _type:_data}, 
_update_ts:1375436343054221056, _values:{TxnCommits:0, TxnCount:0, 
TxnRejects:0, TxnStarts:0, attached:True, channelId:0, clientCredit:0, 
connectionRef:{_agent_epoch:68, 
_object_name:org.apache.qpid.broker:connection:qpid.10.34.1.141:5672-10.34.1.141:42635},
 detachedLifespan:0, name:36332225-5c5b-4077-b8ec-820555253a89, 
unackedMessages:0, 
vhostRef:{_object_name:org.apache.qpid.broker:vhost:org.apache.qpid.broker:broker:amqp-broker,/}}}

But session manager inside does not forget the sessions/channels..


Reproduction for memory leak:
run attached script

Weird is, even fixing the bug for Java client, some steady memory increase is 
still present..

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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