[jira] Created: (QPID-1793) AMQChannel.requeue() will not process all messages if an error occurs during processing
AMQChannel.requeue() will not process all messages if an error occurs during processing --- Key: QPID-1793 URL: https://issues.apache.org/jira/browse/QPID-1793 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: M4, M3 Reporter: Martin Ritchie Assignee: Martin Ritchie Fix For: 0.5 Summary: There is no try/catch in the requeue/dequeueAndDelete loop so if an error occurs during processing then subsequent messages will not be processed. The error will also not be propagated to the client as the requeue() method is called as part of the channel close procedure. Here it makes more sense to record and log the errors and attempt to process every message. Once each message has been attempted once then we can throw the first exception received. -- 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-1794) BaseTransactionLog does not clear the dequeueMap in the StoreContext after processing non-transactionally
BaseTransactionLog does not clear the dequeueMap in the StoreContext after processing non-transactionally - Key: QPID-1794 URL: https://issues.apache.org/jira/browse/QPID-1794 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Martin Ritchie Assignee: Martin Ritchie Priority: Blocker Fix For: 0.5 Summary: When processing a dequeue, non-transaction, of a message that is on multiple queues the dequeueMap on the StoreContext is not cleared after processing. Either processDequeues should remove the message as it processes them or context.commitTransaction() should be called afterwards to clear the map. As the Context is bound to the session it should only be accessed by one thread at a time so either approach will be safe. With our future goal of renaming StoreContext to Transaction and having all operations go through this object rather than directly to the TransactionLog it may make sense to have the messageIDs removed as they are processed. -- 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-1645) Kerberos auth support for the java client
[ https://issues.apache.org/jira/browse/QPID-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned QPID-1645: Assignee: Jan Sarenik (was: Rajith Attapattu) Kerberos auth support for the java client - Key: QPID-1645 URL: https://issues.apache.org/jira/browse/QPID-1645 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: M4 Reporter: Rajith Attapattu Assignee: Jan Sarenik Fix For: 0.5 Currently the 0-8 java client only supports PLAIN and cram-MD5 as authentication mechanisms. The 0-10 java client only uses PLAIN. It would be good to add Keberos as an authentication mechanism to the java client. -- 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] Issue Comment Edited: (QPID-1645) Kerberos auth support for the java client
[ https://issues.apache.org/jira/browse/QPID-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12696946#action_12696946 ] Jan Sarenik edited comment on QPID-1645 at 4/8/09 2:17 AM: --- I am about to verify the Java client kerberos SASL auth works. was (Author: jasan): I am about to verify the Java client SASL auth works. Kerberos auth support for the java client - Key: QPID-1645 URL: https://issues.apache.org/jira/browse/QPID-1645 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: M4 Reporter: Rajith Attapattu Assignee: Rajith Attapattu Fix For: 0.5 Currently the 0-8 java client only supports PLAIN and cram-MD5 as authentication mechanisms. The 0-10 java client only uses PLAIN. It would be good to add Keberos as an authentication mechanism to the java client. -- 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
Re: Trying to build the broker on F10
On Wed, Apr 08, 2009 at 11:52:12AM +0100, Gordon Sim wrote: Ján Sáreník wrote: even the releases (M4) require you to run bootstrap which is really bad example of GNU autotools usage. I don't believe that is the case. The cpp M4 tarball[1] only requires ./configure. Sorry, I was checking only all-in-one tarball at: http://www.apache.org/dist/qpid/M4/qpid-M4.tar.gz Jasan - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Trying to build the broker on F10
Jonathan Robie wrote: Bryan Kearney wrote: I am trying to build the latest cpp on f10. Running configure I get the following error: ./configure: line 1870: syntax error near unexpected token `dist-bzip2' ./configure: line 1870: `AM_INIT_AUTOMAKE(dist-bzip2 subdir-objects)' I am not an autoconf guy.. can this build on f10? Me neither, but did you run ./bootstrap before you ran ./configure? Jonathan I had not.. but this is what I got when I ran it. I still get the configure error after it. [bkear...@localhost cpp]$ ./bootstrap configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found. configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE, configure.ac: that aclocal.m4 is present in the top-level directory, configure.ac: and that aclocal.m4 was recently regenerated (using aclocal). /usr/share/automake-1.10/am/depend2.am: am__fastdepCXX does not appear in AM_CONDITIONAL /usr/share/automake-1.10/am/depend2.am: The usual way to define `am__fastdepCXX' is to add `AC_PROG_CXX' /usr/share/automake-1.10/am/depend2.am: to `configure.ac' and run `aclocal' and `autoconf' again. /usr/share/automake-1.10/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.10/am/depend2.am: The usual way to define `AMDEP' is to add one of the compiler tests /usr/share/automake-1.10/am/depend2.am: AC_PROG_CC, AC_PROG_CXX, AC_PROG_CXX, AC_PROG_OBJC, /usr/share/automake-1.10/am/depend2.am: AM_PROG_AS, AM_PROG_GCJ, AM_PROG_UPC /usr/share/automake-1.10/am/depend2.am: to `configure.ac' and run `aclocal' and `autoconf' again. src/Makefile.am: object `Event.lo' created by `qpid/console/Event.cpp' and `qpid/cluster/Event.cpp' src/Makefile.am: object `Connection.lo' created by `qpid/amqp_0_10/Connection.cpp' and `qpid/cluster/Connection.cpp' src/Makefile.am: object `Broker.lo' created by `qpid/broker/Broker.cpp' and `qpid/console/Broker.cpp' src/Makefile.am: object `ExpiryPolicy.lo' created by `qpid/broker/ExpiryPolicy.cpp' and `qpid/cluster/ExpiryPolicy.cpp' src/Makefile.am: object `Connection.lo' created by `qpid/broker/Connection.cpp' and `qpid/cluster/Connection.cpp' src/Makefile.am: object `SessionManager.lo' created by `qpid/broker/SessionManager.cpp' and `qpid/console/SessionManager.cpp' src/Makefile.am: object `SystemInfo.lo' created by `qpid/sys/solaris/SystemInfo.cpp' and `qpid/sys/posix/SystemInfo.cpp' src/Makefile.am: object `SessionState.lo' created by `qpid/SessionState.cpp' and `qpid/broker/SessionState.cpp' src/Makefile.am: object `SessionHandler.lo' created by `qpid/amqp_0_10/SessionHandler.cpp' and `qpid/broker/SessionHandler.cpp' src/Makefile.am: object `Options.lo' created by `qpid/log/Options.cpp' and `qpid/Options.cpp' src/Makefile.am: object `Shlib.lo' created by `qpid/sys/Shlib.cpp' and `qpid/sys/posix/Shlib.cpp' src/Makefile.am: object `Timer.lo' created by `qpid/sys/Timer.cpp' and `qpid/broker/Timer.cpp' /usr/share/automake-1.10/am/depend2.am: am__fastdepCC does not appear in AM_CONDITIONAL /usr/share/automake-1.10/am/depend2.am: The usual way to define `am__fastdepCC' is to add `AC_PROG_CC' /usr/share/automake-1.10/am/depend2.am: to `configure.ac' and run `aclocal' and `autoconf' again. [bkear...@localhost cpp]$ ls aclocal.m4 build-aux DESIGNINSTALL make-dist qpid-autotools-install rubygen xml autom4te.cache config.logdocs INSTALL-WINDOWS Makefile.am qpid-config.in src boost-1.32-support configure etc LICENSE managementgen README SSL bootstrap configure.ac examples m4 NOTICE RELEASE_NOTES versions [bkear...@localhost cpp]$ ./configure ./configure: line 1870: syntax error near unexpected token `dist-bzip2' ./configure: line 1870: `AM_INIT_AUTOMAKE(dist-bzip2 subdir-objects)' [bkear...@localhost cpp]$ ./configure --prefix=/usr/local ./configure: line 1870: syntax error near unexpected token `dist-bzip2' ./configure: line 1870: `AM_INIT_AUTOMAKE(dist-bzip2 subdir-objects)' [bkear...@localhost cpp]$ sudo ./configure --prefix=/usr/local ./configure: line 1870: syntax error near unexpected token `dist-bzip2' ./configure: line 1870: `AM_INIT_AUTOMAKE(dist-bzip2 subdir-objects)' [bkear...@localhost cpp]$ - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Trying to build the broker on F10
Ján Sáreník wrote: On Wed, Apr 08, 2009 at 11:52:12AM +0100, Gordon Sim wrote: Ján Sáreník wrote: even the releases (M4) require you to run bootstrap which is really bad example of GNU autotools usage. I don't believe that is the case. The cpp M4 tarball[1] only requires ./configure. Sorry, I was checking only all-in-one tarball at: http://www.apache.org/dist/qpid/M4/qpid-M4.tar.gz Yes, thats just an export of the svn tree I think and not in my view particularly useful as a release artifact (especially not for the c++ components as you point out). - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Trying to build the broker on F10
Ján Sáreník wrote: even the releases (M4) require you to run bootstrap which is really bad example of GNU autotools usage. I don't believe that is the case. The cpp M4 tarball[1] only requires ./configure. [1] http://www.apache.org/dist/qpid/M4/qpid-cpp-M4.tar.gz - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-1795) After first message rejected because queue is full, all subsequent messages rejected as well , even though queue goes down in size afterward
After first message rejected because queue is full, all subsequent messages rejected as well , even though queue goes down in size afterward Key: QPID-1795 URL: https://issues.apache.org/jira/browse/QPID-1795 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.5 Reporter: Jeff Stein After the first time I get a message rejected from the queue because the queue is full, all subsequent messages get rejected as well, even if during the interim the queue has shrunk in size a lot. Also, is there some sort of forum or mailing list I can present my problems to before I bug them? My last two bugs turned out to be non-bugs, so I think that'd probably the better approach for me. -- 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] Commented: (QPID-1795) After first message rejected because queue is full, all subsequent messages rejected as well , even though queue goes down in size afterward
[ https://issues.apache.org/jira/browse/QPID-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12697028#action_12697028 ] Robert Gemmell commented on QPID-1795: -- Hi, you can find information and archives for the mailing lists at: http://qpid.apache.org/mailing-lists.html After first message rejected because queue is full, all subsequent messages rejected as well , even though queue goes down in size afterward Key: QPID-1795 URL: https://issues.apache.org/jira/browse/QPID-1795 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.5 Reporter: Jeff Stein After the first time I get a message rejected from the queue because the queue is full, all subsequent messages get rejected as well, even if during the interim the queue has shrunk in size a lot. Also, is there some sort of forum or mailing list I can present my problems to before I bug them? My last two bugs turned out to be non-bugs, so I think that'd probably the better approach for me. -- 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] Assigned: (QPID-1784) Inhaler and Purger threads will not stop running once started
[ https://issues.apache.org/jira/browse/QPID-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie reassigned QPID-1784: Assignee: Aidan Skinner (was: Martin Ritchie) Hi Aidan, can you review this change please. Inhaler and Purger threads will not stop running once started - Key: QPID-1784 URL: https://issues.apache.org/jira/browse/QPID-1784 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Martin Ritchie Assignee: Aidan Skinner Priority: Blocker Fix For: 0.5 Summary: The controls that determine when the purging and inhaling stop. Are wrong. The Inhaler will continue trying to fill memory until it can get memory==maxMemory. This however means that if the next message won't fit in memory it will stop and reschedule to try and put that message back in again. Hoping that someone has consumed data so it will fit. The Inhaler should just stop at this stage. The purger starts when memory is over maxMemory and should not stop until it under maxMemory. However if the the messages do not neatly fit in to memory such that inMemory == maxMemory then the last message that puts us over the limit is not purged causing us to run again. -- 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