[jira] [Commented] (DISPATCH-106) pn link corruption after router restart
[
https://issues.apache.org/jira/browse/DISPATCH-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14298201#comment-14298201
]
michael j. goulish commented on DISPATCH-106:
-
OK, will do.very interesting -- thanks !
pn link corruption after router restart
---
Key: DISPATCH-106
URL: https://issues.apache.org/jira/browse/DISPATCH-106
Project: Qpid Dispatch
Issue Type: Bug
Components: Router Node
Affects Versions: 0.3
Reporter: michael goulish
Fix For: 0.4
With the standard 6-node demo network, (A-D, X, Y) after killing and
restarting node Y, I see a bad link on router D -- which causes D to crash.
Here is sequence of events from logs of routers and the topologist testing
program:
01:05:05.367 Killing router Y, pid 20074
01:05:05.367 Sleeping 30 seconds
01:05:35.367 Restarting router Y, pid 20120
01:05:38 Router D : last valid origins post to its log file :
Node QDR.C valid origins: []
01:05:46 Router D posts to its log file:
Exited Router Flux Mode
01:06:05.368 checking for crash after node bounce
( no crash detected )
01:06:17 last post to router D log file
ROUTER_LS (trace) RCVD: RA(id=QDR.X area=0 inst=1422165872
ls_seq=2 mobile_seq=0)
01:06:35.369 second check for crash. (none detected)
01:06:35.370 getting topology
( Node D fails to respond. PID 20072 )
( core file, timestamped 01:06 )
here is backtrace from router D's core file
{
#0 pn_string_get (string=0xfdfdfdfdbabecafe) at
/home/mick/rh-qpid-proton/proton-c/src/object/string.c:120
#1 0x7ff73fa8e752 in qd_router_link_name (link=0x7ff72800b2d0) at
/home/mick/dispatch/src/router_agent.c:112
#2 0x7ff73fa8e7dd in qd_entity_refresh_router_link
(entity=0x7ff7300c9b50, impl=0x7ff72800b2d0)
at /home/mick/dispatch/src/router_agent.c:120
#3 0x003e40805d8c in ffi_call_unix64 () from /lib64/libffi.so.6
#4 0x003e408056bc in ffi_call () from /lib64/libffi.so.6
#5 0x7ff737d2dc8b in _ctypes_callproc () from
/usr/lib64/python2.7/lib-dynload/_ctypes.so
#6 0x7ff737d27a85 in PyCFuncPtr_call () from
/usr/lib64/python2.7/lib-dynload/_ctypes.so
#7 0x0036df44a0d3 in PyObject_Call () from /lib64/libpython2.7.so.1.0
#8 0x0036df4de37c in PyEval_EvalFrameEx () from
/lib64/libpython2.7.so.1.0
#9 0x0036df4e21dd in PyEval_EvalCodeEx () from
/lib64/libpython2.7.so.1.0
#10 0x0036df4e088f in PyEval_EvalFrameEx () from
/lib64/libpython2.7.so.1.0
#11 0x0036df4e21dd in PyEval_EvalCodeEx () from
/lib64/libpython2.7.so.1.0
#12 0x0036df4e088f in PyEval_EvalFrameEx () from
/lib64/libpython2.7.so.1.0
#13 0x0036df4e21dd in PyEval_EvalCodeEx () from
/lib64/libpython2.7.so.1.0
#14 0x0036df46f0d8 in ?? () from /lib64/libpython2.7.so.1.0
#15 0x0036df44a0d3 in PyObject_Call () from /lib64/libpython2.7.so.1.0
#16 0x0036df4590c5 in ?? () from /lib64/libpython2.7.so.1.0
#17 0x0036df44a0d3 in PyObject_Call () from /lib64/libpython2.7.so.1.0
#18 0x0036df44a1b5 in ?? () from /lib64/libpython2.7.so.1.0
#19 0x0036df44a29e in PyObject_CallFunction () from
/lib64/libpython2.7.so.1.0
#20 0x7ff73fa8d77f in qd_io_rx_handler (context=0x7ff736321e68,
msg=0x7ff728019bd0, link_id=0
at /home/mick/dispatch/src/python_embedded.c:519
#21 0x7ff73fa92533 in router_rx_handler (context=0x1db5fd0,
link=0x7ff730008710, delivery=0x7ff73004cc50)
at /home/mick/dispatch/src/router_node.c:922
#22 0x7ff73fa7fa16 in do_receive (pnd=0x1e359a0) at
/home/mick/dispatch/src/container.c:221
#23 0x7ff73fa7fea3 in process_handler (container=0x1dbd6f0,
unused=0x1e0a050, qd_conn=0x1e2c6a0)
at /home/mick/dispatch/src/container.c:362
#24 0x7ff73fa80135 in handler (handler_context=0x1dbd6f0,
conn_context=0x1e0a050, event=QD_CONN_EVENT_PROCESS,
qd_conn=0x1e2c6a0) at /home/mick/dispatch/src/container.c:438
#25 0x7ff73fa98346 in process_connector (qd_server=0x1d78460,
cxtr=0x1e1b9b0)
at /home/mick/dispatch/src/server.c:322
#26 0x7ff73fa98c1f in thread_run (arg=0x1d70d30) at
/home/mick/dispatch/src/server.c:546
#27 0x003e3dc07ee5 in start_thread () from /lib64/libpthread.so.0
...
}
Let's go up to qd_router_link_name
at /home/mick/dispatch/src/router_agent.c:112
(gdb) print * link
$1 =
{
prev = 0x7ff72800b210,
next = 0x7ff72800b390,
mask_bit = 3,
link_type = QD_LINK_ROUTER,
link_direction = QD_OUTGOING,
owning_addr =
[jira] [Created] (QPID-4518) Unknown qpidd config-file options should prevent startup.
michael j. goulish created QPID-4518: Summary: Unknown qpidd config-file options should prevent startup. Key: QPID-4518 URL: https://issues.apache.org/jira/browse/QPID-4518 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.19 Reporter: michael j. goulish Assignee: michael j. goulish Priority: Minor Mis-spelled config file options are ignored silently. They should cause a warning, and halt startup. -- 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] [Closed] (QPID-4003) qpid-cluster to allow --sasl-mechanism option
[ https://issues.apache.org/jira/browse/QPID-4003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish closed QPID-4003. Resolution: Fixed Fix Version/s: 0.18 qpid-cluster to allow --sasl-mechanism option - Key: QPID-4003 URL: https://issues.apache.org/jira/browse/QPID-4003 Project: Qpid Issue Type: Improvement Components: Python Tools Affects Versions: 0.14 Reporter: Pavel Moravec Priority: Minor Labels: patch Fix For: 0.18 Attachments: qpid-cluster-mechList.patch Original Estimate: 2h Remaining Estimate: 2h Description of problem: qpid-cluster shall have option --sasl-mechanism to select which SASL authentication mechanism it wishes to use. Other qpid tools have it. That makes sense e.g. when more mechanisms are allowed and one wishes to authenticate qpid-cluster via Kerberos. Currently qpid-cluster picks up the most secure method (DIGEST-MD5) that can't be changed. Trivial patch is already proposed. Version-Release number of selected component (if applicable): qpid 0.14 How reproducible: 100% Steps to Reproduce: 1. don't limit auth.mechanisms in /etc/sasl2/qpidd.conf (comment out mech_list there, if present) 2. have auth=yes in a clustered broker 3. Setup Kerberos credentials. 4. Try to run qpid-cluster authenticating via Kerberos. Actual results: There is no option to pick up a mechanism (in our case, GSSAPI). Expected results: Have --sasl-mechanism option available. Additional info: Easy patch proposed. -- 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-4222) qpid-cluster -C ignores credentials provided
[
https://issues.apache.org/jira/browse/QPID-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
michael j. goulish resolved QPID-4222.
--
Resolution: Fixed
qpid-cluster -C ignores credentials provided
Key: QPID-4222
URL: https://issues.apache.org/jira/browse/QPID-4222
Project: Qpid
Issue Type: Bug
Components: Python Tools
Affects Versions: 0.14
Reporter: Pavel Moravec
Priority: Minor
Labels: patch
Attachments: 0001-qpid-cluster-C-ignores-credentials.patch
Original Estimate: 2h
Remaining Estimate: 2h
Description of problem:
qpid-cluster -C shall connect to all brokers of the cluster to gather all
connections to the brokers. However it ignores credentials from broker URL.
So any connection attempt to a broker with authentication fails.
Version-Release number of selected component (if applicable):
any (incl. 0.12)
How reproducible:
100%
Steps to Reproduce:
1. Start clustered broker with authentication enabled (sasl config without
anonymous mechanism)
2. SASL database to have default credentials stored (guest/guest for realm
QPID)
3. Run:
qpid-cluster -C guest/guest@${HOSTNAME}:5672
Actual results:
Traceback (most recent call last):
File /usr/bin/qpid-cluster, line 316, in ?
sys.exit(main())
File /usr/bin/qpid-cluster, line 307, in main
raise Exception(Failed: %s - %s % (e.__class__.__name__, e))
Exception: Failed: ConnectionFailed - (None, 'No acceptable SASL
authentication mechanism available')
Expected results:
list of connections of the cluster to be printed out
Additional info:
Patch to be provided
--
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-4221) qpid-cluster -c does not work
[ https://issues.apache.org/jira/browse/QPID-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish resolved QPID-4221. -- Resolution: Fixed qpid-cluster -c does not work - Key: QPID-4221 URL: https://issues.apache.org/jira/browse/QPID-4221 Project: Qpid Issue Type: Bug Components: Python Tools Affects Versions: 0.14 Reporter: Pavel Moravec Priority: Minor Labels: patch Attachments: 0001-qpid-cluster-c-doesnt-work.patch, qpid-cluster-ipv6.patch Original Estimate: 1h Remaining Estimate: 1h Description of problem: qpid-cluster -c ID shall view client connections to specified member, but it does not work at all. Version-Release number of selected component (if applicable): any How reproducible: 100% Steps to Reproduce: 1. Setup a qpid cluster 2. Run qpid-cluster one_broker_address to discover ID of a broker. Output is something like: $ qpid-cluster localhost:5672 Cluster Name: test Cluster Status: ACTIVE Cluster Size: 2 Members: ID=1.2.3.4:28840 URL=amqp:tcp:1.2.3.4:5672 : ID=1.2.3.5:21260 URL=amqp:tcp:1.2.3.5:5672 $ 3. Query for connections on one node using broker ID from previous output, i.e.: $ qpid-cluster -c 1.2.3.4:28840 localhost:5672 Actual results: Output identical to the one in point 2. is written: Cluster Name: test Cluster Status: ACTIVE Cluster Size: 2 Members: ID=1.2.3.4:28840 URL=amqp:tcp:1.2.3.4:5672 : ID=1.2.3.5:21260 URL=amqp:tcp:1.2.3.5:5672 Expected results: List of connections, i.e. something like: Clients on Member: ID=1.2.3.5:21260: dhcp-1-223:5672-1.2.3.4 dhcp-1-223:5672-1.2.3.5 localhost.localdomain:5672-127.0.0.1 Additional info: Patch attached, trivial omitting of setting up variables at options parsing -- 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-4317) make browse-only x-arg similar to others.
[ https://issues.apache.org/jira/browse/QPID-4317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish reassigned QPID-4317: Assignee: michael j. goulish make browse-only x-arg similar to others. - Key: QPID-4317 URL: https://issues.apache.org/jira/browse/QPID-4317 Project: Qpid Issue Type: Improvement Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish Priority: Minor Make the x-arg string for the new browse-only queue feature qpid.browse-only to be similar to (almost all of) the others. -- 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-4317) make browse-only x-arg similar to others.
michael j. goulish created QPID-4317: Summary: make browse-only x-arg similar to others. Key: QPID-4317 URL: https://issues.apache.org/jira/browse/QPID-4317 Project: Qpid Issue Type: Improvement Components: C++ Broker Reporter: michael j. goulish Priority: Minor Make the x-arg string for the new browse-only queue feature qpid.browse-only to be similar to (almost all of) the others. -- 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-4317) make browse-only x-arg similar to others.
[ https://issues.apache.org/jira/browse/QPID-4317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457797#comment-13457797 ] michael j. goulish commented on QPID-4317: -- done in rev 1387135. make browse-only x-arg similar to others. - Key: QPID-4317 URL: https://issues.apache.org/jira/browse/QPID-4317 Project: Qpid Issue Type: Improvement Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish Priority: Minor Fix For: 0.19 Make the x-arg string for the new browse-only queue feature qpid.browse-only to be similar to (almost all of) the others. -- 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-4317) make browse-only x-arg similar to others.
[ https://issues.apache.org/jira/browse/QPID-4317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish resolved QPID-4317. -- Resolution: Fixed Fix Version/s: 0.19 done in rev 1387135. make browse-only x-arg similar to others. - Key: QPID-4317 URL: https://issues.apache.org/jira/browse/QPID-4317 Project: Qpid Issue Type: Improvement Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish Priority: Minor Fix For: 0.19 Make the x-arg string for the new browse-only queue feature qpid.browse-only to be similar to (almost all of) the others. -- 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-4241) browse-only queues
[ https://issues.apache.org/jira/browse/QPID-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13455959#comment-13455959 ] michael j. goulish commented on QPID-4241: -- implemented in rev 1382991. auto-test checked in -- rev 1384851. browse-only queues -- Key: QPID-4241 URL: https://issues.apache.org/jira/browse/QPID-4241 Project: Qpid Issue Type: New Feature Components: C++ Broker Affects Versions: Future Reporter: michael j. goulish Assignee: michael j. goulish Fix For: 0.19 Some users need browse-only functionality. For example, messages represent the an ongoing history of events, all of which are relevant to newly joining consumers. The messages should remain unconsumed and available to newcomers until they are outdated by time-to-live rules, or the queue is destroyed. -- 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-4241) browse-only queues
[ https://issues.apache.org/jira/browse/QPID-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish resolved QPID-4241. -- Resolution: Fixed Fix Version/s: 0.19 impl in rev 1382991 auto-test in rev 1384851. (oops!) browse-only queues -- Key: QPID-4241 URL: https://issues.apache.org/jira/browse/QPID-4241 Project: Qpid Issue Type: New Feature Components: C++ Broker Affects Versions: Future Reporter: michael j. goulish Assignee: michael j. goulish Fix For: 0.19 Some users need browse-only functionality. For example, messages represent the an ongoing history of events, all of which are relevant to newly joining consumers. The messages should remain unconsumed and available to newcomers until they are outdated by time-to-live rules, or the queue is destroyed. -- 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-4241) browse-only queues
michael j. goulish created QPID-4241: Summary: browse-only queues Key: QPID-4241 URL: https://issues.apache.org/jira/browse/QPID-4241 Project: Qpid Issue Type: New Feature Components: C++ Broker Affects Versions: Future Reporter: michael j. goulish Assignee: michael j. goulish Some users need browse-only functionality. For example, messages represent the an ongoing history of events, all of which are relevant to newly joining consumers. The messages should remain unconsumed and available to newcomers until they are outdated by time-to-live rules, or the queue is destroyed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-4241) browse-only queues
[
https://issues.apache.org/jira/browse/QPID-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13440281#comment-13440281
]
michael j. goulish commented on QPID-4241:
--
Here is the proposed functional specification.
proposed functional specification
{
purpose
{
Some users need browse-only functionality. For example,
messages represent the an ongoing history of events,
all of which are relevant to newly joining consumers.
The messages should remain unconsumed and available to
newcomers until they are outdated by time-to-live rules,
thrown away by a ring-queue, or the queue is destroyed.
}
strategy note
{
ACL and browse-only-queue solutions to this problem are
both possible. But right now we should prefer a
browse-only-queue solution, because
(1) it would satisfy the current customer's requirements, and
(2) the ACL functionality requires a complete overhaul.
}
user interface
{
1. extend x-declare{arguments:{}} in our addressing
to include 'browse-only'.
2. queues that are declared browse-only will allow
subscribers to access queues, and 'acquire' messages
normally -- but that 'acquisition' in this queue would
result in only a browse. The message would remain.
3. no effect on ACLs.
}
testing
{
As user mick, use standard command line tools to:
1. declare a queue with browse-only argument.
2. use standard command line tool to send N
messages to the queue.
3. use standard tool to 'consume' messages from
queue. Confirm that N messages are read.
4. Repeat step 3 at least once, and confirm that
same N messages are again read every time.
( They are not consumed. )
5. Set TTL on messages and confirm that it removes
messages from queue.
6. Confirm same behavior across all queue types.
}
}
browse-only queues
--
Key: QPID-4241
URL: https://issues.apache.org/jira/browse/QPID-4241
Project: Qpid
Issue Type: New Feature
Components: C++ Broker
Affects Versions: Future
Reporter: michael j. goulish
Assignee: michael j. goulish
Some users need browse-only functionality. For example, messages represent
the an ongoing history of events, all of which are relevant to newly joining
consumers. The messages should remain unconsumed and available to newcomers
until they are outdated by time-to-live rules, or the queue is destroyed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-4194) cluster should enable queue events in CATCHUP state
michael j. goulish created QPID-4194: Summary: cluster should enable queue events in CATCHUP state Key: QPID-4194 URL: https://issues.apache.org/jira/browse/QPID-4194 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish pavel moravec has discovered the mechanism for this problem already -- current cluster code does not enable queue events until READY state -- but new messages may be enqueued during CATCHUP state. So if you have a replication-queue, which needs those queue-events to be generated, a newbie broker -- if it is in CATCHUP state -- will fail to replicate any messages that arrive on the replicated queue. Two-line fix -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-4194) cluster should enable queue events in CATCHUP state
[ https://issues.apache.org/jira/browse/QPID-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish resolved QPID-4194. -- Resolution: Fixed Fix Version/s: 0.19 pavel's fix. cluster should enable queue events in CATCHUP state --- Key: QPID-4194 URL: https://issues.apache.org/jira/browse/QPID-4194 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish Labels: cluster, desync Fix For: 0.19 pavel moravec has discovered the mechanism for this problem already -- current cluster code does not enable queue events until READY state -- but new messages may be enqueued during CATCHUP state. So if you have a replication-queue, which needs those queue-events to be generated, a newbie broker -- if it is in CATCHUP state -- will fail to replicate any messages that arrive on the replicated queue. Two-line fix -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3438) cluster auth failure increments cnx count
cluster auth failure increments cnx count - Key: QPID-3438 URL: https://issues.apache.org/jira/browse/QPID-3438 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish Fix For: 0.14 If a cluster brokers are authenticating, and an attempted cnx fails due to an auth problem, the broker nevertheless increments its cnx counter. Which means it eventually runs out of available connections -- even if there aren't any open. :-( -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3397) Add Broker management methods for several queue functions
Add Broker management methods for several queue functions - Key: QPID-3397 URL: https://issues.apache.org/jira/browse/QPID-3397 Project: Qpid Issue Type: Improvement Components: C++ Broker Affects Versions: 0.14 Reporter: michael j. goulish Assignee: michael j. goulish Implement broker management functions to (1) return the ID list of all messages on a queue. (2) retrieve the header of a given message on a given queue (3) retrieve the body of a given message on a given queue (4) remove a given message from a given queue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3398) LegacyLVQ should not impose extra semantics on remove function
LegacyLVQ should not impose extra semantics on remove function -- Key: QPID-3398 URL: https://issues.apache.org/jira/browse/QPID-3398 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish Fix For: 0.14 LegacyLVQ imposes extra semantics on the remove function beyond what its parent MessageMap specifies. It requires the caller to pass in a message with the same payload -- which seems weird. It should instead pass back the message that was deleted, just like its parent. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3340) restore use of testagent to two cluster tests
restore use of testagent to two cluster tests - Key: QPID-3340 URL: https://issues.apache.org/jira/browse/QPID-3340 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.14 Reporter: michael j. goulish Assignee: michael j. goulish Priority: Minor In my checkin for JIRA 3337, two of the cluster tests only worked because I prevented them from using a client called testagent. The tests are cluster_tests.LongTests.test_management_qmf2 cluster_tests.LongTests.test_management . Restore 'testagent' to their list of clients, and fix it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3337) eliminate guest/guest default username/password and use an explicit sasl mechanism list
eliminate guest/guest default username/password and use an explicit sasl mechanism list --- Key: QPID-3337 URL: https://issues.apache.org/jira/browse/QPID-3337 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish Fix For: 0.14 Currently, we default to using the system-default sasl mechanisms list. That list will include GSSAPI if the package is installed on the user's system. But merely installing the GSSAPI package does not prepare qpidd to use GSSAPI. The user must perform specific config steps to make it work. And, since GSSAPI will be selected before other mechanisms, this means that many users will see qpidd fail as soon as they try --auth=yes . It also seems dangerous to allow PLAIN, since users who install qpidd will then have an insecure system by default. By accepting the system-default list we are allowing too many user-surprises. The solution is to explicitly control the mech list, probably only allowing a single mechanism such as DIGEST-MD5, and give the user sufficient instruction on how to set up other mechanisms when they are desired. NOTE -- I am also allowing ANONYMOUS, because some python tools do not yet know how to send credentials, and this will allow them to continue working. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Resolved] (QPID-3337) eliminate guest/guest default username/password and use an explicit sasl mechanism list
[ https://issues.apache.org/jira/browse/QPID-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish resolved QPID-3337. -- Resolution: Fixed checkin 1143536 . eliminate guest/guest default username/password and use an explicit sasl mechanism list --- Key: QPID-3337 URL: https://issues.apache.org/jira/browse/QPID-3337 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish Fix For: 0.14 Currently, we default to using the system-default sasl mechanisms list. That list will include GSSAPI if the package is installed on the user's system. But merely installing the GSSAPI package does not prepare qpidd to use GSSAPI. The user must perform specific config steps to make it work. And, since GSSAPI will be selected before other mechanisms, this means that many users will see qpidd fail as soon as they try --auth=yes . It also seems dangerous to allow PLAIN, since users who install qpidd will then have an insecure system by default. By accepting the system-default list we are allowing too many user-surprises. The solution is to explicitly control the mech list, probably only allowing a single mechanism such as DIGEST-MD5, and give the user sufficient instruction on how to set up other mechanisms when they are desired. NOTE -- I am also allowing ANONYMOUS, because some python tools do not yet know how to send credentials, and this will allow them to continue working. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3262) Remove support for archaic Boost version 103200
Remove support for archaic Boost version 103200 --- Key: QPID-3262 URL: https://issues.apache.org/jira/browse/QPID-3262 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish Priority: Minor Remove support for antique Boost version -- no one wants this any more, and I promised. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3239) sasl_fed_ex tests hangs
sasl_fed_ex tests hangs --- Key: QPID-3239 URL: https://issues.apache.org/jira/browse/QPID-3239 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish the sasl_fed_ex test ( which is the base code for severl tests ) is hanging, because qpid-tool can no longer print the status of links between clustered brokers. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Resolved] (QPID-3239) sasl_fed_ex tests hangs
[ https://issues.apache.org/jira/browse/QPID-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish resolved QPID-3239. -- Resolution: Fixed fixed by checkin 1098704. sasl_fed_ex tests hangs --- Key: QPID-3239 URL: https://issues.apache.org/jira/browse/QPID-3239 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish the sasl_fed_ex test ( which is the base code for severl tests ) is hanging, because qpid-tool can no longer print the status of links between clustered brokers. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3168) C++ Broker: fix the --help text description of flow control thresholds.
[ https://issues.apache.org/jira/browse/QPID-3168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019302#comment-13019302 ] michael j. goulish commented on QPID-3168: -- The change clarifies the text and introduces zero risk. Nihil Obstat. Imprimatur. C++ Broker: fix the --help text description of flow control thresholds. - Key: QPID-3168 URL: https://issues.apache.org/jira/browse/QPID-3168 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.10 Reporter: Ken Giusti Assignee: Ken Giusti Priority: Minor Fix For: 0.11 The following text is incorrect: --default-flow-stop-threshold %MESSAGES (80) Queue capacity level at which flow control is activated. --default-flow-resume-threshold %MESSAGES (70) Queue capacity level at which flow control is de-activated. Correction: --default-flow-stop-threshold PERCENT (80) Percent of queue's maximum capacity at which flow control is activated. --default-flow-resume-threshold PERCENT (70) Percent of queue's maximum capacity at which flow control is de-activated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3188) CyrusSasl ctor logic change for callback storage
CyrusSasl ctor logic change for callback storage Key: QPID-3188 URL: https://issues.apache.org/jira/browse/QPID-3188 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client Reporter: michael j. goulish Assignee: michael j. goulish The logic that stores callbacks in the CyrusSasl ctor should be changed to make the c++ client behave similarly to other language clients. If there is no username, then do nothing with either NAME or PASSWD callbacks. If there is a name but no passwd, then explicitly store an empty PASSWD callback. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3174) broker crash using rdma+sasl
broker crash using rdma+sasl
Key: QPID-3174
URL: https://issues.apache.org/jira/browse/QPID-3174
Project: Qpid
Issue Type: Bug
Components: C++ Broker
Reporter: michael j. goulish
This is sometimes very hard to observe. I was lucky enough to see it three
times in the space of 500 iterations yesterday, but now, with same code
scripts system, I have no repetition after 6000 iterations.
my tree rev number is 1084895
Here is the backtrace -- all 3 have been identical:
#0 0x003f8d030265 in raise (sig=value optimized out)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x003f8d031d10 in abort () at abort.c:88
#2 0x003f8d0296e6 in __assert_fail (
assertion=0x2b28f90400aa completionsNeeded.get() 0,
file=0x2b28f903fe58 ./qpid/broker/AsyncCompletion.h, line=167,
function=0x2b28f9040440 void
qpid::broker::AsyncCompletion::end(qpid::broker::AsyncCompletion::Callback))
at assert.c:78
#3 0x2b28f8fe2935 in qpid::broker::AsyncCompletion::end
(this=0x2aaab60c2e50,
cb=value optimized out) at ./qpid/broker/AsyncCompletion.h:167
#4 0x2b28f8fdf3f3 in qpid::broker::SessionState::handleContent (
this=0x2aaabc4157d0, frame=..., id=value optimized out)
at qpid/broker/SessionState.cpp:265
#5 0x2b28f8fdf830 in qpid::broker::SessionState::handleIn
(this=0x2aaabc4157d0,
frame=...) at qpid/broker/SessionState.cpp:355
#6 0x2b28f94799dc in qpid::amqp_0_10::SessionHandler::handleIn (
this=0x2aaab0025680, f=...) at qpid/amqp_0_10/SessionHandler.cpp:93
#7 0x2b28f8f2622b in operator() (this=0x2aaab38cffa0, frame=...)
at ./qpid/framing/Handler.h:42
#8 qpid::broker::Connection::received (this=0x2aaab38cffa0, frame=...)
at qpid/broker/Connection.cpp:164
#9 0x2b28f8ef8300 in qpid::amqp_0_10::Connection::decode
(this=0x2aaabc47d240,
buffer=value optimized out, size=value optimized out)
at qpid/amqp_0_10/Connection.cpp:58
#10 0x2b28f94c25e5 in qpid::sys::cyrus::CyrusSecurityLayer::decode (
this=0x2aaabc468480, input=0x2aaab2aa97d0 , size=118)
at qpid/sys/cyrus/CyrusSecurityLayer.cpp:59
#11 0x2b28f999c7d8 in qpid::sys::RdmaIOHandler::readbuff
(this=0x2aaab002d9e0,
buff=0x) at qpid/sys/RdmaIOPlugin.cpp:218
#12 0x2b28f9bba75a in boost::function2void, Rdma::AsynchIO,
Rdma::Buffer*, std::allocatorboost::function_base ::operator() (this=0x0,
a0=..., a1=0x6)
here is my broker start script:
-- start script ---
#! /bin/bash
export LD_LIBRARY_PATH=$TRUNK/qpid/cpp/src/.libs
QPID_SRC=$TRUNK/qpid/cpp/src
QPIDD=${QPID_SRC}/.libs/qpidd
echo $QPIDD
rm -rf /tmp/mick
mkdir /tmp/mick
$QPIDD\
--no-module-dir \
--load-module ${QPID_SRC}/.libs/rdma.so \
--data-dir /tmp/mick/data_1 \
--auth=yes \
--mgmt-enable=yes \
--port 5813 \
--log-enable info+ \
--log-to-file /tmp/mick/qpidd_1.log \
--log-source yes\
--sasl-config=${QPID_SRC}/tests/sasl_config \
-d
echo started broker from $QPIDD
--- end script
and here is my client iterator script;
-- start script -
#! /bin/bash
rm core.* ~/.qpidd/core*
count=0
while [ $count -lt 1 ]
do
echo ===
echo TEST $count
echo ===
sleep 1
core_files=`ls -l core.* ~/.qpidd/core* | wc -l`
echo core files: ${core_files}
if [ ${core_files} -gt 0 ]; then
echo core files found!
exit 1
else
echo no core files found.
fi
./qpid-perftest --username zig --password zig --protocol rdma --broker
20.0.40.14 --port 5813 --qt 4 --count 10
count=$(( $count + 1 ))
done
-- end script ---
the sasl config directory that the broker is pointing at was created by the
script cpp/src/tests/sasl_test_setup.sh
also, you need to set ulimit -l 131072(at least that value) before
starting the broker.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3171) RDMA client can segfault if no SASL mech specified.
RDMA client can segfault if no SASL mech specified.
Key: QPID-3171
URL: https://issues.apache.org/jira/browse/QPID-3171
Project: Qpid
Issue Type: Bug
Components: C++ Client
Reporter: michael j. goulish
Assignee: michael j. goulish
Using the following scripts to start the broker and to run a perftest client (
using RDMA ) I get a client segv about 3% of the time.
broker start script:
#! /bin/bash
export LD_LIBRARY_PATH=$TRUNK/qpid/cpp/src/.libs
QPID_SRC=$TRUNK/qpid/cpp/src
QPIDD=${QPID_SRC}/.libs/qpidd
echo $QPIDD
rm -rf /tmp/mick
mkdir /tmp/mick
$QPIDD\
--no-module-dir \
--load-module ${QPID_SRC}/.libs/rdma.so \
--data-dir /tmp/mick/data_1 \
--auth=yes \
--mgmt-enable=yes \
--port 5813 \
--log-enable info+ \
--log-to-file /tmp/mick/qpidd_1.log \
--log-source yes\
--sasl-config=${QPID_SRC}/tests/sasl_config \
-d
echo started broker from $QPIDD
client run script:
#! /bin/bash
rm core.*
count=0
while [ $count -lt 1 ]
do
echo ===
echo TEST $count
echo ===
core_files=`ls -l core.* | wc -l`
echo core files: ${core_files}
if [ ${core_files} -gt 0 ]; then
echo core files found!
exit 1
else
echo no core files found.
fi
./qpid-perftest --username zig --password zig --protocol rdma --broker
20.0.40.14 --port 5813 --qt 4 --count 10
count=$(( $count + 1 ))
done
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Resolved] (QPID-3171) RDMA client can segfault if no SASL mech specified.
[
https://issues.apache.org/jira/browse/QPID-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
michael j. goulish resolved QPID-3171.
--
Resolution: Fixed
fixed by revision 1087047
RDMA client can segfault if no SASL mech specified.
Key: QPID-3171
URL: https://issues.apache.org/jira/browse/QPID-3171
Project: Qpid
Issue Type: Bug
Components: C++ Client
Reporter: michael j. goulish
Assignee: michael j. goulish
Using the following scripts to start the broker and to run a perftest client
( using RDMA ) I get a client segv about 3% of the time.
broker start script:
#! /bin/bash
export LD_LIBRARY_PATH=$TRUNK/qpid/cpp/src/.libs
QPID_SRC=$TRUNK/qpid/cpp/src
QPIDD=${QPID_SRC}/.libs/qpidd
echo $QPIDD
rm -rf /tmp/mick
mkdir /tmp/mick
$QPIDD\
--no-module-dir \
--load-module ${QPID_SRC}/.libs/rdma.so \
--data-dir /tmp/mick/data_1 \
--auth=yes \
--mgmt-enable=yes \
--port 5813 \
--log-enable info+ \
--log-to-file /tmp/mick/qpidd_1.log \
--log-source yes\
--sasl-config=${QPID_SRC}/tests/sasl_config \
-d
echo started broker from $QPIDD
client run script:
#! /bin/bash
rm core.*
count=0
while [ $count -lt 1 ]
do
echo ===
echo TEST $count
echo ===
core_files=`ls -l core.* | wc -l`
echo core files: ${core_files}
if [ ${core_files} -gt 0 ]; then
echo core files found!
exit 1
else
echo no core files found.
fi
./qpid-perftest --username zig --password zig --protocol rdma --broker
20.0.40.14 --port 5813 --qt 4 --count 10
count=$(( $count + 1 ))
done
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3147) Misconfigured tracing/logging can lead to hung threads in logging stack
[ https://issues.apache.org/jira/browse/QPID-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009267#comment-13009267 ] michael j. goulish commented on QPID-3147: -- nice fix. seems like zero risk. nihil obstat. imprimatur. Misconfigured tracing/logging can lead to hung threads in logging stack --- Key: QPID-3147 URL: https://issues.apache.org/jira/browse/QPID-3147 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.10 Environment: Fedora 14 32-bit Reporter: Pete MacKinnon Assignee: Alan Conway Priority: Minor Labels: c++, logging, qpid, thread, trace Given the following trace and logging environment variable mix-up like this: QPID_TRACE=debug+ QPID_LOG_ENABLE= A C++ client that embeds the Qpid runtime can get hung although it has recognized the misconfiguration. #0 0x00555416 in __kernel_vsyscall () #1 0x00f49367 in syscall () at ../sysdeps/unix/sysv/linux/i386/syscall.S:30 #2 0x002bbfca in __cxxabiv1::__cxa_guard_acquire (g=0x2171ea0) at ../../../../libstdc++-v3/libsupc++/guard.cc:293 #3 0x020ca3b8 in instance () at /usr/include/boost/pool/detail/singleton.hpp:83 #4 qpid::log::Logger::instance () at qpid/log/Logger.cpp:47 #5 0x020cd324 in qpid::log::Statement::Initializer::Initializer ( this=0x2171b88, s=...) at qpid/log/Statement.cpp:61 #6 0x02075b6c in qpid::Exception::Exception (this=0x880b370, msg= Error in environment variables: in option 'trace': invalid bool value\n) at qpid/Exception.cpp:31 #7 0x0208095d in Exception (this=0xbf8d0df0, argc=0, argv=0x0, configFile=, allowUnknown=false) at ../include/qpid/Options.h:210 #8 qpid::Options::parse (this=0xbf8d0df0, argc=0, argv=0x0, configFile=, allowUnknown=false) at qpid/Options.cpp:352 #9 0x020c9c57 in qpid::log::Logger::Logger (this=0x2171ec0) at qpid/log/Logger.cpp:55 #10 0x020ca330 in instance () at /usr/include/boost/pool/detail/singleton.hpp:83 #11 object_creator () at /usr/include/boost/pool/detail/singleton.hpp:66 #12 __static_initialization_and_destruction_0 () at /usr/include/boost/pool/detail/singleton.hpp:95 #13 global constructors keyed to Logger.cpp(void) () at qpid/log/Logger.cpp:156 #14 0x020ebc6d in __do_global_ctors_aux () from /usr/lib/libqpidcommon.so.2 #15 0x01fc2a84 in _init () from /usr/lib/libqpidcommon.so.2 #16 0x004f68fc in call_init (l=value optimized out, argc=3, argv=0xbf8d1634, env=0x87feb58) at dl-init.c:68 #17 0x004f6a19 in _dl_init (main_map=value optimized out, argc=3, argv=0xbf8d1634, env=0x87feb58) at dl-init.c:132 #18 0x004fa74f in dl_open_worker (a=0xbf8d10d0) at dl-open.c:464 #19 0x004f6786 in _dl_catch_error (objname=0xbf8d10f8, errstring=0xbf8d10f4, mallocedp=0xbf8d10ff, operate=0x4fa3b0 dl_open_worker, args=0xbf8d10d0) at dl-error.c:178 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-3154) Fix qpidd late/overran warnings.
[ https://issues.apache.org/jira/browse/QPID-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13008591#comment-13008591 ] michael j. goulish commented on QPID-3154: -- This looks reasonable to me (after Alan explained a little more) and zero risk. Fix qpidd late/overran warnings. Key: QPID-3154 URL: https://issues.apache.org/jira/browse/QPID-3154 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.9 Reporter: Alan Conway Assignee: Alan Conway Priority: Minor Fix For: 0.10 Warnings for late-and-overrun tasks were not being correctly reported. They were reported with 0 values. Lateness for overrun tasks below the late threshold was not being reported. This leads to reports of e.g. overran by 3ms, with no indication of lateness when in fact the event was overrun _and_ late by 3ms. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-3150) sasl_fed test fails to specify client's sasl mechanism
sasl_fed test fails to specify client's sasl mechanism -- Key: QPID-3150 URL: https://issues.apache.org/jira/browse/QPID-3150 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish Priority: Minor this is a problem with the test in cpp/src/tests/sasl_fed -- not with the broker. the client should use DIGEST-MD5 when connecting to the broker -- but this is not specified on the command line. It was succeeding accidentally on some systems but, recently, not on others. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-3152) non-clustered sasl_fed_ex_* tests load cluster.so
non-clustered sasl_fed_ex_* tests load cluster.so - Key: QPID-3152 URL: https://issues.apache.org/jira/browse/QPID-3152 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish The 4 non-clustered versions of the sasl_fed_ex_* tests load cluster.so in the broker command line (and fail when it isn't present). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-3152) non-clustered sasl_fed_ex_* tests load cluster.so
[ https://issues.apache.org/jira/browse/QPID-3152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish resolved QPID-3152. -- Resolution: Fixed Fix Version/s: 0.10 Assignee: michael j. goulish fixed by rev 1082804 non-clustered sasl_fed_ex_* tests load cluster.so - Key: QPID-3152 URL: https://issues.apache.org/jira/browse/QPID-3152 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish Fix For: 0.10 The 4 non-clustered versions of the sasl_fed_ex_* tests load cluster.so in the broker command line (and fail when it isn't present). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-3150) sasl_fed test fails to specify client's sasl mechanism
[ https://issues.apache.org/jira/browse/QPID-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish resolved QPID-3150. -- Resolution: Fixed Fix Version/s: 0.10 fixed by 1082685. sasl_fed test fails to specify client's sasl mechanism -- Key: QPID-3150 URL: https://issues.apache.org/jira/browse/QPID-3150 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish Priority: Minor Fix For: 0.10 this is a problem with the test in cpp/src/tests/sasl_fed -- not with the broker. the client should use DIGEST-MD5 when connecting to the broker -- but this is not specified on the command line. It was succeeding accidentally on some systems but, recently, not on others. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-3153) sasl_fed_ex_*_cluster tests should test for aisexec running
sasl_fed_ex_*_cluster tests should test for aisexec running --- Key: QPID-3153 URL: https://issues.apache.org/jira/browse/QPID-3153 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish use ais_exec to make sure that aisexec is actually running. also use with_ais_group to force proper group membership for openais. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-3153) sasl_fed_ex_*_cluster tests should test for aisexec running
[ https://issues.apache.org/jira/browse/QPID-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish resolved QPID-3153. -- Resolution: Fixed Fix Version/s: 0.11 fixed by rev 1082812. sasl_fed_ex_*_cluster tests should test for aisexec running --- Key: QPID-3153 URL: https://issues.apache.org/jira/browse/QPID-3153 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish Fix For: 0.11 use ais_exec to make sure that aisexec is actually running. also use with_ais_group to force proper group membership for openais. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-3144) qpidd --check does not work with info logging and --log-to-stdout=yes
[ https://issues.apache.org/jira/browse/QPID-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13007476#comment-13007476 ] michael j. goulish commented on QPID-3144: -- good point about the inappropriate position of these log statements in any case. and especially because of teensyness of change -- i withdraw my objection. nihil obstat. imprimatur. qpidd --check does not work with info logging and --log-to-stdout=yes - Key: QPID-3144 URL: https://issues.apache.org/jira/browse/QPID-3144 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.9 Reporter: Alan Conway Assignee: Alan Conway Priority: Minor Fix For: 0.10 qpidd --check is supposed to print the PID of a running qpidd --daemon, for use in scripts and the like. However with info logging and log-to-stdout enabled this does not work because log messages of the form: 2011-03-14 16:21:05 info Loaded Module: /usr/lib64/qpid/daemon/cluster.so precede the port number. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-3144) qpidd --check does not work with info logging and --log-to-stdout=yes
[ https://issues.apache.org/jira/browse/QPID-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13007042#comment-13007042 ] michael j. goulish commented on QPID-3144: -- Fixing this in the code seems too heavy-handed. Also, the log message that is getting in the way is presumably useful in other contexts. Wouldn't it be better to simply do something like the following in the affected scripts? my_pid=`qpidd --check | grep -v Loaded` I would propose that we leave this small change out. qpidd --check does not work with info logging and --log-to-stdout=yes - Key: QPID-3144 URL: https://issues.apache.org/jira/browse/QPID-3144 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.9 Reporter: Alan Conway Assignee: Alan Conway Priority: Minor Fix For: 0.10 qpidd --check is supposed to print the PID of a running qpidd --daemon, for use in scripts and the like. However with info logging and log-to-stdout enabled this does not work because log messages of the form: 2011-03-14 16:21:05 info Loaded Module: /usr/lib64/qpid/daemon/cluster.so precede the port number. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2057) qpidd --require-encryption forces SASL security layer to be used even if SSL is in use
[ https://issues.apache.org/jira/browse/QPID-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-2057: - Fix Version/s: 0.11 qpidd --require-encryption forces SASL security layer to be used even if SSL is in use -- Key: QPID-2057 URL: https://issues.apache.org/jira/browse/QPID-2057 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.5 Reporter: Ted Ross Assignee: michael j. goulish Priority: Minor Fix For: 0.11 If running SSL and using GSSAPI authentication with the --require-encryption option turned on, the SASL layer will force minSsf to be greater than zero, thus causing the SASL security layer to encrypt. This is unnecessary double-encryption since SSL is already providing a cipher channel at a lower layer. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2993) Federated source-local links crash remotely federated cluster member on local cluster startup
[ https://issues.apache.org/jira/browse/QPID-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-2993: - Fix Version/s: 0.11 Federated source-local links crash remotely federated cluster member on local cluster startup - Key: QPID-2993 URL: https://issues.apache.org/jira/browse/QPID-2993 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Clustering Affects Versions: 0.8 Environment: Debian Linux Squeeze, 32-bit, kernel 2.6.36.2, Dell Poweredge 1950s. Corosync==1.3.0, Openais==1.1.4 Reporter: Mark Moseley Assignee: michael j. goulish Fix For: 0.11 Attachments: 2993_bug.sh, cluster-fed-src.sh This is related to JIRA 2992 that I opened, but this is for source-local routes. Given the same setup as in JIRA 2992 but using source-local routes (and obviously with the exchanges switched accordingly in the qpid-route statements), i.e. cluster A and cluster B with the routes between A1-B1, when cluster B shuts down in the order B2-B1 and starts back up, the static routes are not correctly re-bound on cluster A's side. However if cluster B is shut down in the order B1-B2 and started back up, the route is correctly created and works. However in the non-functioning case (B2-B1, or A2-A1), there is an additional side-effect: on node A2, qpidd crashes with the following error (cluster A is called 'walclust', B is bosclust): 2011-01-07 18:57:35 error Channel exception: not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) 2011-01-07 18:57:35 critical cluster(102.0.0.0:13650 READY/error) local error 2030 did not occur on member 101.0.0.0:9920: not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) 2011-01-07 18:57:35 critical Error delivering frames: local error did not occur on all cluster members : not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) (qpid/cluster/ErrorCheck.cpp:89) 2011-01-07 18:57:35 notice cluster(102.0.0.0:13650 LEFT/error) leaving cluster walclust 2011-01-07 18:57:35 notice Shut down This happens on both sides of the cluster, so it's not limited to one or the other. This crash does *not* occur in the A1-A2/B1-B2 test (i.e. the test where the route is re-bound correctly). I can cause this to reoccur pretty much every time. I've been resetting the cluster completely to a new state between each test. Occasionally in the B2-B1 test, A1 will also crash with the same error (and vice versa for A2-A1 for node B1), though most of the time, it's A2/B2 that crashes. I was getting this same behaviour prior to upgrading corosync/openais as well. Previously I was using the stock Squeeze versions of corosync==1.2.1 and openais==1.1.2. The results are the same with corosync=1.3.0 and openais==1.1.4. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-3123) disallow federation links between members of a cluster
disallow federation links between members of a cluster -- Key: QPID-3123 URL: https://issues.apache.org/jira/browse/QPID-3123 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish Priority: Minor Attempts to create a federation link between two brokers that are members of the same cluster should be disallowed. Otherwise messages delivered to one end of the link are double-delivered to members of the cluster. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-3117) qpidd --help output on --sasl-config is misleading
qpidd --help output on --sasl-config is misleading -- Key: QPID-3117 URL: https://issues.apache.org/jira/browse/QPID-3117 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish Priority: Minor The --help output suggest that --sasl-config points to a file. But it points to a directory. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-3096) remove qrsh from cpp/src/tests
remove qrsh from cpp/src/tests -- Key: QPID-3096 URL: https://issues.apache.org/jira/browse/QPID-3096 Project: Qpid Issue Type: Improvement Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish Priority: Minor The qrsh material represents an experiment that was never used, in fact never quite completed. It should be removed. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Closed: (QPID-2617) make sasl-based tests config files relocatable
[ https://issues.apache.org/jira/browse/QPID-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish closed QPID-2617. implemented, and then secondary problems fixed, in the following svn revs: 947748 947764 947850 947994 make sasl-based tests config files relocatable -- Key: QPID-2617 URL: https://issues.apache.org/jira/browse/QPID-2617 Project: Qpid Issue Type: Improvement Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish Currently, sasl-based testing is hampered by the fact that the sasl library code is only reading its configuration information from the standard installed location /etc/sasl2 . This means that sasl installation must be done manually on a machine prior to running sasl-based tests, which makes them not fully automatable. 1. Find a way of telling the library to look elsewhere 2. expose that mechanism through a broker option 3. check a suitable config file into our source tree, at cpp/src/tests 4. reference the locally-created sasldb from the new config file 5. the new sasl tests should be runnable by any users -- not just root. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2617) make sasl-based tests config files relocatable
[ https://issues.apache.org/jira/browse/QPID-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13000917#comment-13000917 ] michael j. goulish commented on QPID-2617: -- Implemented, and then secondary problems fixed, in the following svn versions: 947748 947764 947850 947994 make sasl-based tests config files relocatable -- Key: QPID-2617 URL: https://issues.apache.org/jira/browse/QPID-2617 Project: Qpid Issue Type: Improvement Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish Currently, sasl-based testing is hampered by the fact that the sasl library code is only reading its configuration information from the standard installed location /etc/sasl2 . This means that sasl installation must be done manually on a machine prior to running sasl-based tests, which makes them not fully automatable. 1. Find a way of telling the library to look elsewhere 2. expose that mechanism through a broker option 3. check a suitable config file into our source tree, at cpp/src/tests 4. reference the locally-created sasldb from the new config file 5. the new sasl tests should be runnable by any users -- not just root. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-3096) remove qrsh from cpp/src/tests
[ https://issues.apache.org/jira/browse/QPID-3096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish resolved QPID-3096. -- Resolution: Fixed fixed in rev 1075874 remove qrsh from cpp/src/tests -- Key: QPID-3096 URL: https://issues.apache.org/jira/browse/QPID-3096 Project: Qpid Issue Type: Improvement Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish Priority: Minor The qrsh material represents an experiment that was never used, in fact never quite completed. It should be removed. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-2057) qpidd --require-encryption forces SASL security layer to be used even if SSL is in use
[ https://issues.apache.org/jira/browse/QPID-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish reassigned QPID-2057: Assignee: michael j. goulish qpidd --require-encryption forces SASL security layer to be used even if SSL is in use -- Key: QPID-2057 URL: https://issues.apache.org/jira/browse/QPID-2057 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.5 Reporter: Ted Ross Assignee: michael j. goulish Priority: Minor If running SSL and using GSSAPI authentication with the --require-encryption option turned on, the SASL layer will force minSsf to be greater than zero, thus causing the SASL security layer to encrypt. This is unnecessary double-encryption since SSL is already providing a cipher channel at a lower layer. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2993) Federated source-local links crash remotely federated cluster member on local cluster startup
[ https://issues.apache.org/jira/browse/QPID-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-2993: - Attachment: 2993_bug.sh Federated source-local links crash remotely federated cluster member on local cluster startup - Key: QPID-2993 URL: https://issues.apache.org/jira/browse/QPID-2993 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Clustering Affects Versions: 0.8 Environment: Debian Linux Squeeze, 32-bit, kernel 2.6.36.2, Dell Poweredge 1950s. Corosync==1.3.0, Openais==1.1.4 Reporter: Mark Moseley Assignee: michael j. goulish Attachments: 2993_bug.sh, cluster-fed-src.sh This is related to JIRA 2992 that I opened, but this is for source-local routes. Given the same setup as in JIRA 2992 but using source-local routes (and obviously with the exchanges switched accordingly in the qpid-route statements), i.e. cluster A and cluster B with the routes between A1-B1, when cluster B shuts down in the order B2-B1 and starts back up, the static routes are not correctly re-bound on cluster A's side. However if cluster B is shut down in the order B1-B2 and started back up, the route is correctly created and works. However in the non-functioning case (B2-B1, or A2-A1), there is an additional side-effect: on node A2, qpidd crashes with the following error (cluster A is called 'walclust', B is bosclust): 2011-01-07 18:57:35 error Channel exception: not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) 2011-01-07 18:57:35 critical cluster(102.0.0.0:13650 READY/error) local error 2030 did not occur on member 101.0.0.0:9920: not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) 2011-01-07 18:57:35 critical Error delivering frames: local error did not occur on all cluster members : not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) (qpid/cluster/ErrorCheck.cpp:89) 2011-01-07 18:57:35 notice cluster(102.0.0.0:13650 LEFT/error) leaving cluster walclust 2011-01-07 18:57:35 notice Shut down This happens on both sides of the cluster, so it's not limited to one or the other. This crash does *not* occur in the A1-A2/B1-B2 test (i.e. the test where the route is re-bound correctly). I can cause this to reoccur pretty much every time. I've been resetting the cluster completely to a new state between each test. Occasionally in the B2-B1 test, A1 will also crash with the same error (and vice versa for A2-A1 for node B1), though most of the time, it's A2/B2 that crashes. I was getting this same behaviour prior to upgrading corosync/openais as well. Previously I was using the stock Squeeze versions of corosync==1.2.1 and openais==1.1.2. The results are the same with corosync=1.3.0 and openais==1.1.4. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Issue Comment Edited: (QPID-2993) Federated source-local links crash remotely federated cluster member on local cluster startup
[ https://issues.apache.org/jira/browse/QPID-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12995336#comment-12995336 ] michael j. goulish edited comment on QPID-2993 at 2/16/11 3:23 PM: --- Well, with the latest code tree ( r1071018 ) I do indeed find something interesting. I cannot get it to actually crash, but with the attached script ( 2993_bug.sh ) running on a fast 8-proc system, I was able to see 2 out of 10 instances of broker A2 failing to start up, and logging the following error: 2011-02-16 09:34:23 error Channel exception: not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) 2011-02-16 09:34:23 critical cluster(20.0.100.36:11855 READY/error) local error 1498 did not occur on member 20.0.100.36:11714: not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) 2011-02-16 09:34:23 critical Error delivering frames: local error did not occur on all cluster members : not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) (qpid/cluster/ErrorCheck.cpp:89) 2011-02-16 09:34:23 notice cluster(20.0.100.36:11855 LEFT/error) leaving cluster A 2011-02-16 09:34:23 notice Shut down === and, by the way, the store version is 4439 was (Author: mgoulish2): Well, with the latest code tree ( r1071018 ) I do indeed find something interesting. I cannot get it to actually crash, but with the attached script ( 2993_bug.sh ) running on a fast 8-proc system, I was able to see 2 out of 10 instances of broker A2 failing to start up, and logging the following error: 2011-02-16 09:34:23 error Channel exception: not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) 2011-02-16 09:34:23 critical cluster(20.0.100.36:11855 READY/error) local error 1498 did not occur on member 20.0.100.36:11714: not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) 2011-02-16 09:34:23 critical Error delivering frames: local error did not occur on all cluster members : not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) (qpid/cluster/ErrorCheck.cpp:89) 2011-02-16 09:34:23 notice cluster(20.0.100.36:11855 LEFT/error) leaving cluster A 2011-02-16 09:34:23 notice Shut down Federated source-local links crash remotely federated cluster member on local cluster startup - Key: QPID-2993 URL: https://issues.apache.org/jira/browse/QPID-2993 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Clustering Affects Versions: 0.8 Environment: Debian Linux Squeeze, 32-bit, kernel 2.6.36.2, Dell Poweredge 1950s. Corosync==1.3.0, Openais==1.1.4 Reporter: Mark Moseley Assignee: michael j. goulish Attachments: 2993_bug.sh, cluster-fed-src.sh This is related to JIRA 2992 that I opened, but this is for source-local routes. Given the same setup as in JIRA 2992 but using source-local routes (and obviously with the exchanges switched accordingly in the qpid-route statements), i.e. cluster A and cluster B with the routes between A1-B1, when cluster B shuts down in the order B2-B1 and starts back up, the static routes are not correctly re-bound on cluster A's side. However if cluster B is shut down in the order B1-B2 and started back up, the route is correctly created and works. However in the non-functioning case (B2-B1, or A2-A1), there is an additional side-effect: on node A2, qpidd crashes with the following error (cluster A is called 'walclust', B is bosclust): 2011-01-07 18:57:35 error Channel exception: not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) 2011-01-07 18:57:35 critical cluster(102.0.0.0:13650 READY/error) local error 2030 did not occur on member 101.0.0.0:9920: not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) 2011-01-07 18:57:35 critical Error delivering frames: local error did not occur on all cluster members : not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) (qpid/cluster/ErrorCheck.cpp:89) 2011-01-07 18:57:35 notice cluster(102.0.0.0:13650 LEFT/error) leaving cluster walclust 2011-01-07 18:57:35 notice Shut down This happens on both sides of the cluster, so it's not limited to one or the other. This crash does *not* occur in the A1-A2/B1-B2 test (i.e. the test where the route is re-bound correctly). I can cause this to reoccur pretty much every time. I've been resetting the cluster completely to a new state between each test. Occasionally in the B2-B1 test, A1 will also crash with the same error (and vice versa for
[jira] Commented: (QPID-2993) Federated source-local links crash remotely federated cluster member on local cluster startup
[ https://issues.apache.org/jira/browse/QPID-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991588#comment-12991588 ] michael j. goulish commented on QPID-2993: -- I was not able to repro the crash, using the code tree from 10 Jan, after 100 iterations.I will try again with latest code tree. Federated source-local links crash remotely federated cluster member on local cluster startup - Key: QPID-2993 URL: https://issues.apache.org/jira/browse/QPID-2993 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Clustering Affects Versions: 0.8 Environment: Debian Linux Squeeze, 32-bit, kernel 2.6.36.2, Dell Poweredge 1950s. Corosync==1.3.0, Openais==1.1.4 Reporter: Mark Moseley Assignee: michael j. goulish Attachments: cluster-fed-src.sh This is related to JIRA 2992 that I opened, but this is for source-local routes. Given the same setup as in JIRA 2992 but using source-local routes (and obviously with the exchanges switched accordingly in the qpid-route statements), i.e. cluster A and cluster B with the routes between A1-B1, when cluster B shuts down in the order B2-B1 and starts back up, the static routes are not correctly re-bound on cluster A's side. However if cluster B is shut down in the order B1-B2 and started back up, the route is correctly created and works. However in the non-functioning case (B2-B1, or A2-A1), there is an additional side-effect: on node A2, qpidd crashes with the following error (cluster A is called 'walclust', B is bosclust): 2011-01-07 18:57:35 error Channel exception: not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) 2011-01-07 18:57:35 critical cluster(102.0.0.0:13650 READY/error) local error 2030 did not occur on member 101.0.0.0:9920: not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) 2011-01-07 18:57:35 critical Error delivering frames: local error did not occur on all cluster members : not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) (qpid/cluster/ErrorCheck.cpp:89) 2011-01-07 18:57:35 notice cluster(102.0.0.0:13650 LEFT/error) leaving cluster walclust 2011-01-07 18:57:35 notice Shut down This happens on both sides of the cluster, so it's not limited to one or the other. This crash does *not* occur in the A1-A2/B1-B2 test (i.e. the test where the route is re-bound correctly). I can cause this to reoccur pretty much every time. I've been resetting the cluster completely to a new state between each test. Occasionally in the B2-B1 test, A1 will also crash with the same error (and vice versa for A2-A1 for node B1), though most of the time, it's A2/B2 that crashes. I was getting this same behaviour prior to upgrading corosync/openais as well. Previously I was using the stock Squeeze versions of corosync==1.2.1 and openais==1.1.2. The results are the same with corosync=1.3.0 and openais==1.1.4. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2992) Cluster failing to resurrect durable static route depending on order of shutdown
[ https://issues.apache.org/jira/browse/QPID-2992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12990165#comment-12990165 ] michael j. goulish commented on QPID-2992: -- Using modifications of Ken's script, I have reproduced two bad behaviors, including the one that Mark is reporting. I don't think this is a bug... well, sort of. Two, actually. I will submit a doc bug, and probably one enhancement request. What's happening is this: messaging systems that include clusters and stores are sensitive to timing issues around events like broker introduction and shut-down. Here are the timing issues that I know of: 1. When you shut down a cluster that is using a store, there must be time for the last-broker-standing to realize his status, and mark his store as clean. I.e. my store is the one we should use at re-start. If all brokers are killed too quickly, this will not happen. The cluster will not be able to restart because it will not find any store that has been marked clean. 2. When you make a topology change, i.e. adding a route from one cluster to another to create a federation-of- clusters, if you then shut down the cluster soon afterwards you may get it before that topology-change has had a chance to propagate across the cluster. This can cause a problem on re-start that depends on the order in which the brokers are killed. If you *first* kill the broker that knew about the topology change before he manages to communicate that knowledge to the other broker, that's Bad. because the other broker will be the last-man- standing, and it will be *his* store that gets marked as clean! So his store will be re-used at startup, and the cluster will have lost knowledge of the topology change. By altering the timing of events in Ken's script, I was able to: A. get no failures in 200 runs. (original script, plus explicit wait-loops fro brokers.) B. get 100% failure because of no clean store. (kill both brokers in B cluster too close together.) C. get the failure that Mark reported, about 7% of the time. ( place B1 under load, then kill it too soon after route- creation. ) So, here's what I will propose... I. A bit of documentation ( I will take first sketch-whack at it, then give to doc professionals) to centralize description of this type of problem -- the two I have mentioned above, plus whatever anyone else thinks up that is similar. This will include best-practices on how to avoid this type of problem. II. A request for enhancement wherever there is no very good way to avoid one of these multi-broker race conditions. III. III'll come back and update this Jira with the numbers of any resultant Jiras that I open. Cluster failing to resurrect durable static route depending on order of shutdown Key: QPID-2992 URL: https://issues.apache.org/jira/browse/QPID-2992 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Clustering Affects Versions: 0.8 Environment: Debian Linux Squeeze, 32-bit, kernel 2.6.36.2, Dell Poweredge 1950s. Corosync==1.3.0, Openais==1.1.4 Reporter: Mark Moseley Assignee: michael j. goulish Attachments: cluster-fed.sh, error I've got a 2-node qpid test cluster at each of 2 datacenters, which are federated together with a single durable static route between each. Qpid is version 0.8. Corosync and openais are stock Squeeze (1.2.1-3 and 1.1.2-2, respectively). OS is Squeeze, 32-bit, on Dell Poweredge 1950s, kernel 2.6.36. The static route is durable and is set up over SSL (but I can replicate as well with non-SSL). I've tried to normalize the hostnames below to make things clearer; hopefully I didn't mess anything up. Given two clusters, cluster A (consisting of hosts A1 and A2) and cluster B (with B1 and B2), I've got a static exchange route from A1 to B1, as well as another from B1 to A1. Federation is working correctly, so I can send a message on A2 and have it successfully retrieved on B2. The exchange local to cluster A is walmyex1; the local exchange for B is bosmyex1. If I shut down the cluster in this order: B2, then B1, and start back up with B1, B2, the static route route fails to get recreated. That is, on A1/A2, looking at the bindings, exchange 'bosmyex1' does not get re-bound to cluster B; the only output for it in qpid-config exchanges --bindings is just: snip Exchange 'bosmyex1' (direct) /snip If however I shut the cluster down in this order: B1,
[jira] Resolved: (QPID-2992) Cluster failing to resurrect durable static route depending on order of shutdown
[ https://issues.apache.org/jira/browse/QPID-2992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish resolved QPID-2992. -- Resolution: Won't Fix I don't really want to say Won't Fix here -- I really want to say Will make two separate Jiras. ( please see my other comment for a complete explanation ) Cluster failing to resurrect durable static route depending on order of shutdown Key: QPID-2992 URL: https://issues.apache.org/jira/browse/QPID-2992 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Clustering Affects Versions: 0.8 Environment: Debian Linux Squeeze, 32-bit, kernel 2.6.36.2, Dell Poweredge 1950s. Corosync==1.3.0, Openais==1.1.4 Reporter: Mark Moseley Assignee: michael j. goulish Attachments: cluster-fed.sh, error I've got a 2-node qpid test cluster at each of 2 datacenters, which are federated together with a single durable static route between each. Qpid is version 0.8. Corosync and openais are stock Squeeze (1.2.1-3 and 1.1.2-2, respectively). OS is Squeeze, 32-bit, on Dell Poweredge 1950s, kernel 2.6.36. The static route is durable and is set up over SSL (but I can replicate as well with non-SSL). I've tried to normalize the hostnames below to make things clearer; hopefully I didn't mess anything up. Given two clusters, cluster A (consisting of hosts A1 and A2) and cluster B (with B1 and B2), I've got a static exchange route from A1 to B1, as well as another from B1 to A1. Federation is working correctly, so I can send a message on A2 and have it successfully retrieved on B2. The exchange local to cluster A is walmyex1; the local exchange for B is bosmyex1. If I shut down the cluster in this order: B2, then B1, and start back up with B1, B2, the static route route fails to get recreated. That is, on A1/A2, looking at the bindings, exchange 'bosmyex1' does not get re-bound to cluster B; the only output for it in qpid-config exchanges --bindings is just: snip Exchange 'bosmyex1' (direct) /snip If however I shut the cluster down in this order: B1, then B2, and start B2, then B1, the static route gets re-bound. The output then is: snip Exchange 'bosmyex1' (direct) bind [unix.boston.cust] = bridge_queue_1_8870523d-2286-408e-b5b5-50d53db2fa61 /bind and I can message over the federated link with no further modification. Prior to a few minutes ago, I was seeing this with the Squeeze stock openais==1.1.2 and corosync==1.2.1. In debugging this, I've upgraded both to the latest versions with no change. I can replicate this every time I try. These are just test clusters, so I don't have any other activity going on on them, or any other exchanges/queues. My steps: On all boxes in cluster A and B: * Kill the qpidd if it's running and delete all existing store files, i.e. contents of /var/lib/qpid/ On host A1 in cluster A (I'm leaving out the -a user/test@host stuff): * Start up qpid * qpid-config add exchange direct bosmyex1 --durable * qpid-config add exchange direct walmyex1 --durable * qpid-config add queue walmyq1 --durable * qpid-config bind walmyex1 walmyq1 unix.waltham.cust On host B1 in cluster B: * qpid-config add exchange direct bosmyex1 --durable * qpid-config add exchange direct walmyex1 --durable * qpid-config add queue bosmyq1 --durable * qpid-config bind bosmyex1 bosmyq1 unix.boston.cust On cluster A: * Start other member of cluster, A2 * qpid-route route add amqps://user/pass@HOSTA1:5671 amqps://user/pass@HOSTB1:5671 walmyex1 unix.waltham.cust -d On cluster B: * Start other member of cluster, B2 * qpid-route route add amqps://user/pass@HOSTB1:5671 amqps://user/pass@HOSTA1:5671 bosmyex1 unix.boston.cust -d On either cluster: * Check qpid-config exchanges --bindings to make sure bindings are correct for remote exchanges * To see correct behaviour, stop cluster in the order B1-B2, or A1-A2, start cluster back up, check bindings. * To see broken behaviour, stop cluster in the order B2-B1, or A2-A1, start cluster back up, check bindings. This is a test cluster, so I'm free to do anything with it, debugging-wise, that would be useful. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-3037) document race conditions in complex messaging systems
document race conditions in complex messaging systems - Key: QPID-3037 URL: https://issues.apache.org/jira/browse/QPID-3037 Project: Qpid Issue Type: Improvement Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish inspired by QPID-2992 We need some documentation to describe the kinds of 'race' problems you can get into when creating and shutting down messaging systems involving clusters, store, and federation. There are 'race conditions' that can give the appearance of bugs that depend on, for example, the speed with which you shut down brokers and the order in which you shut down brokers in a multi-broker messaging system. We should have a single place in the docs where we collect what we know about the most common of these problems, and best practices for avoiding them. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-2992) Cluster failing to resurrect durable static route depending on order of shutdown
[ https://issues.apache.org/jira/browse/QPID-2992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish reassigned QPID-2992: Assignee: michael j. goulish (was: Alan Conway) Cluster failing to resurrect durable static route depending on order of shutdown Key: QPID-2992 URL: https://issues.apache.org/jira/browse/QPID-2992 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Clustering Affects Versions: 0.8 Environment: Debian Linux Squeeze, 32-bit, kernel 2.6.36.2, Dell Poweredge 1950s. Corosync==1.3.0, Openais==1.1.4 Reporter: Mark Moseley Assignee: michael j. goulish Attachments: cluster-fed.sh, error I've got a 2-node qpid test cluster at each of 2 datacenters, which are federated together with a single durable static route between each. Qpid is version 0.8. Corosync and openais are stock Squeeze (1.2.1-3 and 1.1.2-2, respectively). OS is Squeeze, 32-bit, on Dell Poweredge 1950s, kernel 2.6.36. The static route is durable and is set up over SSL (but I can replicate as well with non-SSL). I've tried to normalize the hostnames below to make things clearer; hopefully I didn't mess anything up. Given two clusters, cluster A (consisting of hosts A1 and A2) and cluster B (with B1 and B2), I've got a static exchange route from A1 to B1, as well as another from B1 to A1. Federation is working correctly, so I can send a message on A2 and have it successfully retrieved on B2. The exchange local to cluster A is walmyex1; the local exchange for B is bosmyex1. If I shut down the cluster in this order: B2, then B1, and start back up with B1, B2, the static route route fails to get recreated. That is, on A1/A2, looking at the bindings, exchange 'bosmyex1' does not get re-bound to cluster B; the only output for it in qpid-config exchanges --bindings is just: snip Exchange 'bosmyex1' (direct) /snip If however I shut the cluster down in this order: B1, then B2, and start B2, then B1, the static route gets re-bound. The output then is: snip Exchange 'bosmyex1' (direct) bind [unix.boston.cust] = bridge_queue_1_8870523d-2286-408e-b5b5-50d53db2fa61 /bind and I can message over the federated link with no further modification. Prior to a few minutes ago, I was seeing this with the Squeeze stock openais==1.1.2 and corosync==1.2.1. In debugging this, I've upgraded both to the latest versions with no change. I can replicate this every time I try. These are just test clusters, so I don't have any other activity going on on them, or any other exchanges/queues. My steps: On all boxes in cluster A and B: * Kill the qpidd if it's running and delete all existing store files, i.e. contents of /var/lib/qpid/ On host A1 in cluster A (I'm leaving out the -a user/test@host stuff): * Start up qpid * qpid-config add exchange direct bosmyex1 --durable * qpid-config add exchange direct walmyex1 --durable * qpid-config add queue walmyq1 --durable * qpid-config bind walmyex1 walmyq1 unix.waltham.cust On host B1 in cluster B: * qpid-config add exchange direct bosmyex1 --durable * qpid-config add exchange direct walmyex1 --durable * qpid-config add queue bosmyq1 --durable * qpid-config bind bosmyex1 bosmyq1 unix.boston.cust On cluster A: * Start other member of cluster, A2 * qpid-route route add amqps://user/pass@HOSTA1:5671 amqps://user/pass@HOSTB1:5671 walmyex1 unix.waltham.cust -d On cluster B: * Start other member of cluster, B2 * qpid-route route add amqps://user/pass@HOSTB1:5671 amqps://user/pass@HOSTA1:5671 bosmyex1 unix.boston.cust -d On either cluster: * Check qpid-config exchanges --bindings to make sure bindings are correct for remote exchanges * To see correct behaviour, stop cluster in the order B1-B2, or A1-A2, start cluster back up, check bindings. * To see broken behaviour, stop cluster in the order B2-B1, or A2-A1, start cluster back up, check bindings. This is a test cluster, so I'm free to do anything with it, debugging-wise, that would be useful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-2993) Federated source-local links crash remotely federated cluster member on local cluster startup
[ https://issues.apache.org/jira/browse/QPID-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish reassigned QPID-2993: Assignee: michael j. goulish (was: Alan Conway) Federated source-local links crash remotely federated cluster member on local cluster startup - Key: QPID-2993 URL: https://issues.apache.org/jira/browse/QPID-2993 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Clustering Affects Versions: 0.8 Environment: Debian Linux Squeeze, 32-bit, kernel 2.6.36.2, Dell Poweredge 1950s. Corosync==1.3.0, Openais==1.1.4 Reporter: Mark Moseley Assignee: michael j. goulish Attachments: cluster-fed-src.sh This is related to JIRA 2992 that I opened, but this is for source-local routes. Given the same setup as in JIRA 2992 but using source-local routes (and obviously with the exchanges switched accordingly in the qpid-route statements), i.e. cluster A and cluster B with the routes between A1-B1, when cluster B shuts down in the order B2-B1 and starts back up, the static routes are not correctly re-bound on cluster A's side. However if cluster B is shut down in the order B1-B2 and started back up, the route is correctly created and works. However in the non-functioning case (B2-B1, or A2-A1), there is an additional side-effect: on node A2, qpidd crashes with the following error (cluster A is called 'walclust', B is bosclust): 2011-01-07 18:57:35 error Channel exception: not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) 2011-01-07 18:57:35 critical cluster(102.0.0.0:13650 READY/error) local error 2030 did not occur on member 101.0.0.0:9920: not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) 2011-01-07 18:57:35 critical Error delivering frames: local error did not occur on all cluster members : not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) (qpid/cluster/ErrorCheck.cpp:89) 2011-01-07 18:57:35 notice cluster(102.0.0.0:13650 LEFT/error) leaving cluster walclust 2011-01-07 18:57:35 notice Shut down This happens on both sides of the cluster, so it's not limited to one or the other. This crash does *not* occur in the A1-A2/B1-B2 test (i.e. the test where the route is re-bound correctly). I can cause this to reoccur pretty much every time. I've been resetting the cluster completely to a new state between each test. Occasionally in the B2-B1 test, A1 will also crash with the same error (and vice versa for A2-A1 for node B1), though most of the time, it's A2/B2 that crashes. I was getting this same behaviour prior to upgrading corosync/openais as well. Previously I was using the stock Squeeze versions of corosync==1.2.1 and openais==1.1.2. The results are the same with corosync=1.3.0 and openais==1.1.4. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2949) broker prompts console interactively for password when --auth=no
[ https://issues.apache.org/jira/browse/QPID-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-2949: - Attachment: dont_prompt_me_2.diff obsoletes previous patch this patch provides a way to tell SaslFactory that console interaction is NOT ok. i.e. if the code is running as part of a broker, or a demonized client of some kind. Just tell it to never do interaction, and any attempt to interact will be treated as an error. This script demonstrates that all goes well if you supply enough info : rm -rf /tmp/data_1 /tmp/data_2 mkdir /tmp/data_1 /tmp/data_2 # in window 1: ../qpidd -p 5672 --data-dir /tmp/data_1 --auth=yes --mgmt-enable=yes --log-enable info+ ./qpidd_1.log --log-source yes --sasl-config=/home/mick/trunk/qpid/cpp/src/tests/sasl_config # in window 2: ../qpidd -p 1 --data-dir /tmp/data_2 --auth=yes --mgmt-enable=yes --log-enable info+ ./qpidd_1.log --log-source yes --sasl-config=/home/mick/trunk/qpid/cpp/src/tests/sasl_config # in window 3 ( from qpid dir ) ./tools/src/py/qpid-route dynamic add zig/z...@localhost zig/z...@localhost:1 qmf.default.direct # and view the created route ./tools/src/py/qpid-route route list localhost:5672 If you say auth=no, that works fine also. HOWEVER PLEASE NOTE -- if you say auth=yes, but then do not supply enough into to avoid the need for interaction, the attempted interaction will result in the connection being closed. Then the originating broker will re-try the connection, and you will get a two-broker infinite loop until you fix it. broker prompts console interactively for password when --auth=no Key: QPID-2949 URL: https://issues.apache.org/jira/browse/QPID-2949 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.8 Reporter: michael j. goulish Assignee: michael j. goulish Priority: Minor Fix For: 0.9 Attachments: dont_prompt_me_2.diff, dont_prompt_me_2.diff, dont_prompt_me_2.diff, dont_prompt_me_noauth.diff As a result of checkin svn r1024541, which promoted some client-side Sasl code to the common library for use in broker, the broker now prompts for a password when when it is run with --auth=no ! The attached patch removes this behavior by propagating knowledge of --auth=no down to SaslFactory. If authorization has been turned off, the Saslfactory will create a null sasl object, just like it does if the code is compiled with no Sasl support. TODO -- also must fix the pathway where auth==yes. NOTE: this is apparently an irritant rather than a disaster, since it did not affect make check after the original checkin ( r102451 ). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2949) broker prompts console interactively for password when --auth=no
[ https://issues.apache.org/jira/browse/QPID-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-2949: - Description: As a result of checkin svn r1024541, which promoted some client-side Sasl code to the common library for use in broker, the broker now prompts for a password when when it is run with --auth=no ! The attached patch removes this behavior by propagating knowledge of --auth=no down to SaslFactory. If authorization has been turned off, the Saslfactory will create a null sasl object, just like it does if the code is compiled with no Sasl support. TODO -- also must fix the pathway where auth==yes. NOTE: this is apparently an irritant rather than a disaster, since it did not affect make check after the original checkin ( r102451 ). was: As a result of checkin svn r1024541, which promoted some client-side Sasl code to the common library for use in broker, the broker now prompts for a password when when it is run with --auth=no ! The attached patch removes this behavior by propagating knowledge of --auth=no down to SaslFactory. If authorization has been turned off, the Saslfactory will create a null sasl object, just like it does if the code is compiled with no Sasl support. broker prompts console interactively for password when --auth=no Key: QPID-2949 URL: https://issues.apache.org/jira/browse/QPID-2949 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.8 Reporter: michael j. goulish Assignee: michael j. goulish Priority: Minor Fix For: 0.8 Attachments: dont_prompt_me.diff As a result of checkin svn r1024541, which promoted some client-side Sasl code to the common library for use in broker, the broker now prompts for a password when when it is run with --auth=no ! The attached patch removes this behavior by propagating knowledge of --auth=no down to SaslFactory. If authorization has been turned off, the Saslfactory will create a null sasl object, just like it does if the code is compiled with no Sasl support. TODO -- also must fix the pathway where auth==yes. NOTE: this is apparently an irritant rather than a disaster, since it did not affect make check after the original checkin ( r102451 ). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-1672) Inter-broker links need full SASL support
[ https://issues.apache.org/jira/browse/QPID-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish reassigned QPID-1672: Assignee: michael j. goulish (was: Ken Giusti) Inter-broker links need full SASL support - Key: QPID-1672 URL: https://issues.apache.org/jira/browse/QPID-1672 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: M4 Reporter: Gordon Sim Assignee: michael j. goulish -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Closed: (QPID-2617) make sasl-based tests config files relocatable
[ https://issues.apache.org/jira/browse/QPID-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish closed QPID-2617. Resolution: Fixed fixed with svn rev 947748. make sasl-based tests config files relocatable -- Key: QPID-2617 URL: https://issues.apache.org/jira/browse/QPID-2617 Project: Qpid Issue Type: Improvement Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish Currently, sasl-based testing is hampered by the fact that the sasl library code is only reading its configuration information from the standard installed location /etc/sasl2 . This means that sasl installation must be done manually on a machine prior to running sasl-based tests, which makes them not fully automatable. 1. Find a way of telling the library to look elsewhere 2. expose that mechanism through a broker option 3. check a suitable config file into our source tree, at cpp/src/tests 4. reference the locally-created sasldb from the new config file 5. the new sasl tests should be runnable by any users -- not just root. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2617) make sasl-based tests config files relocatable
make sasl-based tests config files relocatable -- Key: QPID-2617 URL: https://issues.apache.org/jira/browse/QPID-2617 Project: Qpid Issue Type: Improvement Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish Currently, sasl-based testing is hampered by the fact that the sasl library code is only reading its configuration information from the standard installed location /etc/sasl2 . This means that sasl installation must be done manually on a machine prior to running sasl-based tests, which makes them not fully automatable. 1. Find a way of telling the library to look elsewhere 2. expose that mechanism through a broker option 3. check a suitable config file into our source tree, at cpp/src/tests 4. reference the locally-created sasldb from the new config file 5. the new sasl tests should be runnable by any users -- not just root. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2187) Allow clients to make secure/authenticated connections to a cluster.
[ https://issues.apache.org/jira/browse/QPID-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-2187: - Attachment: 944158.diff Cluster + Security --- * initial observation of a problem was a 2% failure rate in perftests of 20,000 messages against a cluster with security enabled. Problem was occasional receit of encrypted frames before the security codec had been enabled. This is fixed with locking in cluster code (no new locks in broker code) and a callback that is fired by broker::ConnectionHandler::Handler to tell the cluster code when the opening handshake has finished. This was never a problem in the non-clustered broker before because everything happened in a single thread. * the brokers that shadow the connection must not have null authenticators rather than real ones, so that they go through all the motions but don't do anythig. Only the directly-connected broker can perform the security handshake. * once the directly-connected broker receives the real user ID from its callback, it mcasts that ID to all other brokers. Otherwise the shadowing brokers will al think that the user ID is anonymous. Check this by doing a substantial perftest, and using qpid-stat -c localhost:PORT to confirm that the brokers all have the same userID for the same connection. * the user ID, negotiated during the Sasl security startup, is communicated from the directly connected broker to all other cluster brokers. * If security is *not* being used, then this code should *not* tell the brokers anything about the userID -- or it will step on the value that is being set by other code pathways. * test program at cpp/src/tests/cluster_authentication_soak is not yet fully automated -- run it with something like sudo ./cluster_authentication_soak 500 Allow clients to make secure/authenticated connections to a cluster. Key: QPID-2187 URL: https://issues.apache.org/jira/browse/QPID-2187 Project: Qpid Issue Type: Improvement Environment: all Reporter: Ken Giusti Assignee: michael j. goulish Attachments: 944158.diff The current implementation of clustering does not correctly handle authentication correctly.From the trunk build: [kgiu...@localhost src]$ ./qpidd --auth yes --realm KGIUSTI.COM --log-enable info+ --load-module ./.libs/cluster.so --cluster-name ken 2009-11-02 10:30:58 info Loaded Module: ./.libs/cluster.so 2009-11-02 10:30:58 info Management enabled 2009-11-02 10:30:58 notice Initializing CPG 2009-11-02 10:30:58 notice cluster(127.0.0.1:14581 INIT) membership change: 127.0.0.1:14581 (joined: 127.0.0.1:14581(joined) ) 2009-11-02 10:30:58 info No message store configured, persistence is disabled. 2009-11-02 10:30:58 info SASL enabled 2009-11-02 10:30:58 notice Listening on TCP port 5672 2009-11-02 10:30:58 notice cluster(127.0.0.1:14581 INIT) joining cluster ken with url=amqp:tcp:10.16.19.19:5672,tcp:10.16.14.69:5672,tcp:192.168.122.1:5672 2009-11-02 10:30:58 notice Broker running 2009-11-02 10:30:58 info cluster(127.0.0.1:14581 READY) member update: 127.0.0.1:14581(member) 2009-11-02 10:30:58 notice cluster(127.0.0.1:14581 READY) first in cluster 2009-11-02 10:31:05 info SASL: Mechanism list: ANONYMOUS PLAIN DIGEST-MD5 LOGIN GSSAPI CRAM-MD5 2009-11-02 10:31:05 info cluster(127.0.0.1:14581 READY) new local connection 127.0.0.1:14581-1 2009-11-02 10:31:05 info SASL: Starting authentication with mechanism: GSSAPI 2009-11-02 10:31:05 info SASL: Authentication succeeded for: testu...@kgiusti.com 2009-11-02 10:31:05 error cluster(127.0.0.1:14581 READY) aborting connection 127.0.0.1:14581-1: framing-error: Reserved bits not zero (qpid/framing/AMQFrame.cpp:132) 2009-11-02 10:31:05 info cluster(127.0.0.1:14581 READY) connection closed 127.0.0.1:14581-1 The above error occurs when running perftest against the cluster in the following manner: [kgiu...@localhost tests]$ /usr/kerberos/bin/kinit testu...@kgiusti.com [kgiu...@localhost tests]$ ./perftest -b localhost.localdomain --mechanism GSSAPI --username testuser --tx 1 --count 1 --summary --log-enable info+ 2009-11-02 10:31:05 info Connecting to tcp:localhost.localdomain:5672 2009-11-02 10:31:05 info Installing security layer, SSF: 56 2009-11-02 10:31:05 warning Connection closed Running the same test, but turning off clustering, authentication succeeds. Alan has determined that the problem is due to the way the clustered broker constructs the codec chain. The chain is built without the codec for a secure connection. The correct solution would implement a mechanism that allows more generic chaining of the codecs. It should be possible to
[jira] Closed: (QPID-2187) Allow clients to make secure/authenticated connections to a cluster.
[ https://issues.apache.org/jira/browse/QPID-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish closed QPID-2187. Resolution: Fixed Cluster + Security --- * initial observation of a problem was a 2% failure rate in perftests of 20,000 messages against a cluster with security enabled. Problem was occasional receit of encrypted frames before the security codec had been enabled. This is fixed with locking in cluster code (no new locks in broker code) and a callback that is fired by broker::ConnectionHandler::Handler to tell the cluster code when the opening handshake has finished. This was never a problem in the non-clustered broker before because everything happened in a single thread. * the brokers that shadow the connection must not have null authenticators rather than real ones, so that they go through all the motions but don't do anythig. Only the directly-connected broker can perform the security handshake. * once the directly-connected broker receives the real user ID from its callback, it mcasts that ID to all other brokers. Otherwise the shadowing brokers will al think that the user ID is anonymous. Check this by doing a substantial perftest, and using qpid-stat -c localhost:PORT to confirm that the brokers all have the same userID for the same connection. * the user ID, negotiated during the Sasl security startup, is communicated from the directly connected broker to all other cluster brokers. * If security is *not* being used, then this code should *not* tell the brokers anything about the userID -- or it will step on the value that is being set by other code pathways. * test program at cpp/src/tests/cluster_authentication_soak is not yet fully automated -- run it with something like sudo ./cluster_authentication_soak 500 Allow clients to make secure/authenticated connections to a cluster. Key: QPID-2187 URL: https://issues.apache.org/jira/browse/QPID-2187 Project: Qpid Issue Type: Improvement Environment: all Reporter: Ken Giusti Assignee: michael j. goulish Attachments: 944158.diff The current implementation of clustering does not correctly handle authentication correctly.From the trunk build: [kgiu...@localhost src]$ ./qpidd --auth yes --realm KGIUSTI.COM --log-enable info+ --load-module ./.libs/cluster.so --cluster-name ken 2009-11-02 10:30:58 info Loaded Module: ./.libs/cluster.so 2009-11-02 10:30:58 info Management enabled 2009-11-02 10:30:58 notice Initializing CPG 2009-11-02 10:30:58 notice cluster(127.0.0.1:14581 INIT) membership change: 127.0.0.1:14581 (joined: 127.0.0.1:14581(joined) ) 2009-11-02 10:30:58 info No message store configured, persistence is disabled. 2009-11-02 10:30:58 info SASL enabled 2009-11-02 10:30:58 notice Listening on TCP port 5672 2009-11-02 10:30:58 notice cluster(127.0.0.1:14581 INIT) joining cluster ken with url=amqp:tcp:10.16.19.19:5672,tcp:10.16.14.69:5672,tcp:192.168.122.1:5672 2009-11-02 10:30:58 notice Broker running 2009-11-02 10:30:58 info cluster(127.0.0.1:14581 READY) member update: 127.0.0.1:14581(member) 2009-11-02 10:30:58 notice cluster(127.0.0.1:14581 READY) first in cluster 2009-11-02 10:31:05 info SASL: Mechanism list: ANONYMOUS PLAIN DIGEST-MD5 LOGIN GSSAPI CRAM-MD5 2009-11-02 10:31:05 info cluster(127.0.0.1:14581 READY) new local connection 127.0.0.1:14581-1 2009-11-02 10:31:05 info SASL: Starting authentication with mechanism: GSSAPI 2009-11-02 10:31:05 info SASL: Authentication succeeded for: testu...@kgiusti.com 2009-11-02 10:31:05 error cluster(127.0.0.1:14581 READY) aborting connection 127.0.0.1:14581-1: framing-error: Reserved bits not zero (qpid/framing/AMQFrame.cpp:132) 2009-11-02 10:31:05 info cluster(127.0.0.1:14581 READY) connection closed 127.0.0.1:14581-1 The above error occurs when running perftest against the cluster in the following manner: [kgiu...@localhost tests]$ /usr/kerberos/bin/kinit testu...@kgiusti.com [kgiu...@localhost tests]$ ./perftest -b localhost.localdomain --mechanism GSSAPI --username testuser --tx 1 --count 1 --summary --log-enable info+ 2009-11-02 10:31:05 info Connecting to tcp:localhost.localdomain:5672 2009-11-02 10:31:05 info Installing security layer, SSF: 56 2009-11-02 10:31:05 warning Connection closed Running the same test, but turning off clustering, authentication succeeds. Alan has determined that the problem is due to the way the clustered broker constructs the codec chain. The chain is built without the codec for a secure connection. The correct solution would implement a mechanism that allows more generic chaining of the codecs. It should be possible to allow
[jira] Commented: (QPID-2235) clustered broker does not retry CPG calls that return TRY_AGAIN
[ https://issues.apache.org/jira/browse/QPID-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789357#action_12789357 ] michael j. goulish commented on QPID-2235: -- fixed by svn rev 889657. sorry, i do not have permission to change status of this Jira to resolved. don't know why... clustered broker does not retry CPG calls that return TRY_AGAIN Key: QPID-2235 URL: https://issues.apache.org/jira/browse/QPID-2235 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.5 Reporter: Alan Conway Assignee: Alan Conway Priority: Minor Fix For: 0.6 Causes occasional failures on joining a cluster like this: soak-22: 2009-12-03 15:49:44 notice Initializing CPG soak-22: 2009-12-03 15:49:44 critical Unexpected error: Cannot join CPG group soakTestCluster_9edd905b-92b3-4cfb-803f-120d7a088f1f: try again (6) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1988) unhang failover_soak in case of broker error
[ https://issues.apache.org/jira/browse/QPID-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-1988: - Attachment: unhang_failover_soak.patch unhang failover_soak in case of broker error Key: QPID-1988 URL: https://issues.apache.org/jira/browse/QPID-1988 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Attachments: unhang_failover_soak.patch Currently failover_soak will deliberately leave its other brokers alive if one of them exits unexpectedly. But this makes failover_soak a bad citizen in multi-test systems like make check. The added line of code in this patch makes this exit-path from the program the same as all others. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-1988) unhang failover_soak in case of broker error
unhang failover_soak in case of broker error Key: QPID-1988 URL: https://issues.apache.org/jira/browse/QPID-1988 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Attachments: unhang_failover_soak.patch Currently failover_soak will deliberately leave its other brokers alive if one of them exits unexpectedly. But this makes failover_soak a bad citizen in multi-test systems like make check. The added line of code in this patch makes this exit-path from the program the same as all others. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1908) cluster_manager -- testing tool
[ https://issues.apache.org/jira/browse/QPID-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-1908: - Attachment: cluster_manager.diff cluster_manager -- testing tool --- Key: QPID-1908 URL: https://issues.apache.org/jira/browse/QPID-1908 Project: Qpid Issue Type: Improvement Components: C++ Broker Reporter: michael j. goulish Attachments: cluster_manager.diff cluster_manager will start a cluster on a set of host:port URLs that you specify on the command line. The hosts can all be different -- so long as they are all clustered and have openais running on them. It will then periodically check the qpid cluster and make sure that there are syill brokers running at the expected places. ( For this, it uses ssh and reads /proc . ) If it finds that one or more brokers are missing, it will start new brokers to replace them. This will allows us to run long-term tests in which the clients start and stop (or are killed) during the test -- they will always know what set of host:ports to attach to. Clients can be written either to try one host:port after the other until they connect (which is functionality available from the client library) -- or so that they try a single host:port -- then wait 30 seconds or so and retry if it doesn't work the first time. ( Because of the use of ssh, this is not a very high-speed application. It often takes more than 30 seconds to check on a cluster of 3 brokers. ) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-1891) fix declaration problems with boost 1_33_1
fix declaration problems with boost 1_33_1 -- Key: QPID-1891 URL: https://issues.apache.org/jira/browse/QPID-1891 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Under Boost 1.33.1, the use of boost::starts_withcaused compilation problems like this: /usr/include/boost/algorithm/string/iterator_range.hpp:289: error: make_iterator_range is already declared in this scope So I replaced it with C stdlib equivalents. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1891) fix declaration problems with boost 1_33_1
[ https://issues.apache.org/jira/browse/QPID-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-1891: - Attachment: (was: tests.diff) fix declaration problems with boost 1_33_1 -- Key: QPID-1891 URL: https://issues.apache.org/jira/browse/QPID-1891 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Under Boost 1.33.1, the use of boost::starts_withcaused compilation problems like this: /usr/include/boost/algorithm/string/iterator_range.hpp:289: error: make_iterator_range is already declared in this scope So I replaced it with C stdlib equivalents. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1891) fix declaration problems with boost 1_33_1
[ https://issues.apache.org/jira/browse/QPID-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-1891: - Attachment: tests.diff tests.diff fix declaration problems with boost 1_33_1 -- Key: QPID-1891 URL: https://issues.apache.org/jira/browse/QPID-1891 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Under Boost 1.33.1, the use of boost::starts_withcaused compilation problems like this: /usr/include/boost/algorithm/string/iterator_range.hpp:289: error: make_iterator_range is already declared in this scope So I replaced it with C stdlib equivalents. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1891) fix declaration problems with boost 1_33_1
[ https://issues.apache.org/jira/browse/QPID-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-1891: - Attachment: forked_broker.diff tests.diff fix declaration problems with boost 1_33_1 -- Key: QPID-1891 URL: https://issues.apache.org/jira/browse/QPID-1891 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Attachments: forked_broker.diff, tests.diff Under Boost 1.33.1, the use of boost::starts_withcaused compilation problems like this: /usr/include/boost/algorithm/string/iterator_range.hpp:289: error: make_iterator_range is already declared in this scope So I replaced it with C stdlib equivalents. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1873) Queue durability does not propagate in cluster newbie broker update.
[ https://issues.apache.org/jira/browse/QPID-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-1873: - Attachment: queue_durability_propagation.diff Queue durability does not propagate in cluster newbie broker update. Key: QPID-1873 URL: https://issues.apache.org/jira/browse/QPID-1873 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Attachments: queue_durability_propagation.diff When a newbie broker is added to a cluster, it will hallucinate all of its queues as durable. It happens because the encode / decode stuff in src/qpid/broker/Queue.cpp just doesn't propagate the actual durability status of queues. It assumes that all queues are durable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-1796) add durability to failover_soak.cpp
add durability to failover_soak.cpp --- Key: QPID-1796 URL: https://issues.apache.org/jira/browse/QPID-1796 Project: Qpid Issue Type: Improvement Components: C++ Broker Reporter: michael j. goulish Priority: Minor Add durability option to the cpp failover_soak test. The failover_soak executable uses several external executables, so they all had to be modified as well. Default is still non-durable. Setting durability=1 also has the effect of making replaying_sender send persistent messages. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1693) Several improvements to cpp/src/tests/failover_soak.cpp
[
https://issues.apache.org/jira/browse/QPID-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
michael j. goulish updated QPID-1693:
-
Attachment: failover_soak_improvements.diff
Several improvements to cpp/src/tests/failover_soak.cpp
--
Key: QPID-1693
URL: https://issues.apache.org/jira/browse/QPID-1693
Project: Qpid
Issue Type: Improvement
Components: C++ Broker
Reporter: michael j. goulish
Priority: Minor
Attachments: failover_soak_improvements.diff
improvements for failover_soak
{
1. Do not kill children if they hang. Leave
alive for questioning.
2. Identify what type of child is hanging.
3. Print a clear end-of-test message for grepping
( and clear status indication on same line. )
4. Detect and error out on spontaneous broker death.
5. Improve message when child fails to start up.
6. Don't kill brokers when they've been newly added
to the cluster and are updating. It generates
spurious errors.
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-1693) Several improvements to cpp/src/tests/failover_soak.cpp
Several improvements to cpp/src/tests/failover_soak.cpp
--
Key: QPID-1693
URL: https://issues.apache.org/jira/browse/QPID-1693
Project: Qpid
Issue Type: Improvement
Components: C++ Broker
Reporter: michael j. goulish
Priority: Minor
Attachments: failover_soak_improvements.diff
improvements for failover_soak
{
1. Do not kill children if they hang. Leave
alive for questioning.
2. Identify what type of child is hanging.
3. Print a clear end-of-test message for grepping
( and clear status indication on same line. )
4. Detect and error out on spontaneous broker death.
5. Improve message when child fails to start up.
6. Don't kill brokers when they've been newly added
to the cluster and are updating. It generates
spurious errors.
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-1678) better cluster names in cluster_failover soak
better cluster names in cluster_failover soak -- Key: QPID-1678 URL: https://issues.apache.org/jira/browse/QPID-1678 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Priority: Minor Attachments: failover_soak_uuid.diff cluster_failover_soak in cpp/src/tests currently uses a random number between 0 and 1000 as the uniqing factor in its cluster names. There may have been a collision recently when two tests were running simultaneously on one clustered setup during a Ptolemy test. This change make it use UUIDs. If one of these collides please tell me, so I can buy a lotto ticket with that number on it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1678) better cluster names in cluster_failover soak
[ https://issues.apache.org/jira/browse/QPID-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-1678: - Attachment: failover_soak_uuid.diff better cluster names in cluster_failover soak -- Key: QPID-1678 URL: https://issues.apache.org/jira/browse/QPID-1678 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Priority: Minor Attachments: failover_soak_uuid.diff cluster_failover_soak in cpp/src/tests currently uses a random number between 0 and 1000 as the uniqing factor in its cluster names. There may have been a collision recently when two tests were running simultaneously on one clustered setup during a Ptolemy test. This change make it use UUIDs. If one of these collides please tell me, so I can buy a lotto ticket with that number on it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1674) failover_soak string-out-of-scope error
[ https://issues.apache.org/jira/browse/QPID-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-1674: - Attachment: failover_soak.diff failover_soak string-out-of-scope error --- Key: QPID-1674 URL: https://issues.apache.org/jira/browse/QPID-1674 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Attachments: failover_soak.diff Fixes an error caused by a string going out of scope just before ForkedBroker startup. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-1674) failover_soak string-out-of-scope error
failover_soak string-out-of-scope error --- Key: QPID-1674 URL: https://issues.apache.org/jira/browse/QPID-1674 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Attachments: failover_soak.diff Fixes an error caused by a string going out of scope just before ForkedBroker startup. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1651) add editable broker argv to src/tests/ClusterFixture
[ https://issues.apache.org/jira/browse/QPID-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-1651: - Attachment: ClusterFixtureArgv.diff add editable broker argv to src/tests/ClusterFixture Key: QPID-1651 URL: https://issues.apache.org/jira/browse/QPID-1651 Project: Qpid Issue Type: Improvement Components: C++ Broker Reporter: michael j. goulish Priority: Minor Attachments: ClusterFixtureArgv.diff make the argv that is used for the broker creation editable -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1618) unacked persistent messages don't get to messageStore of newbie cluster broker.
[ https://issues.apache.org/jira/browse/QPID-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-1618: - Attachment: qpid_1618.diff unacked persistent messages don't get to messageStore of newbie cluster broker. --- Key: QPID-1618 URL: https://issues.apache.org/jira/browse/QPID-1618 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: M4 Reporter: michael j. goulish Priority: Critical Attachments: qpid_1618.diff When a new broker is added to a cluster, persistent messages that have not yet been ACKed do not get stored in the new brokers messageStore. How to reproduce: ( this is overview -- actual scripts follow ) 1. kill any MY_CLUSTER brokers from previous test 2. remove data dirs from previous test, and recreate 3. start node 1 as first member of MY_CLUSTER 4 declare the MY_CLUSTER queue -- durable 5. connect to it with receiver -- use ack frequency of 10; 6. connect with publish send only 5 persistent msgs, receiver will get them but not ack. 7. start second node 8. when the state transfer completes kill both nodes. (receiver should also perish) 9. start up the second node only, as new first member of MY_CLUSTER. ( I.e. use 2nd broker's data dir path. ) 10. start and attach a new receiver PREVIOUS RESULT -- nothing. messages were never stored in broker2's messageStore. RESULT -- new receiver now gets 5 messages. durable queue says that sender confirmed point moved to (5+0) == Scripts for reproducing problem. == ### #step 1 ## ### #! /bin/bash echo echo Step 1: Kill any brokers already running in the MY_CLUSTER cluster echo kill -9 `pgrep -f MY_STORE` echo There should be no remaining brokers. Here they are: ps -aef | grep qpidd | grep -v grep ### #step 2 ## ### #! /bin/bash echo echo Step 2: remove and rebuild the store data dirs. echo rm -rf ./data mkdir -p ./data/1 ./data/2 ### #step 3 ## ### #! /bin/bash echo echo Step 3: Start the first broker in a cluster, using Store in ./data/1 . echo rm broker_1.log $QPID_ROOT/cpp/src/qpidd --no-module-dir\ --load-module $QPID_ROOT/cpp/src/.libs/cluster.so \ --load-module $STORE_ROOT/cpp/lib/.libs/msgstore.so \ --cluster-name MY_CLUSTER -p 5813 \ --auth=no --mgmt-enable=no\ --log-enable debug --log-to-file ./broker_1.log \ --data-dir ./data/1 ### #step 4 ## ### #! /bin/bash echo Step 4: Declaring queue. $QPID_ROOT/cpp/examples/direct/declare_queues # !! NOTE !! # edit declare_queues.cpp to do port 5813 # in call to session.queueDeclare use arg::durable=true # and arg::queue=MY_QUEUE, # edit exchangeBind call to use: # arg::queue = MY_QUEUE, ### #step 5 ## ### #! /bin/bash echo Step 5: Starting receiver... $QPID_ROOT/cpp/src/tests/receiver \ -p 5813 \ --queue MY_QUEUE \ --messages 10 \ --ack-frequency 10 ### #step 6 ## ### #! /bin/bash echo Publish only 5 messages, so the receiver will not yet ack.
[jira] Updated: (QPID-1618) unacked persistent messages don't get to messageStore of newbie cluster broker.
[ https://issues.apache.org/jira/browse/QPID-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-1618: - Attachment: (was: qpid_1618.diff) unacked persistent messages don't get to messageStore of newbie cluster broker. --- Key: QPID-1618 URL: https://issues.apache.org/jira/browse/QPID-1618 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: M4 Reporter: michael j. goulish Priority: Critical Attachments: qpid_1618.diff When a new broker is added to a cluster, persistent messages that have not yet been ACKed do not get stored in the new brokers messageStore. How to reproduce: ( this is overview -- actual scripts follow ) 1. kill any MY_CLUSTER brokers from previous test 2. remove data dirs from previous test, and recreate 3. start node 1 as first member of MY_CLUSTER 4 declare the MY_CLUSTER queue -- durable 5. connect to it with receiver -- use ack frequency of 10; 6. connect with publish send only 5 persistent msgs, receiver will get them but not ack. 7. start second node 8. when the state transfer completes kill both nodes. (receiver should also perish) 9. start up the second node only, as new first member of MY_CLUSTER. ( I.e. use 2nd broker's data dir path. ) 10. start and attach a new receiver PREVIOUS RESULT -- nothing. messages were never stored in broker2's messageStore. RESULT -- new receiver now gets 5 messages. durable queue says that sender confirmed point moved to (5+0) == Scripts for reproducing problem. == ### #step 1 ## ### #! /bin/bash echo echo Step 1: Kill any brokers already running in the MY_CLUSTER cluster echo kill -9 `pgrep -f MY_STORE` echo There should be no remaining brokers. Here they are: ps -aef | grep qpidd | grep -v grep ### #step 2 ## ### #! /bin/bash echo echo Step 2: remove and rebuild the store data dirs. echo rm -rf ./data mkdir -p ./data/1 ./data/2 ### #step 3 ## ### #! /bin/bash echo echo Step 3: Start the first broker in a cluster, using Store in ./data/1 . echo rm broker_1.log $QPID_ROOT/cpp/src/qpidd --no-module-dir\ --load-module $QPID_ROOT/cpp/src/.libs/cluster.so \ --load-module $STORE_ROOT/cpp/lib/.libs/msgstore.so \ --cluster-name MY_CLUSTER -p 5813 \ --auth=no --mgmt-enable=no\ --log-enable debug --log-to-file ./broker_1.log \ --data-dir ./data/1 ### #step 4 ## ### #! /bin/bash echo Step 4: Declaring queue. $QPID_ROOT/cpp/examples/direct/declare_queues # !! NOTE !! # edit declare_queues.cpp to do port 5813 # in call to session.queueDeclare use arg::durable=true # and arg::queue=MY_QUEUE, # edit exchangeBind call to use: # arg::queue = MY_QUEUE, ### #step 5 ## ### #! /bin/bash echo Step 5: Starting receiver... $QPID_ROOT/cpp/src/tests/receiver \ -p 5813 \ --queue MY_QUEUE \ --messages 10 \ --ack-frequency 10 ### #step 6 ## ### #! /bin/bash echo Publish only 5 messages, so the receiver will not yet
[jira] Created: (QPID-1650) in src/tests, separate the code for ClusterFixture
in src/tests, separate the code for ClusterFixture --- Key: QPID-1650 URL: https://issues.apache.org/jira/browse/QPID-1650 Project: Qpid Issue Type: Improvement Components: C++ Broker Reporter: michael j. goulish Priority: Minor Attachments: separate_ClusterFixture.diff Separating out the code for ClusterFixture into its own files so it can be re-used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1627) Three T-Shirt Alternatives
[ https://issues.apache.org/jira/browse/QPID-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-1627: - Attachment: qpid_shirts.jpg Three T-Shirt Alternatives -- Key: QPID-1627 URL: https://issues.apache.org/jira/browse/QPID-1627 Project: Qpid Issue Type: Wish Reporter: michael j. goulish Priority: Trivial Attachments: qpid_shirts.jpg All three are based on the I'm with Qpid! idea. Just different shapes for the arrow. Original, Manta, and Chevron. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-1624) t-shirt image concept
t-shirt image concept - Key: QPID-1624 URL: https://issues.apache.org/jira/browse/QPID-1624 Project: Qpid Issue Type: Wish Reporter: michael j. goulish Priority: Trivial Attachments: im_with_qpid.jpg Here's a concept for a t-shirt logo based on the I'm with Qpid! slogan. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1624) t-shirt image concept
[ https://issues.apache.org/jira/browse/QPID-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-1624: - Attachment: im_with_qpid.jpg t-shirt image concept - Key: QPID-1624 URL: https://issues.apache.org/jira/browse/QPID-1624 Project: Qpid Issue Type: Wish Reporter: michael j. goulish Priority: Trivial Attachments: im_with_qpid.jpg Here's a concept for a t-shirt logo based on the I'm with Qpid! slogan. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1618) unacked persistent messages don't get to messageStore of newbie cluster broker.
[ https://issues.apache.org/jira/browse/QPID-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-1618: - Attachment: (was: unack_newbie.diff) unacked persistent messages don't get to messageStore of newbie cluster broker. --- Key: QPID-1618 URL: https://issues.apache.org/jira/browse/QPID-1618 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: M4 Reporter: michael j. goulish Priority: Critical When a new broker is added to a cluster, persistent messages that have not yet been ACKed do not get stored in the new brokers messageStore. How to reproduce: ( this is overview -- actual scripts follow ) 1. kill any MY_CLUSTER brokers from previous test 2. remove data dirs from previous test, and recreate 3. start node 1 as first member of MY_CLUSTER 4 declare the MY_CLUSTER queue -- durable 5. connect to it with receiver -- use ack frequency of 10; 6. connect with publish send only 5 persistent msgs, receiver will get them but not ack. 7. start second node 8. when the state transfer completes kill both nodes. (receiver should also perish) 9. start up the second node only, as new first member of MY_CLUSTER. ( I.e. use 2nd broker's data dir path. ) 10. start and attach a new receiver PREVIOUS RESULT -- nothing. messages were never stored in broker2's messageStore. RESULT -- new receiver now gets 5 messages. durable queue says that sender confirmed point moved to (5+0) == Scripts for reproducing problem. == ### #step 1 ## ### #! /bin/bash echo echo Step 1: Kill any brokers already running in the MY_CLUSTER cluster echo kill -9 `pgrep -f MY_STORE` echo There should be no remaining brokers. Here they are: ps -aef | grep qpidd | grep -v grep ### #step 2 ## ### #! /bin/bash echo echo Step 2: remove and rebuild the store data dirs. echo rm -rf ./data mkdir -p ./data/1 ./data/2 ### #step 3 ## ### #! /bin/bash echo echo Step 3: Start the first broker in a cluster, using Store in ./data/1 . echo rm broker_1.log $QPID_ROOT/cpp/src/qpidd --no-module-dir\ --load-module $QPID_ROOT/cpp/src/.libs/cluster.so \ --load-module $STORE_ROOT/cpp/lib/.libs/msgstore.so \ --cluster-name MY_CLUSTER -p 5813 \ --auth=no --mgmt-enable=no\ --log-enable debug --log-to-file ./broker_1.log \ --data-dir ./data/1 ### #step 4 ## ### #! /bin/bash echo Step 4: Declaring queue. $QPID_ROOT/cpp/examples/direct/declare_queues # !! NOTE !! # edit declare_queues.cpp to do port 5813 # in call to session.queueDeclare use arg::durable=true # and arg::queue=MY_QUEUE, # edit exchangeBind call to use: # arg::queue = MY_QUEUE, ### #step 5 ## ### #! /bin/bash echo Step 5: Starting receiver... $QPID_ROOT/cpp/src/tests/receiver \ -p 5813 \ --queue MY_QUEUE \ --messages 10 \ --ack-frequency 10 ### #step 6 ## ### #! /bin/bash echo Publish only 5 messages, so the receiver will not yet ack.
[jira] Updated: (QPID-1618) unacked persistent messages don't get to messageStore of newbie cluster broker.
[ https://issues.apache.org/jira/browse/QPID-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-1618: - Attachment: unack_newbie.diff unacked persistent messages don't get to messageStore of newbie cluster broker. --- Key: QPID-1618 URL: https://issues.apache.org/jira/browse/QPID-1618 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: M4 Reporter: michael j. goulish Priority: Critical Attachments: unack_newbie.diff When a new broker is added to a cluster, persistent messages that have not yet been ACKed do not get stored in the new brokers messageStore. How to reproduce: ( this is overview -- actual scripts follow ) 1. kill any MY_CLUSTER brokers from previous test 2. remove data dirs from previous test, and recreate 3. start node 1 as first member of MY_CLUSTER 4 declare the MY_CLUSTER queue -- durable 5. connect to it with receiver -- use ack frequency of 10; 6. connect with publish send only 5 persistent msgs, receiver will get them but not ack. 7. start second node 8. when the state transfer completes kill both nodes. (receiver should also perish) 9. start up the second node only, as new first member of MY_CLUSTER. ( I.e. use 2nd broker's data dir path. ) 10. start and attach a new receiver PREVIOUS RESULT -- nothing. messages were never stored in broker2's messageStore. RESULT -- new receiver now gets 5 messages. durable queue says that sender confirmed point moved to (5+0) == Scripts for reproducing problem. == ### #step 1 ## ### #! /bin/bash echo echo Step 1: Kill any brokers already running in the MY_CLUSTER cluster echo kill -9 `pgrep -f MY_STORE` echo There should be no remaining brokers. Here they are: ps -aef | grep qpidd | grep -v grep ### #step 2 ## ### #! /bin/bash echo echo Step 2: remove and rebuild the store data dirs. echo rm -rf ./data mkdir -p ./data/1 ./data/2 ### #step 3 ## ### #! /bin/bash echo echo Step 3: Start the first broker in a cluster, using Store in ./data/1 . echo rm broker_1.log $QPID_ROOT/cpp/src/qpidd --no-module-dir\ --load-module $QPID_ROOT/cpp/src/.libs/cluster.so \ --load-module $STORE_ROOT/cpp/lib/.libs/msgstore.so \ --cluster-name MY_CLUSTER -p 5813 \ --auth=no --mgmt-enable=no\ --log-enable debug --log-to-file ./broker_1.log \ --data-dir ./data/1 ### #step 4 ## ### #! /bin/bash echo Step 4: Declaring queue. $QPID_ROOT/cpp/examples/direct/declare_queues # !! NOTE !! # edit declare_queues.cpp to do port 5813 # in call to session.queueDeclare use arg::durable=true # and arg::queue=MY_QUEUE, # edit exchangeBind call to use: # arg::queue = MY_QUEUE, ### #step 5 ## ### #! /bin/bash echo Step 5: Starting receiver... $QPID_ROOT/cpp/src/tests/receiver \ -p 5813 \ --queue MY_QUEUE \ --messages 10 \ --ack-frequency 10 ### #step 6 ## ### #! /bin/bash echo Publish only 5 messages, so the receiver will not yet ack.
[jira] Created: (QPID-1618) unacked persistent messages don't get to messageStore of newbie cluster broker.
unacked persistent messages don't get to messageStore of newbie cluster broker. --- Key: QPID-1618 URL: https://issues.apache.org/jira/browse/QPID-1618 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: M4 Reporter: michael j. goulish Priority: Critical Attachments: unack_newbie.diff When a new broker is added to a cluster, persistent messages that have not yet been ACKed do not get stored in the new brokers messageStore. How to reproduce: ( this is overview -- actual scripts follow ) 1. kill any MY_CLUSTER brokers from previous test 2. remove data dirs from previous test, and recreate 3. start node 1 as first member of MY_CLUSTER 4 declare the MY_CLUSTER queue -- durable 5. connect to it with receiver -- use ack frequency of 10; 6. connect with publish send only 5 persistent msgs, receiver will get them but not ack. 7. start second node 8. when the state transfer completes kill both nodes. (receiver should also perish) 9. start up the second node only, as new first member of MY_CLUSTER. ( I.e. use 2nd broker's data dir path. ) 10. start and attach a new receiver PREVIOUS RESULT -- nothing. messages were never stored in broker2's messageStore. RESULT -- new receiver now gets 5 messages. durable queue says that sender confirmed point moved to (5+0) == Scripts for reproducing problem. == ### #step 1 ## ### #! /bin/bash echo echo Step 1: Kill any brokers already running in the MY_CLUSTER cluster echo kill -9 `pgrep -f MY_STORE` echo There should be no remaining brokers. Here they are: ps -aef | grep qpidd | grep -v grep ### #step 2 ## ### #! /bin/bash echo echo Step 2: remove and rebuild the store data dirs. echo rm -rf ./data mkdir -p ./data/1 ./data/2 ### #step 3 ## ### #! /bin/bash echo echo Step 3: Start the first broker in a cluster, using Store in ./data/1 . echo rm broker_1.log $QPID_ROOT/cpp/src/qpidd --no-module-dir\ --load-module $QPID_ROOT/cpp/src/.libs/cluster.so \ --load-module $STORE_ROOT/cpp/lib/.libs/msgstore.so \ --cluster-name MY_CLUSTER -p 5813 \ --auth=no --mgmt-enable=no\ --log-enable debug --log-to-file ./broker_1.log \ --data-dir ./data/1 ### #step 4 ## ### #! /bin/bash echo Step 4: Declaring queue. $QPID_ROOT/cpp/examples/direct/declare_queues # !! NOTE !! # edit declare_queues.cpp to do port 5813 # in call to session.queueDeclare use arg::durable=true # and arg::queue=MY_QUEUE, # edit exchangeBind call to use: # arg::queue = MY_QUEUE, ### #step 5 ## ### #! /bin/bash echo Step 5: Starting receiver... $QPID_ROOT/cpp/src/tests/receiver \ -p 5813 \ --queue MY_QUEUE \ --messages 10 \ --ack-frequency 10 ### #step 6 ## ### #! /bin/bash echo Publish only 5 messages, so the receiver will not yet ack. $QPID_ROOT/cpp/src/tests/publish \ -p 5813 \ --count 5\ --durable yes\ --destination amq.direct \ --routing-key routing_key\ --log-enable debug #! /bin/bash
[jira] Reopened: (QPID-1611) queue durability is lost on broker-newbie sync.
[ https://issues.apache.org/jira/browse/QPID-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish reopened QPID-1611: -- My attached fix is OK wrt the Broker -- but breaks MessageStore tests. queue durability is lost on broker-newbie sync. --- Key: QPID-1611 URL: https://issues.apache.org/jira/browse/QPID-1611 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Priority: Critical Fix For: M5 Attachments: 480871.diff queue durability does not survive cluster broker newbie sync. When a new broker is syncing up with a cluster, it gets all the information it needs to preserve queue durability, But the code pathway that we go through in that case does not tell the journaling code to create a journal. This has the effect of making the queue not durable after all. ! catch attached patch ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1611) queue durability is lost on broker-newbie sync.
[ https://issues.apache.org/jira/browse/QPID-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-1611: - Attachment: (was: 480871.diff) queue durability is lost on broker-newbie sync. --- Key: QPID-1611 URL: https://issues.apache.org/jira/browse/QPID-1611 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Priority: Critical Fix For: M5 queue durability does not survive cluster broker newbie sync. When a new broker is syncing up with a cluster, it gets all the information it needs to preserve queue durability, But the code pathway that we go through in that case does not tell the journaling code to create a journal. This has the effect of making the queue not durable after all. ! catch attached patch ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1611) queue durability is lost on broker-newbie sync.
[ https://issues.apache.org/jira/browse/QPID-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-1611: - Attachment: qpid_1611.diff Previous version had problem with MessageStore code during its recovery operation. This version adds a way for the RecoverManager to tell the Queue code that we are dong a recovery -- thus avoiding a double queue creation that was messing up Store. queue durability is lost on broker-newbie sync. --- Key: QPID-1611 URL: https://issues.apache.org/jira/browse/QPID-1611 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Priority: Critical Fix For: M5 Attachments: qpid_1611.diff queue durability does not survive cluster broker newbie sync. When a new broker is syncing up with a cluster, it gets all the information it needs to preserve queue durability, But the code pathway that we go through in that case does not tell the journaling code to create a journal. This has the effect of making the queue not durable after all. ! catch attached patch ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1611) patch for BZ 480871
[ https://issues.apache.org/jira/browse/QPID-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-1611: - Attachment: 480871.diff patch for BZ 480871 --- Key: QPID-1611 URL: https://issues.apache.org/jira/browse/QPID-1611 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Priority: Critical Attachments: 480871.diff BZ 480871 queue durability does not survive cluster broker newbie sync. ! catch attached patch ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1611) queue durability is lost on broker-newbie sync.
[ https://issues.apache.org/jira/browse/QPID-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-1611: - Description: queue durability does not survive cluster broker newbie sync. When a new broker is syncing up with a cluster, it gets all the information it needs to preserve queue durability, But the code pathway that we go through in that case does not tell the journaling code to create a journal. This has the effect of making the queue not durable after all. ! catch attached patch ! was: BZ 480871 queue durability does not survive cluster broker newbie sync. ! catch attached patch ! Summary: queue durability is lost on broker-newbie sync. (was: patch for BZ 480871) queue durability is lost on broker-newbie sync. --- Key: QPID-1611 URL: https://issues.apache.org/jira/browse/QPID-1611 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Priority: Critical Attachments: 480871.diff queue durability does not survive cluster broker newbie sync. When a new broker is syncing up with a cluster, it gets all the information it needs to preserve queue durability, But the code pathway that we go through in that case does not tell the journaling code to create a journal. This has the effect of making the queue not durable after all. ! catch attached patch ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
