[jira] [Resolved] (QPID-3284) Removed unused variables, which caused the build to break under GCC 4.6
[ https://issues.apache.org/jira/browse/QPID-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-3284. --- Resolution: Fixed Fix Version/s: (was: Future) 0.11 Committed as very similar but more extensive patch I was already working on. > Removed unused variables, which caused the build to break under GCC 4.6 > --- > > Key: QPID-3284 > URL: https://issues.apache.org/jira/browse/QPID-3284 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: 0.10 > Environment: Fedora 15 x86_64. >Reporter: Darryl L. Pierce >Assignee: Andrew Stitcher >Priority: Blocker > Fix For: 0.11 > > Attachments: 0001-Removed-unused-variables.patch, > 0001-Removed-unused-variables.patch > > > There were several variables that were declared and assigned values but whose > values were not used. This caused GCC 4.6.0 to raise a warning, which causes > the build to stop. > This patch removes those unused variables. -- 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-3295) Under some conditions autoconf incorrectly detects that gcc doesn't support -Werror
[ https://issues.apache.org/jira/browse/QPID-3295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-3295: -- Component/s: Build Tools > Under some conditions autoconf incorrectly detects that gcc doesn't support > -Werror > --- > > Key: QPID-3295 > URL: https://issues.apache.org/jira/browse/QPID-3295 > Project: Qpid > Issue Type: Bug > Components: Build Tools >Affects Versions: 0.8, 0.10 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Labels: autoconf, gcc > Fix For: 0.11 > > > If CFLAGS or CXXFLAGS contains "-Wall" when running configure, autoconf > incorrectly detects that gcc doesn't support -Werror > This is problematic because it is an important aspect of our policy that > there should be no compiler warnings, and this bug stops this being enforced. > Notably, the fedora package build has this issue and has been shipping with > some unnoticed warnings for a while. -- 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-3295) Under some conditions autoconf incorrectly detects that gcc doesn't support -Werror
[ https://issues.apache.org/jira/browse/QPID-3295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-3295. --- Resolution: Fixed Fix Version/s: 0.11 > Under some conditions autoconf incorrectly detects that gcc doesn't support > -Werror > --- > > Key: QPID-3295 > URL: https://issues.apache.org/jira/browse/QPID-3295 > Project: Qpid > Issue Type: Bug >Affects Versions: 0.8, 0.10 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Labels: autoconf, gcc > Fix For: 0.11 > > > If CFLAGS or CXXFLAGS contains "-Wall" when running configure, autoconf > incorrectly detects that gcc doesn't support -Werror > This is problematic because it is an important aspect of our policy that > there should be no compiler warnings, and this bug stops this being enforced. > Notably, the fedora package build has this issue and has been shipping with > some unnoticed warnings for a while. -- 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-3284) Removed unused variables, which caused the build to break under GCC 4.6
[ https://issues.apache.org/jira/browse/QPID-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned QPID-3284: -- Assignee: Andrew Stitcher (was: Ted Ross) > Removed unused variables, which caused the build to break under GCC 4.6 > --- > > Key: QPID-3284 > URL: https://issues.apache.org/jira/browse/QPID-3284 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: 0.10 > Environment: Fedora 15 x86_64. >Reporter: Darryl L. Pierce >Assignee: Andrew Stitcher >Priority: Blocker > Fix For: Future > > Attachments: 0001-Removed-unused-variables.patch, > 0001-Removed-unused-variables.patch > > > There were several variables that were declared and assigned values but whose > values were not used. This caused GCC 4.6.0 to raise a warning, which causes > the build to stop. > This patch removes those unused variables. -- 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-3295) Under some conditions autoconf incorrectly detects that gcc doesn't support -Werror
[ https://issues.apache.org/jira/browse/QPID-3295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045589#comment-13045589 ] Andrew Stitcher commented on QPID-3295: --- Since -Werror has been supported in every gcc version since at least 2.95 I think it's safe to enable -Werror unconditionally if the compiler is gcc. > Under some conditions autoconf incorrectly detects that gcc doesn't support > -Werror > --- > > Key: QPID-3295 > URL: https://issues.apache.org/jira/browse/QPID-3295 > Project: Qpid > Issue Type: Bug >Affects Versions: 0.8, 0.10 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Labels: autoconf, gcc > > If CFLAGS or CXXFLAGS contains "-Wall" when running configure, autoconf > incorrectly detects that gcc doesn't support -Werror > This is problematic because it is an important aspect of our policy that > there should be no compiler warnings, and this bug stops this being enforced. > Notably, the fedora package build has this issue and has been shipping with > some unnoticed warnings for a while. -- 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-3295) Under some conditions autoconf incorrectly detects that gcc doesn't support -Werror
[
https://issues.apache.org/jira/browse/QPID-3295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045588#comment-13045588
]
Andrew Stitcher commented on QPID-3295:
---
Configure.ac uses the gl_COMPILER_FLAGS macro to test whether the compiler
accepts a particular flag. However the program it uses to test compile has an
unused variable in it.
The program is:
int main() {
int x;
;
return 0;
}
when compiled with -Wall -Werror this program reports an error and so autoconf
thinks that -Werror isn't a valid flags for gcc
> Under some conditions autoconf incorrectly detects that gcc doesn't support
> -Werror
> ---
>
> Key: QPID-3295
> URL: https://issues.apache.org/jira/browse/QPID-3295
> Project: Qpid
> Issue Type: Bug
>Affects Versions: 0.8, 0.10
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Labels: autoconf, gcc
>
> If CFLAGS or CXXFLAGS contains "-Wall" when running configure, autoconf
> incorrectly detects that gcc doesn't support -Werror
> This is problematic because it is an important aspect of our policy that
> there should be no compiler warnings, and this bug stops this being enforced.
> Notably, the fedora package build has this issue and has been shipping with
> some unnoticed warnings for a while.
--
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-3295) Under some conditions autoconf incorrectly detects that gcc doesn't support -Werror
Under some conditions autoconf incorrectly detects that gcc doesn't support -Werror --- Key: QPID-3295 URL: https://issues.apache.org/jira/browse/QPID-3295 Project: Qpid Issue Type: Bug Affects Versions: 0.10, 0.8 Reporter: Andrew Stitcher Assignee: Andrew Stitcher If CFLAGS or CXXFLAGS contains "-Wall" when running configure, autoconf incorrectly detects that gcc doesn't support -Werror This is problematic because it is an important aspect of our policy that there should be no compiler warnings, and this bug stops this being enforced. Notably, the fedora package build has this issue and has been shipping with some unnoticed warnings for a while. -- 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-3294) .NET Binding for Messaging keeps connections open after connection.Close()
.NET Binding for Messaging keeps connections open after connection.Close()
--
Key: QPID-3294
URL: https://issues.apache.org/jira/browse/QPID-3294
Project: Qpid
Issue Type: Bug
Components: Dot Net Client
Affects Versions: 0.10
Environment: .NET using binding
Reporter: Chuck Rolke
Assignee: Chuck Rolke
Calling connection.Close() does not close the connection to the broker.
Connection c = new Connection("localhost:5672");
for (int i=0; i<10; i++) {
c.Open();
c.Close();
}
leaves 10 TCP connections open to the broker.
Reported by Joe (paperman at gmx.at)
--
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-1013) Documentation on running Qpid Management Console within Eclipse is Required
[ https://issues.apache.org/jira/browse/QPID-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed QPID-1013. Resolution: Won't Fix Closing out old issue. > Documentation on running Qpid Management Console within Eclipse is Required > --- > > Key: QPID-1013 > URL: https://issues.apache.org/jira/browse/QPID-1013 > Project: Qpid > Issue Type: Improvement > Components: Java Management : JMX Console >Reporter: Senaka Fernando >Assignee: Robbie Gemmell >Priority: Minor > > Documentation on running Qpid Management Console within Eclipse is Required -- 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-1802) [Java broker] failure to startup when recovering persistent messages from store for a queue in the configuration file which was not previously added to the store
[ https://issues.apache.org/jira/browse/QPID-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-1802. -- Resolution: Fixed Closing out old issue. > [Java broker] failure to startup when recovering persistent messages from > store for a queue in the configuration file which was not previously added to > the store > - > > Key: QPID-1802 > URL: https://issues.apache.org/jira/browse/QPID-1802 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.5 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.6 > > Attachments: test-store_after_restart.zip, > test-store_before_restart.zip > > > This seems similar to QPID-1730, but raising new JIRA as that is currently > ready to review, and the files in question have since been modified for other > issues so this could be new. > Steps taken: > Start broker (trunk, r763963) configured to use BDB message store (r3265) > with the persistent_config.xml. > Start JMS Direct example consumer, having modified 'direct.properties' file > to use the 'ping' queue configured on the 'test' virtualhost in > virtualhosts.xml > Terminate consumer. > Start modified JMS Direct example producer, send '100' (so actually 101 with > the completion message) persistent messages > Shutdown broker > Restart broker > Result: > 2009-04-10 16:48:57,688 WARN [main] management.JMXManagedObjectRegistry > (JMXManagedObjectRegistry.java:187) - Starting JMX ConnectorServer on port > '8999' (+9099) with SSL > Error initialising message broker: org.apache.qpid.AMQException: Error > recovering persistent state: org.apache.qpid.AMQException: Error registering > managed object ping[Queue]: javax.management.InstanceAlreadyExistsException: > org.apache.qpid:type=VirtualHost.Queue,VirtualHost=test,name=ping,version=2org.apache.qpid.AMQException: > Error recovering persistent state: org.apache.qpid.AMQException: Error > registering managed object ping[Queue]: > javax.management.InstanceAlreadyExistsException: > org.apache.qpid:type=VirtualHost.Queue,VirtualHost=test,name=ping,version=2 > 2009-04-10 16:48:58,436 ERROR [main] server.Main (Main.java:204) - Error > initialising message broker: org.apache.qpid.AMQException: Error recovering > persistent state: org.apache.qpid.AMQException: Error registering managed > object ping[Queue]: javax.management.InstanceAlreadyExistsException: > org.apache.qpid:type=VirtualHost.Queue,VirtualHost=test,name=ping,version=2 > at > org.apache.qpid.server.store.berkeleydb.BDBMessageStore.recover(BDBMessageStore.java:1283) > at > org.apache.qpid.server.store.berkeleydb.BDBMessageStore.configure(BDBMessageStore.java:247) > at > org.apache.qpid.server.store.berkeleydb.BDBMessageStore.configure(BDBMessageStore.java:211) > at > org.apache.qpid.server.virtualhost.VirtualHost.initialiseTransactionLog(VirtualHost.java:299) > at > org.apache.qpid.server.virtualhost.VirtualHost.(VirtualHost.java:221) > at > org.apache.qpid.server.virtualhost.VirtualHost.(VirtualHost.java:162) > at > org.apache.qpid.server.registry.ConfigurationFileApplicationRegistry.initialiseVirtualHosts(ConfigurationFileApplicationRegistry.java:71) > at > org.apache.qpid.server.registry.ConfigurationFileApplicationRegistry.initialise(ConfigurationFileApplicationRegistry.java:63) > at > org.apache.qpid.server.registry.ApplicationRegistry.initialise(ApplicationRegistry.java:100) > at > org.apache.qpid.server.registry.ApplicationRegistry.initialise(ApplicationRegistry.java:88) > at org.apache.qpid.server.Main.startup(Main.java:269) > at org.apache.qpid.server.Main.execute(Main.java:193) > at org.apache.qpid.server.Main.(Main.java:93) > at org.apache.qpid.server.Main.main(Main.java:440) > Caused by: org.apache.qpid.AMQException: Error registering managed object > ping[Queue]: javax.management.InstanceAlreadyExistsException: > org.apache.qpid:type=VirtualHost.Queue,VirtualHost=test,name=ping,version=2 > at > org.apache.qpid.server.management.DefaultManagedObject.register(DefaultManagedObject.java:76) > at > org.apache.qpid.server.queue.SimpleAMQQueue.(SimpleAMQQueue.java:151) > at > org.apache.qpid.server.queue.SimpleAMQQueue.(SimpleAMQQueue.java:117) > at > org.apache.qpid.server.queue.AMQQueueFactory.createAMQQueueImpl(AMQQueueFactory.java:71) > at > org.apache.qpid.server.store.berkeleydb.BDBMessageStore.deliverMessages(BDBMessageStore.java:1645) > at > org.apache.qpid.server.store.berkeleydb.BDBMessageStore.recover(BDBMessageStore.java:1269) > ... 13 more > Ca
[jira] [Resolved] (QPID-2177) Allow for configuration of producer flow control queue properties through Management Console
[ https://issues.apache.org/jira/browse/QPID-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-2177. -- Resolution: Fixed Closing out ancient issue. > Allow for configuration of producer flow control queue properties through > Management Console > > > Key: QPID-2177 > URL: https://issues.apache.org/jira/browse/QPID-2177 > Project: Qpid > Issue Type: New Feature > Components: Java Management : JMX Interface >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 0.6 > > > The Java Broker now supports a simplistic producer side flow control model > governed by setting limits on how large a queue may grow. > Broker queues now have two new properties: > capacity : the size in bytes at which the queue is considered "full" and all > channels sending > messages to the queue will (on next send) be sent a flow > control message > flowResumeCapcity: the size at which, when reached, blocked sessions will be > unflowed (presuming >there is no other reason why the > session has been flow controlled). > Currently these properties can be set on queue creation (either through the > queue.declare arguments, or in the XML configuration) but cannot be modified > through the management console. > The Queue MBean needs to be altered to allow access to these properties -- 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-2097) InVM JMX Console appears to have problems starting up/shutting down.
[ https://issues.apache.org/jira/browse/QPID-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-2097. -- Resolution: Fixed Closing out ancient issue. > InVM JMX Console appears to have problems starting up/shutting down. > > > Key: QPID-2097 > URL: https://issues.apache.org/jira/browse/QPID-2097 > Project: Qpid > Issue Type: Bug > Components: Java Broker, Java Management : JMX Interface >Reporter: Martin Ritchie >Assignee: Robbie Gemmell > > Summary: > Running queue.ModelTest InVM results in alternating Pass/Fails. The even > tests will always fail to get a JMX Connection however, the by the time the > next test starts it will have cleared up the issue and the new JMX interface > will be ok. > So while QPID-2094 has enabled the ability to use the JMX interface from an > InVM test case it appears that there are problems with the > registration/unregistration of the JMX Server components. -- 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-2209) FailedDequeueException whilst clearing queue of messages moved/copied from another queue
[ https://issues.apache.org/jira/browse/QPID-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-2209. -- Resolution: Fixed Closing out old issue. > FailedDequeueException whilst clearing queue of messages moved/copied from > another queue > > > Key: QPID-2209 > URL: https://issues.apache.org/jira/browse/QPID-2209 > Project: Qpid > Issue Type: Bug > Components: Java Broker, Java Management : JMX Interface >Affects Versions: 0.5 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 0.6 > > > Whilst testing the updated management console, attempt was made to clear the > queues used previously as destinations to test copying and moving messages > between queues. The originating queue had previously been cleared without > issue, however attempting to clear the queues to which the messages were > moved/copied resulted in a FailedDequeueException. > This may relate to a difference in treatment of persistent messages between > their initial delivery to the broker, and when they are moved/copied. > Currently all persistent messages are entered into the store on arrival at > the broker, regardless of whether the queue they are destined for is durable. > When moving/copying, the queue durability is also checke, and so the messages > that threw the FailedDequeueException (but apprently were dequeued) had not > been entered into the store for the destination queue as the queue was not > durable. -- 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-2172) [Java] Merge race condition fixes from trunk to 0.5.x-dev branch
[ https://issues.apache.org/jira/browse/QPID-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-2172. -- Resolution: Fixed Closing out old issue. > [Java] Merge race condition fixes from trunk to 0.5.x-dev branch > > > Key: QPID-2172 > URL: https://issues.apache.org/jira/browse/QPID-2172 > Project: Qpid > Issue Type: Bug > Components: Java Broker, Java Client >Reporter: Rob Godfrey >Assignee: Robbie Gemmell > > Work on the Java 0-10 broker resulted in a number of race conditions being > address - these should be backported to the 0.5.x branch > In particular fixes can be found in r829414 (client closing race condition) > or r829575 (Broker race condition) -- 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-2096) ExchangeRegistration shoud NOT automatically add durable Exchanges to messageStore
[ https://issues.apache.org/jira/browse/QPID-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-2096. -- Resolution: Fixed Closing out old issue. > ExchangeRegistration shoud NOT automatically add durable Exchanges to > messageStore > -- > > Key: QPID-2096 > URL: https://issues.apache.org/jira/browse/QPID-2096 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: M4, 0.5, 0.6 >Reporter: Martin Ritchie >Assignee: Robbie Gemmell >Priority: Blocker > Fix For: 0.6 > > Attachments: QPID-2096_trunk.patch > > > Summary: > DefaultExchangeRegistry.registerExchange() has a side effect of calling > messageStore.createExchange. > This behaviour is unexpected as DefaultQueueRegistry does not do the same for > queues. > The problem that this has is that on MessageStore recovery the recovered > exchanges will be registered. Which after the MessageStore has been recovered > will cause createExchange to be called. The problem here is that the > createExchange interface is not designed to cope with duplicates. Something > that Derby highlights as it throws primary key constraint violation error. > The solution is to decouple register and create as has been done with queues. > This has not previously been seen as a) the Derby test profile is not run as > often and b) the configuration used did not have an additional durable > exchange defined. -- 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-2250) copying messages to a new queue only works with a persistent message and a durable queue
[ https://issues.apache.org/jira/browse/QPID-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-2250. -- Resolution: Fixed Closing out old issue. > copying messages to a new queue only works with a persistent message and a > durable queue > > > Key: QPID-2250 > URL: https://issues.apache.org/jira/browse/QPID-2250 > Project: Qpid > Issue Type: Bug > Components: Java Broker, Java Management : JMX Interface >Affects Versions: 0.6 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.6 > > > Following changes to the transaction processing with the 0-10 additions, > copying messages to a new queue using the JMX interface only works with a > persistent message and a durable destination 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] [Resolved] (QPID-2449) bindings are not removed from the persistent store when a durable queue bound to a durable exchange is deleted
[ https://issues.apache.org/jira/browse/QPID-2449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-2449. -- Resolution: Fixed Closing out old issue. > bindings are not removed from the persistent store when a durable queue bound > to a durable exchange is deleted > -- > > Key: QPID-2449 > URL: https://issues.apache.org/jira/browse/QPID-2449 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: M2, M2.1, M3, M4, 0.5 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.6 > > > When a queue is deleted any bindings are also deleted. However, they are not > removed from the persistent store if they have been added previously. If the > same queue name is then used in future and the broker later restarted these > bindings can be recovered and lead to unexpected behaviour. For example this > can lead to problems with durable subscriptions when the same subscription > name is used over time for differing subscriptions (eg without selectors > initially, and then with selectors later). > 0.6 and trunk is no longer affected, however the 0.5.x branch is. -- 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-2400) QMF NullPointerException on broker shutdown.
[ https://issues.apache.org/jira/browse/QPID-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-2400. -- Resolution: Fixed Fix Version/s: 0.6 Closing out old issue. > QMF NullPointerException on broker shutdown. > > > Key: QPID-2400 > URL: https://issues.apache.org/jira/browse/QPID-2400 > Project: Qpid > Issue Type: Bug > Components: Java Broker, Java Management : QMF >Reporter: Martin Ritchie >Assignee: Robbie Gemmell > Fix For: 0.6 > > > The broker failed to bind throwing: > BROKER: main 2010-02-10 13:24:30,472 ERROR [Qpid.Broker] Error initialising > message broker: java.net.BindException: Could not bind to > 0.0.0.0/0.0.0.0:15672 > BROKER: java.net.BindException: Could not bind to 0.0.0.0/0.0.0.0:15672 > BROKER: at > org.apache.qpid.transport.network.mina.MINANetworkDriver.bind(MINANetworkDriver.java:165) > BROKER: at org.apache.qpid.server.Main.startup(Main.java:431) > BROKER: at org.apache.qpid.server.Main.execute(Main.java:233) > BROKER: at org.apache.qpid.server.Main.(Main.java:104) > BROKER: at org.apache.qpid.server.Main.main(Main.java:541) > So when it then goes to shutdown the QMF throws a NPE. > BROKER: java.lang.NullPointerException > BROKER: at > java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) > BROKER: at > org.apache.qpid.qmf.QMFService.unmanageObject(QMFService.java:417) > BROKER: at org.apache.qpid.qmf.QMFService.onEvent(QMFService.java:395) > BROKER: at > org.apache.qpid.server.configuration.ConfigStore.sendEvent(ConfigStore.java:149) > BROKER: at > org.apache.qpid.server.configuration.ConfigStore.removeConfiguredObject(ConfigStore.java:111) > BROKER: at > org.apache.qpid.server.configuration.SystemConfigImpl.removeBroker(SystemConfigImpl.java:128) > BROKER: at > org.apache.qpid.server.registry.ApplicationRegistry.remove(ApplicationRegistry.java:198) > BROKER: at > org.apache.qpid.server.registry.ApplicationRegistry.removeAll(ApplicationRegistry.java:217) > BROKER: at org.apache.qpid.server.Main.shutdown(Main.java:254) > BROKER: at org.apache.qpid.server.Main.execute(Main.java:247) > BROKER: at org.apache.qpid.server.Main.(Main.java:104) > BROKER: at org.apache.qpid.server.Main.main(Main.java:541) > Now I can't tell if the broker always fails to shutdown QMF as the test > profiles do not cleanly shutdown the broker. QTC test do an effective kill -9 > on the external 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] [Resolved] (QPID-3166) add system test using multiple producers with batched transactions and multiple consumers with unique selectors
[ https://issues.apache.org/jira/browse/QPID-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-3166. -- Resolution: Fixed Closing out old issue. > add system test using multiple producers with batched transactions and > multiple consumers with unique selectors > --- > > Key: QPID-3166 > URL: https://issues.apache.org/jira/browse/QPID-3166 > Project: Qpid > Issue Type: Sub-task > Components: Java Tests >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.11 > > > Add system test using multiple producers with batched transactions and > multiple consumers with unique selectors -- 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-3274) Jenkins CI - JMX test failures under Solaris
[
https://issues.apache.org/jira/browse/QPID-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045479#comment-13045479
]
Robbie Gemmell commented on QPID-3274:
--
The hostname does appear to be the cause of the failures, yes. This will
probably warrant discussion with infra to have the hostname made legal on the
boxes.
> Jenkins CI - JMX test failures under Solaris
>
>
> Key: QPID-3274
> URL: https://issues.apache.org/jira/browse/QPID-3274
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Tests
>Affects Versions: 0.11
> Environment: Solaris/Hudson
>Reporter: Keith Wall
>Assignee: Keith Wall
> Labels: Hudson, Jenkins, Solaris
> Fix For: 0.11
>
>
> Andrew K noticed whilst setting up Qpid under Hudson that the JMX tests fail
> under Hudson on Solaris.
> The first error was:
> https://builds.apache.org/hudson/view/M-R/view/Qpid/job/qpid-java-build/3/testReport/junit/org.apache.qpid.management.jmx/ManagementActorLoggingTest/testJMXManagementConsoleConnection/
> {code}
> java.net.MalformedURLException: Bad URL path:
> _solaris:30099/jndi/rmi://hudson_solaris:2/jmxrmi
> {code}
> followed by many instances of:
> https://builds.apache.org/hudson/view/M-R/view/Qpid/job/qpid-java-build/3/testReport/junit/org.apache.qpid.management.jmx/ManagementActorLoggingTest/testConnectionCloseViaManagement/
> {code}
> internal error: ObjID already in use
> {code}
> The full list of test failures is recorded here:
> https://builds.apache.org/hudson/view/M-R/view/Qpid/job/qpid-java-build/3/#showFailuresLink
> I tried the test cases standalone under OpenSolaris 11 and could not
> reproduce the problem.
> However, I notice that the initial error looks very much like the issue
> discussed here:
> http://apache-qpid-users.2158936.n2.nabble.com/Run-qpid-0-6-broker-error-in-Linux-td5517015.html
> Is the problem just being caused by the hostname on the Solaris host in the
> Jenkins build farm?
--
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-3161) All tests using JMX fail on Solaris
[ https://issues.apache.org/jira/browse/QPID-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045477#comment-13045477 ] Robbie Gemmell commented on QPID-3161: -- Keith wall has posted a probable cause on QPID-3274. This will probably warrant discussion with infra to have the hostname made legal on the boxes. > All tests using JMX fail on Solaris > --- > > Key: QPID-3161 > URL: https://issues.apache.org/jira/browse/QPID-3161 > Project: Qpid > Issue Type: Bug > Components: Java Broker, Java Tests >Affects Versions: 0.10, 0.11 > Environment: Solaris 10 >Reporter: Andrew Kennedy >Assignee: Robbie Gemmell > > All tests that use JMX fail on Solaris 10 under the default profile. See > results here: > https://builds.apache.org/hudson/view/M-R/view/Qpid/job/qpid-java-build/3/#showFailuresLink > The stack trace is as follows: > java.rmi.server.ExportException: internal error: ObjID already in use > at sun.rmi.transport.ObjectTable.putTarget(ObjectTable.java:169) > at sun.rmi.transport.Transport.exportObject(Transport.java:74) > at > sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:229) > at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:393) > at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:129) > at > sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:190) > at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:92) > at sun.rmi.registry.RegistryImpl.(RegistryImpl.java:68) > at > java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:222) > at > org.apache.qpid.server.management.JMXManagedObjectRegistry.start(JMXManagedObjectRegistry.java:218) > at > org.apache.qpid.server.registry.ApplicationRegistry.initialise(ApplicationRegistry.java:294) > at > org.apache.qpid.server.registry.ApplicationRegistry.initialise(ApplicationRegistry.java:154) > at > org.apache.qpid.test.utils.QpidBrokerTestCase.startBroker(QpidBrokerTestCase.java:472) > at > org.apache.qpid.test.utils.QpidBrokerTestCase.startBroker(QpidBrokerTestCase.java:403) > at > org.apache.qpid.test.utils.QpidBrokerTestCase.setUp(QpidBrokerTestCase.java:301) > at > org.apache.qpid.server.security.acl.AbstractACLTestCase.setUp(AbstractACLTestCase.java:120) > at > org.apache.qpid.server.security.acl.ExternalACLJMXTest.setUp(ExternalACLJMXTest.java:57) > at > org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:234) > at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:120) -- 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-2158) [Java 0-8/0-9] Overlong AMQShortStrings incorrectly encoded and cause Frame corruption
[ https://issues.apache.org/jira/browse/QPID-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-2158. -- Resolution: Fixed Patch applied. > [Java 0-8/0-9] Overlong AMQShortStrings incorrectly encoded and cause Frame > corruption > -- > > Key: QPID-2158 > URL: https://issues.apache.org/jira/browse/QPID-2158 > Project: Qpid > Issue Type: Bug > Components: Java Common >Affects Versions: M2, M2.1, M3, M4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.10 >Reporter: Rob Godfrey >Assignee: Robbie Gemmell > Fix For: 0.11 > > Attachments: adds-amqshortstring-length-validation.patch > > > AMQP defines as shortstr as a 1-octet length followed by that many octets of > data. In java we use the AMQShortString class to represent this datatype in > the 0-8/0-9 codebase. Unfortunately the AMQShortString class does not check > to ensure that on construction its total length is less than 256 characters. > In cases where an overlong AMQShortString is created and subsequently > encoded, the size is written out as (byte) length, which means that a String > of length 296 will be encoded as an octect with value 40 (296 & 255) followed > by 296 octets of data. Upon decoding this causes a frame decoding error. > We should check on construction of an AMQShortString that the underlying data > does not have length > 255, and that if it does we should throw an > appropriate exception (IndexOutOfBoundsException?) > [This error was discovered when a long queue name was created, and that queue > subsequently used as the destination for a reply-to field... the encoding of > a reply-to copies the queue name twice (once as the queue name, once as the > binding-key] -- 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
Re: svn commit: r1132628 - /qpid/trunk/qpid/specs/management-schema.xml
Thanks for doing that. This is my error, I had completely forgotten the impact of the management schema on the java build. Sorry (and I'll make sure I don't forget next time!) Kim On Tue, 2011-06-07 at 12:24 +0100, Robbie Gemmell wrote: > I have stubbed out the newly introduced property to allow the build to > complete. > > Robbie > > On 6 June 2011 22:32, Robbie Gemmell wrote: > > This commit appears to have broken the Java broker build (and also > > doesnt have a JIRA reference): > > https://builds.apache.org/job/qpid-java-build/123/ > > > > Robbie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Qpid and AMQP 1-0: Plans?
I think we had a good discussion on this thread and some ideas/plans were floated/discussed. I am wondering where we are at in terms of the 1.0 plans ? Maybe it's a good time to restart the discussion to get some ideas about timelines or share any work that has been done in this area. Rajith On Tue, Mar 29, 2011 at 5:31 AM, Marnie McCormack < marnie.mccorm...@googlemail.com> wrote: > > > > > > > For eample, for Qpid users we want solid inter-op and upgrade as we > > > introduce AMQP > > > 1.0 and clean 0-10 1.0 inter-op for the C++ broker. For the Java broker > > > there may also > > > be a desire to also have 0-9 upgrade path. that is for those that know > > > better to comment > > > on. > > > > > > Based on my knowledge, I don't think we need a 0-9 upgrade path > specifically > - so long as on the Java side we continue to support the JMS semantics in > the same way (with particular reference to client exception handling on > send()). Perhaps more of a general issue is the gaps in feature sets as we > move forward, which we'd need to consider for 1-0 and identify which are > obstacles we should address (e.g. operational logging, flow control > mechanisms, firewalls, acls etc). > > 0-10 traffic does need to be supported in a 1-0 broker though, I think. > > Hth, > Marnie >
Re: FW: [DRAFT FOR REVIEW] [ACTION REQUIRED] www.apache.org/dist/ housekeeping
On Mon, 2011-06-06 at 18:06 -0400, Andrew Stitcher wrote: > On Mon, 2011-06-06 at 22:10 +0100, Robbie Gemmell wrote: > > Given that we dont actually link to the 0.8 files on the mirrors from > > our download page, and they will still available from the archive area > > which is linked for the purpose of getting older releases, I'd say we > > should just remove 0.8 from the mirrors if it will appease infra. > > Makes sense to me - I'll do it tomorrow if you haven't done it already. Done du tells me we're now using 165Mb - the largest users of the space are 5 java management console tars (qpid-jmx-management-console-*) each of which takes about 13-14Mb and the combined source tree tar at 56Mb. Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3228) Qpid broker JMX API allows creation of queues with queue name length greater than 255, owner name length greather than 255, routine key length greather than 255, exchange
[ https://issues.apache.org/jira/browse/QPID-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-3228: - Attachment: additional-test-cases-for-255-127-names.patch Test cases to tests JMX and JMS operations to create queues, routine keys, exchanges with length over 255 and 127. > Qpid broker JMX API allows creation of queues with queue name length greater > than 255, owner name length greather than 255, routine key length greather > than 255, exchange name length greather than 255 > - > > Key: QPID-3228 > URL: https://issues.apache.org/jira/browse/QPID-3228 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.5 >Reporter: Alex Rudyy >Assignee: Robbie Gemmell > Attachments: additional-test-cases-for-255-127-names.patch > > > Qpid broker does not have any validation of queue name length, queue owner > name length, routine key length, exchange name length. As result of this it > is possible to create queues with name or/and owner length greater then 255 > characters, exchanges with name length greater then 255, binding keys with > length exceeding 255 characters. These can be done through configuration > file, JMX API or JMX consoles. Possibility to create queues, exchanges, > routines keys with length exceeded 255 not only contradicts AMQP > specifications 0.9, 0.10 but additionally can results in BDB store corruption > when AMQShortString objects with length >255 are stored incorrectly because > of current implementation. -- 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-3228) Qpid broker JMX API allows creation of queues with queue name length greater than 255, owner name length greather than 255, routine key length greather than 255, exchange
[ https://issues.apache.org/jira/browse/QPID-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-3228: - Attachment: (was: branch-255-limitation.patch) > Qpid broker JMX API allows creation of queues with queue name length greater > than 255, owner name length greather than 255, routine key length greather > than 255, exchange name length greather than 255 > - > > Key: QPID-3228 > URL: https://issues.apache.org/jira/browse/QPID-3228 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.5 >Reporter: Alex Rudyy >Assignee: Robbie Gemmell > > Qpid broker does not have any validation of queue name length, queue owner > name length, routine key length, exchange name length. As result of this it > is possible to create queues with name or/and owner length greater then 255 > characters, exchanges with name length greater then 255, binding keys with > length exceeding 255 characters. These can be done through configuration > file, JMX API or JMX consoles. Possibility to create queues, exchanges, > routines keys with length exceeded 255 not only contradicts AMQP > specifications 0.9, 0.10 but additionally can results in BDB store corruption > when AMQShortString objects with length >255 are stored incorrectly because > of current implementation. -- 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-3228) Qpid broker JMX API allows creation of queues with queue name length greater than 255, owner name length greather than 255, routine key length greather than 255, exchange
[ https://issues.apache.org/jira/browse/QPID-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-3228: - Attachment: (was: trunk-add-255-limitation.patch) > Qpid broker JMX API allows creation of queues with queue name length greater > than 255, owner name length greather than 255, routine key length greather > than 255, exchange name length greather than 255 > - > > Key: QPID-3228 > URL: https://issues.apache.org/jira/browse/QPID-3228 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.5 >Reporter: Alex Rudyy >Assignee: Robbie Gemmell > > Qpid broker does not have any validation of queue name length, queue owner > name length, routine key length, exchange name length. As result of this it > is possible to create queues with name or/and owner length greater then 255 > characters, exchanges with name length greater then 255, binding keys with > length exceeding 255 characters. These can be done through configuration > file, JMX API or JMX consoles. Possibility to create queues, exchanges, > routines keys with length exceeded 255 not only contradicts AMQP > specifications 0.9, 0.10 but additionally can results in BDB store corruption > when AMQShortString objects with length >255 are stored incorrectly because > of current implementation. -- 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-2158) [Java 0-8/0-9] Overlong AMQShortStrings incorrectly encoded and cause Frame corruption
[ https://issues.apache.org/jira/browse/QPID-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-2158: Assignee: Robbie Gemmell > [Java 0-8/0-9] Overlong AMQShortStrings incorrectly encoded and cause Frame > corruption > -- > > Key: QPID-2158 > URL: https://issues.apache.org/jira/browse/QPID-2158 > Project: Qpid > Issue Type: Bug > Components: Java Common >Affects Versions: M2, M2.1, M3, M4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.10 >Reporter: Rob Godfrey >Assignee: Robbie Gemmell > Fix For: 0.11 > > Attachments: adds-amqshortstring-length-validation.patch > > > AMQP defines as shortstr as a 1-octet length followed by that many octets of > data. In java we use the AMQShortString class to represent this datatype in > the 0-8/0-9 codebase. Unfortunately the AMQShortString class does not check > to ensure that on construction its total length is less than 256 characters. > In cases where an overlong AMQShortString is created and subsequently > encoded, the size is written out as (byte) length, which means that a String > of length 296 will be encoded as an octect with value 40 (296 & 255) followed > by 296 octets of data. Upon decoding this causes a frame decoding error. > We should check on construction of an AMQShortString that the underlying data > does not have length > 255, and that if it does we should throw an > appropriate exception (IndexOutOfBoundsException?) > [This error was discovered when a long queue name was created, and that queue > subsequently used as the destination for a reply-to field... the encoding of > a reply-to copies the queue name twice (once as the queue name, once as the > binding-key] -- 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-2158) [Java 0-8/0-9] Overlong AMQShortStrings incorrectly encoded and cause Frame corruption
[ https://issues.apache.org/jira/browse/QPID-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-2158: - Affects Version/s: 0.6 0.7 0.8 0.9 0.10 Fix Version/s: 0.11 > [Java 0-8/0-9] Overlong AMQShortStrings incorrectly encoded and cause Frame > corruption > -- > > Key: QPID-2158 > URL: https://issues.apache.org/jira/browse/QPID-2158 > Project: Qpid > Issue Type: Bug > Components: Java Common >Affects Versions: M2, M2.1, M3, M4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.10 >Reporter: Rob Godfrey >Assignee: Robbie Gemmell > Fix For: 0.11 > > Attachments: adds-amqshortstring-length-validation.patch > > > AMQP defines as shortstr as a 1-octet length followed by that many octets of > data. In java we use the AMQShortString class to represent this datatype in > the 0-8/0-9 codebase. Unfortunately the AMQShortString class does not check > to ensure that on construction its total length is less than 256 characters. > In cases where an overlong AMQShortString is created and subsequently > encoded, the size is written out as (byte) length, which means that a String > of length 296 will be encoded as an octect with value 40 (296 & 255) followed > by 296 octets of data. Upon decoding this causes a frame decoding error. > We should check on construction of an AMQShortString that the underlying data > does not have length > 255, and that if it does we should throw an > appropriate exception (IndexOutOfBoundsException?) > [This error was discovered when a long queue name was created, and that queue > subsequently used as the destination for a reply-to field... the encoding of > a reply-to copies the queue name twice (once as the queue name, once as the > binding-key] -- 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
Re: svn commit: r1132628 - /qpid/trunk/qpid/specs/management-schema.xml
I have stubbed out the newly introduced property to allow the build to complete. Robbie On 6 June 2011 22:32, Robbie Gemmell wrote: > This commit appears to have broken the Java broker build (and also > doesnt have a JIRA reference): > https://builds.apache.org/job/qpid-java-build/123/ > > Robbie > > On 6 June 2011 14:24, wrote: >> Author: kpvdr >> Date: Mon Jun 6 13:24:11 2011 >> New Revision: 1132628 >> >> URL: http://svn.apache.org/viewvc?rev=1132628&view=rev >> Log: >> Missing spec file change to checkin 1132623 >> >> Modified: >> qpid/trunk/qpid/specs/management-schema.xml >> >> Modified: qpid/trunk/qpid/specs/management-schema.xml >> URL: >> http://svn.apache.org/viewvc/qpid/trunk/qpid/specs/management-schema.xml?rev=1132628&r1=1132627&r2=1132628&view=diff >> == >> --- qpid/trunk/qpid/specs/management-schema.xml (original) >> +++ qpid/trunk/qpid/specs/management-schema.xml Mon Jun 6 13:24:11 2011 >> @@ -255,6 +255,7 @@ >> >> >> > desc="Infrastucture/ Inter-system connection (Cluster, Federation, ...)"/> >> + > desc="Authorization to proxy for users not on broker"/> >> >> > desc="authId of connection if authentication enabled"/> >> > optional="y" desc="Name of executable running as remote client"/> >> >> >> >> - >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org >> Use/Interact: mailto:commits-subscr...@qpid.apache.org >> >> > - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Resolved] (QPID-3219) some logic used to find current/available messages may return a QueueEntry currently in the dequeued state.
[ https://issues.apache.org/jira/browse/QPID-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-3219. -- Resolution: Fixed Patch applied. > some logic used to find current/available messages may return a QueueEntry > currently in the dequeued state. > --- > > Key: QPID-3219 > URL: https://issues.apache.org/jira/browse/QPID-3219 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.5, 0.6, 0.7, 0.8, 0.9, 0.10 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.11 > > Attachments: QPID-3219-adds-dequeued-checks.patch > > > Some logic used to find current/available messages may incorrectly > gather/return a QueueEntry in the dequeued state. > The QueueEntry state model has an intermediate 'dequeued' state that the > entry will enter before being disposed of and moved to the 'deleted' state. > At present, most logic dealing with QueueEntry presence/availability checks > only that they aren't deleted or that they can be acquired (typically both > are done in the latter case, but checking the deletion is unnecessary in this > case since the acquire attempt would fail if it were deleted). There is no > intended path for a queue entry to transition from being dequeued to anything > other than the deleted state, and so any logic inspecting for > current/available messages should also disregard entries in the dequeued > state. > Areas known to be affected by the issues include the various > SimpleAMQQueue#'getMessagesOnTheQueue' type operations in used for tasks > such as viewing / copying / moving messages via JMX, and also the > QueueEntryImpl#getNext method used to traverse the QueueEntryList during > delivery operations. -- 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-3219) some logic used to find current/available messages may return a QueueEntry currently in the dequeued state.
[ https://issues.apache.org/jira/browse/QPID-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-3219: Assignee: Robbie Gemmell > some logic used to find current/available messages may return a QueueEntry > currently in the dequeued state. > --- > > Key: QPID-3219 > URL: https://issues.apache.org/jira/browse/QPID-3219 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.5, 0.6, 0.7, 0.8, 0.9, 0.10 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.11 > > Attachments: QPID-3219-adds-dequeued-checks.patch > > > Some logic used to find current/available messages may incorrectly > gather/return a QueueEntry in the dequeued state. > The QueueEntry state model has an intermediate 'dequeued' state that the > entry will enter before being disposed of and moved to the 'deleted' state. > At present, most logic dealing with QueueEntry presence/availability checks > only that they aren't deleted or that they can be acquired (typically both > are done in the latter case, but checking the deletion is unnecessary in this > case since the acquire attempt would fail if it were deleted). There is no > intended path for a queue entry to transition from being dequeued to anything > other than the deleted state, and so any logic inspecting for > current/available messages should also disregard entries in the dequeued > state. > Areas known to be affected by the issues include the various > SimpleAMQQueue#'getMessagesOnTheQueue' type operations in used for tasks > such as viewing / copying / moving messages via JMX, and also the > QueueEntryImpl#getNext method used to traverse the QueueEntryList during > delivery operations. -- 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
Re: FW: [DRAFT FOR REVIEW] [ACTION REQUIRED] www.apache.org/dist/ housekeeping
On 06/06/2011 10:10 PM, Robbie Gemmell wrote: Given that we dont actually link to the 0.8 files on the mirrors from our download page, and they will still available from the archive area which is linked for the purpose of getting older releases, I'd say we should just remove 0.8 from the mirrors if it will appease infra. I agree. I removed all the older releases when previously asked. However at that time we hadn't yet released 0.10 so I left 0.8 as the current release. I think we just need to change the release process to include deletion of the last release to avoid this building up again. Robbie On 6 June 2011 19:33, Andrew Stitcher wrote: On Mon, 2011-06-06 at 12:34 -0400, Steve Huston wrote: Who has access to qpid's /dist area and can help clean it up? I've now looked at /dist and I don't think we've got anything to clean up there - We've got only 2 releases up there 0.10 and 0.8. Which is the current and previous release. I think it is reasonable to have them both there. When we release 0.12 then we should remove 0.8. If we released 0.10.1 it would be the latest version of the current release and we should remove 0.10. Any other opinions? Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
