[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] 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: > > Exchange 'bosmyex1' (direct) > > 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: > > Exchange 'bosmyex1' (direct) > bind [unix.boston.cust] => > bridge_queue_1_8870523d-2286-408e-b5b5-50d53db2fa61 > > 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
Re: QIP: object creation and deletion via management
On 01/26/2011 07:34 PM, Alan Conway wrote:
So it seems like we have an open ended collection of concrete type
systems here:
amqp0-10
amqp1-0
amqpx-y
(stomp or whatever future protocols we support)
And we have a "generic" type system with 2 types (so far):
topic(=exchage) and queue. These are implemented in terms of whatever
concrete types are available. We want it to be easy to create objects
using the generic system, while at the same time providing "escapes" to
let the user directly create objects and tweak properties for the
underlying system if they want to. Since the set is open ended it seems
like namespaces would be appropriate here.
I see it slightly differently. I think we are talking about objects that
are in their function and purpose independent of the protocol version of
any client.
However we have inherited baggage from earlier versions of AMQP where
the protocol governing the interactions between a client and broker were
mixed up with a particular broker model. That does not mean the entities
defined by that broker model are necessarily tied to a particular
protocol version however. A queue is a queue after all. Even the concept
of exchanges and bindings need not be tied to a specific protocol.
If we follow the classic "constructor" pattern, then we should separate
identifying the type from the arguments to create an instance of that
type. The type defines the meaning of the properties so it seems a bit
murky to use a properties to determine the type.
So how about:
create(type:"topic", name:"abc", properties:{...}) - create a generic
topic using whatever underlying protocol
create(type:"amqp0-10/exchange", ...) - specify a 0-10 exchange
create(type:"stomp/foobar", ...) - specify some other protocol's object
etc.
I don't think amqp0-10 is appropriate here (I shouldn't have suggested
in the sub-type comment either). The exchange is the same for 0-8 and
0-9 as well (and the java broker supports all versions). You don't want
users to have to care about the version here. It just adds confusion.
While amqp/exchange would make more sense, I'm not convinced it is
necessary. I believe the concept of exchanges is clear and unambiguous
to those who want to think in those terms.
I think namespaces are a solution to a problem we don't have (and they
don't really solve the problem we *do* have). I'm especially
uncomfortable with tying the namespaces to specific versions of a protocol.
That leaves us open as to future type systems and gives us enough
information in the type name to determine the meaning of properties -
allowing each concrete type to define whatever set of properties with
whatever names it desires.
This also means the generic types can take a "clean" set of properties -
i.e. no "x-binding" or other protocol escapes. The generic types have a
well defined set of properties that always apply regardless of the
underlying type system - so you can write portable code.
I agree we want a 'clean' set of properties.
I don't think x-binding (or x-declare or x-subscribe) are necessary here
nor are they being proposed. Those were introduced to allow the user to
'customise' the particular interaction in interpreting and implementing
senders/receivers for a given address over a particular protocol version.
This proposal on the other hand is about the management schema that the
broker exposes in general.
I think the properties should mostly be obvious. However they aren't all
uniform between the two brokers and some are less well thought through
than others and thus more likely to be deprecated at some point in the
future.
The exchange type was a special case that seemed to me to perhaps
warrant a special name as it seemed odd to have type in the properties
as well as the object type. However on reflection that perhaps is not
such a big issue.
I'll get a list together in the next iteration of the QIP to make things
more concrete.
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [jira] Commented: (QPID-3009) Perl binding to Qpid messaging
The .NET Binding to Qpid Messaging already has a session-listener. * It is packaged as a .NET Assembly DLL separate from the rest of the .NET Binding so a user is not forced to include it. * File cpp\bindings\qpid\dotnet\src\sessionreceiver\sessionreceiver.cs holds the listener's implementation. * File cpp\bindings\qpid\dotnet\examples\csharp.map.callback.receiver\csharp.map.callback.receiver.cs shows how to use it. * In this implementation the SessionReceiver creates its own thread on which to call Messaging's session.NextReceiver() and to deliver messages to the parent application. Maybe its design and use could be a model, maybe not. Other languages may be different enough to make common usage/construction not worth the trouble. - Original Message - > From: "Ted Ross (JIRA)" > To: dev@qpid.apache.org > Sent: Thursday, January 27, 2011 11:23:44 AM > Subject: [jira] Commented: (QPID-3009) Perl binding to Qpid messaging > [ > https://issues.apache.org/jira/browse/QPID-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987628#action_12987628 > ] > > Ted Ross commented on QPID-3009: > > > I agree with Gordon that the session-listener is a separate utility. I > also agree that we should formulate a common pattern for its design > that can be used in all of the various language APIs and bindings. > > > > Perl binding to Qpid messaging > > -- > > > > Key: QPID-3009 > > URL: https://issues.apache.org/jira/browse/QPID-3009 > > Project: Qpid > > Issue Type: New Feature > > Components: C++ Client > >Affects Versions: 0.8 > > Environment: - > >Reporter: Hao Chang Yu > >Assignee: Ted Ross > > Fix For: 0.8 > > > > Attachments: QPID-3009.diff, qpid_perl.patch > > > > > > As we need to use perl programs to send amqp messages but there is > > no perl version of qpid messaging. > > Therefore, I had written a perl api to bind with c++ qpid messaging > > library. This perl api for qpid messaging is developed using swig > > and is base on qpid 0.8. > > Please see the attached patch file. > > -- > 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 - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [jira] Commented: (QPID-3009) Perl binding to Qpid messaging
On 01/27/2011 03:02 PM, Carl Trieloff wrote: On 01/27/2011 06:25 AM, Gordon Sim (JIRA) wrote: I'd be cautious with committing to a particular for of session-listener. While you may be right that it will always be language specific, I think it needs some thought and discussion on the form it should take. I don't think it is an intrinsic part of the binding that must be provided. It is a possible added utility. It is however a pattern that everyone looks for, so we should really provide utilities for this for our clients and consistent across the languages Indeed. Committing to consistent support requires wide discussion and consideration, which is what my comment was really asking for. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-3009) Perl binding to Qpid messaging
[ https://issues.apache.org/jira/browse/QPID-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987628#action_12987628 ] Ted Ross commented on QPID-3009: I agree with Gordon that the session-listener is a separate utility. I also agree that we should formulate a common pattern for its design that can be used in all of the various language APIs and bindings. > Perl binding to Qpid messaging > -- > > Key: QPID-3009 > URL: https://issues.apache.org/jira/browse/QPID-3009 > Project: Qpid > Issue Type: New Feature > Components: C++ Client >Affects Versions: 0.8 > Environment: - >Reporter: Hao Chang Yu >Assignee: Ted Ross > Fix For: 0.8 > > Attachments: QPID-3009.diff, qpid_perl.patch > > > As we need to use perl programs to send amqp messages but there is no perl > version of qpid messaging. > Therefore, I had written a perl api to bind with c++ qpid messaging library. > This perl api for qpid messaging is developed using swig and is base on qpid > 0.8. > Please see the attached patch file. -- 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] Resolved: (QPID-3013) ConnectionCloseTest fails on machines with increased processor counts
[ https://issues.apache.org/jira/browse/QPID-3013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy resolved QPID-3013. -- Resolution: Fixed Works, but we need to verify this behaviour on a machine where N_processors is large, say 128 or 256? > ConnectionCloseTest fails on machines with increased processor counts > - > > Key: QPID-3013 > URL: https://issues.apache.org/jira/browse/QPID-3013 > Project: Qpid > Issue Type: Test > Components: Java Broker, Java Client >Affects Versions: 0.8 >Reporter: Robbie Gemmell >Assignee: Andrew Kennedy >Priority: Minor > Fix For: 0.9 > > > ConnectionCloseTest fails on machines with increased processor counts. This > is because it does allow for the larger number of threads that can be > assigned to thread pools created in the MINA codebase. -- 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: [jira] Commented: (QPID-3009) Perl binding to Qpid messaging
On 01/27/2011 06:25 AM, Gordon Sim (JIRA) wrote: I'd be cautious with committing to a particular for of session-listener. While you may be right that it will always be language specific, I think it needs some thought and discussion on the form it should take. I don't think it is an intrinsic part of the binding that must be provided. It is a possible added utility. It is however a pattern that everyone looks for, so we should really provide utilities for this for our clients and consistent across the languages Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-3013) ConnectionCloseTest fails on machines with increased processor counts
[ https://issues.apache.org/jira/browse/QPID-3013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987528#action_12987528 ] Robbie Gemmell commented on QPID-3013: -- Removed the initial connection, moving its closure showed that only the encessary threads in the pools were started and so it wasnt having the desired effect of taing the pool size out of the equation afterall. Added a processor count based variable delta instead. > ConnectionCloseTest fails on machines with increased processor counts > - > > Key: QPID-3013 > URL: https://issues.apache.org/jira/browse/QPID-3013 > Project: Qpid > Issue Type: Test > Components: Java Broker, Java Client >Affects Versions: 0.8 >Reporter: Robbie Gemmell >Assignee: Andrew Kennedy >Priority: Minor > Fix For: 0.9 > > > ConnectionCloseTest fails on machines with increased processor counts. This > is because it does allow for the larger number of threads that can be > assigned to thread pools created in the MINA codebase. -- 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-3009) Perl binding to Qpid messaging
[ https://issues.apache.org/jira/browse/QPID-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987507#action_12987507 ] Gordon Sim commented on QPID-3009: -- Very much agree that a thin layer adapting to more Perl-like usage is nice. I'd be cautious with committing to a particular for of session-listener. While you may be right that it will always be language specific, I think it needs some thought and discussion on the form it should take. I don't think it is an intrinsic part of the binding that must be provided. It is a possible added utility. > Perl binding to Qpid messaging > -- > > Key: QPID-3009 > URL: https://issues.apache.org/jira/browse/QPID-3009 > Project: Qpid > Issue Type: New Feature > Components: C++ Client >Affects Versions: 0.8 > Environment: - >Reporter: Hao Chang Yu >Assignee: Ted Ross > Fix For: 0.8 > > Attachments: QPID-3009.diff, qpid_perl.patch > > > As we need to use perl programs to send amqp messages but there is no perl > version of qpid messaging. > Therefore, I had written a perl api to bind with c++ qpid messaging library. > This perl api for qpid messaging is developed using swig and is base on qpid > 0.8. > Please see the attached patch file. -- 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-3021) the Session and Connector actors should be set for events occurring on 0-10 connections
[ https://issues.apache.org/jira/browse/QPID-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-3021: Assignee: Andrew Kennedy (was: Robbie Gemmell) Andrew, can you review the changes please? Thanks. > the Session and Connector actors should be set for events occurring on 0-10 > connections > --- > > Key: QPID-3021 > URL: https://issues.apache.org/jira/browse/QPID-3021 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.8, 0.9 >Reporter: Robbie Gemmell >Assignee: Andrew Kennedy > Fix For: 0.9 > > > When addressing QPID-3014 it was noticed that the Session and Connector > actors were not being set appropriately when processing events arriving on > 0-10 connections. As a result, logging such as session close and connection > close do not properly convey the associated LogActor, and instead reported > either the actor for the wrong connection that was previously left on the > CurrentAActor stack, or jsut the default Broker actor supplied when the stack > is empty. -- 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-3021) the Session and Connector actors should be set for events occurring on 0-10 connections
[ https://issues.apache.org/jira/browse/QPID-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3021: - Status: Ready To Review (was: In Progress) > the Session and Connector actors should be set for events occurring on 0-10 > connections > --- > > Key: QPID-3021 > URL: https://issues.apache.org/jira/browse/QPID-3021 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.8, 0.9 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.9 > > > When addressing QPID-3014 it was noticed that the Session and Connector > actors were not being set appropriately when processing events arriving on > 0-10 connections. As a result, logging such as session close and connection > close do not properly convey the associated LogActor, and instead reported > either the actor for the wrong connection that was previously left on the > CurrentAActor stack, or jsut the default Broker actor supplied when the stack > is empty. -- 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-3023) logging tests unnecessarily use an InternalBrokerBaseCase to load configuration for test comparison
[ https://issues.apache.org/jira/browse/QPID-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3023: - Status: Ready To Review (was: In Progress) > logging tests unnecessarily use an InternalBrokerBaseCase to load > configuration for test comparison > --- > > Key: QPID-3023 > URL: https://issues.apache.org/jira/browse/QPID-3023 > Project: Qpid > Issue Type: Test > Components: Java Tests >Affects Versions: 0.7, 0.8 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 0.9 > > > The status logging tests use an InternalBrokerBaseCase to simply load > virtualhost configuration. It should be possible to use a ServerConfiguration > for this directly without actually using an IBBC. -- 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-3023) logging tests unnecessarily use an InternalBrokerBaseCase to load configuration for test comparison
[ https://issues.apache.org/jira/browse/QPID-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-3023: Assignee: Andrew Kennedy (was: Robbie Gemmell) Andrew, can you review the changes please? Thanks. > logging tests unnecessarily use an InternalBrokerBaseCase to load > configuration for test comparison > --- > > Key: QPID-3023 > URL: https://issues.apache.org/jira/browse/QPID-3023 > Project: Qpid > Issue Type: Test > Components: Java Tests >Affects Versions: 0.7, 0.8 >Reporter: Robbie Gemmell >Assignee: Andrew Kennedy >Priority: Minor > Fix For: 0.9 > > > The status logging tests use an InternalBrokerBaseCase to simply load > virtualhost configuration. It should be possible to use a ServerConfiguration > for this directly without actually using an IBBC. -- 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-3022) status logging tests are disabled and/or failing on Java 0-10 test profile
[ https://issues.apache.org/jira/browse/QPID-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-3022: Assignee: Andrew Kennedy (was: Robbie Gemmell) Andrew, can you review the changes please? Thanks. > status logging tests are disabled and/or failing on Java 0-10 test profile > -- > > Key: QPID-3022 > URL: https://issues.apache.org/jira/browse/QPID-3022 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.8 >Reporter: Robbie Gemmell >Assignee: Andrew Kennedy > Fix For: 0.9 > > > Most of the status logging tests are disabled on the Java 0-10 test profile > as they were failing. With recent updates to the 0-10 status logging, these > tests should be re-enabled where possible and fixed where necessary. -- 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-3022) status logging tests are disabled and/or failing on Java 0-10 test profile
[ https://issues.apache.org/jira/browse/QPID-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3022: - Status: Ready To Review (was: In Progress) > status logging tests are disabled and/or failing on Java 0-10 test profile > -- > > Key: QPID-3022 > URL: https://issues.apache.org/jira/browse/QPID-3022 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.8 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.9 > > > Most of the status logging tests are disabled on the Java 0-10 test profile > as they were failing. With recent updates to the 0-10 status logging, these > tests should be re-enabled where possible and fixed where necessary. -- 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-3017) Add unit tests and improve error handling for classes within org.apache.qpid.server.txn
[ https://issues.apache.org/jira/browse/QPID-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987486#action_12987486 ] Robbie Gemmell commented on QPID-3017: -- Hi Keith, Thanks for this, I had a look over the patches and they seem good. There are some small updates I'd suggest: - In AutoCommittransaction, one of the enqueue methods logs that it is dequeing instead of enqueing. - I would ensure the log messages convey that it is a store/transaction log dequeue being performed, as that logging isn't output for transient messages which isn't clear from the text. - The patches introduced whitespace after the penultimate closing brace in LocalTransaction.beginTranIfNecessary() - AMQException is now being caught in LocalTransaction.commit() instead of Exception. Given that any type of exception really indicates a need to clean up the transaction, I think it should still be catching Exception there. An additional patch just for updates to the originals is fine, easier even as it makes the changes obvious and I'll just squash them together at commit time. Robbie > Add unit tests and improve error handling for classes within > org.apache.qpid.server.txn > --- > > Key: QPID-3017 > URL: https://issues.apache.org/jira/browse/QPID-3017 > Project: Qpid > Issue Type: Task > Components: Java Broker >Affects Versions: 0.6, 0.7, 0.8 > Environment: N/A >Reporter: Keith Wall >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 0.9 > > Attachments: > 0001-QPID-3017-Unit-tests-for-new-transaction-classes-in-.patch, > 0002-QPID-3017-Added-javadoc-and-logging.-Removed-todos.patch, > 0003-QPID-3017-Added-unit-tests-for-new-LocalTransaction-.patch > > > The following new transaction classes: > org.apache.qpid.server.txn.LocalTransaction > org.apache.qpid.server.txn.AutoCommitTransaction > org.apache.qpid.server.txn.ServerTransaction > added for 0-10 currently have no unit tests and there are several TODOs > flagged in the error handling logic. -- 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-3017) Add unit tests and improve error handling for classes within org.apache.qpid.server.txn
[ https://issues.apache.org/jira/browse/QPID-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-3017: Assignee: Robbie Gemmell > Add unit tests and improve error handling for classes within > org.apache.qpid.server.txn > --- > > Key: QPID-3017 > URL: https://issues.apache.org/jira/browse/QPID-3017 > Project: Qpid > Issue Type: Task > Components: Java Broker >Affects Versions: 0.6, 0.7, 0.8 > Environment: N/A >Reporter: Keith Wall >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 0.9 > > Attachments: > 0001-QPID-3017-Unit-tests-for-new-transaction-classes-in-.patch, > 0002-QPID-3017-Added-javadoc-and-logging.-Removed-todos.patch, > 0003-QPID-3017-Added-unit-tests-for-new-LocalTransaction-.patch > > > The following new transaction classes: > org.apache.qpid.server.txn.LocalTransaction > org.apache.qpid.server.txn.AutoCommitTransaction > org.apache.qpid.server.txn.ServerTransaction > added for 0-10 currently have no unit tests and there are several TODOs > flagged in the error handling logic. -- 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-3017) Add unit tests and improve error handling for classes within org.apache.qpid.server.txn
[ https://issues.apache.org/jira/browse/QPID-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3017: - Affects Version/s: (was: Future) 0.6 0.7 0.8 Fix Version/s: 0.9 > Add unit tests and improve error handling for classes within > org.apache.qpid.server.txn > --- > > Key: QPID-3017 > URL: https://issues.apache.org/jira/browse/QPID-3017 > Project: Qpid > Issue Type: Task > Components: Java Broker >Affects Versions: 0.6, 0.7, 0.8 > Environment: N/A >Reporter: Keith Wall >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 0.9 > > Attachments: > 0001-QPID-3017-Unit-tests-for-new-transaction-classes-in-.patch, > 0002-QPID-3017-Added-javadoc-and-logging.-Removed-todos.patch, > 0003-QPID-3017-Added-unit-tests-for-new-LocalTransaction-.patch > > > The following new transaction classes: > org.apache.qpid.server.txn.LocalTransaction > org.apache.qpid.server.txn.AutoCommitTransaction > org.apache.qpid.server.txn.ServerTransaction > added for 0-10 currently have no unit tests and there are several TODOs > flagged in the error handling logic. -- 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
