Nabble - Qpid Developers

[jira] Created: (QPID-2223) Controlling order of plug-in initialization.

2009-11-27T08:34:20Z

Controlling order of plug-in initialization.
--------------------------------------------

Key: QPID-2223
URL: https://issues.apache.org/jira/browse/QPID-2223
Project: Qpid
Issue Type: Improvement
Components: C++ Broker
Affects Versions: 0.5
Reporter: Alan Conway
Assignee: Alan Conway

The specific use case for this is as follows:

The cluster plug-in needs to know in earlyInitialize whether or not the broker has a store so it can correctly advertise itself as persistent/transient when joining the cluster.

The current solution is
/**
* Initialization order. If a plugin does not override this, it
* returns DEFAULT_INIT_ORDER. Plugins that need to be initialized
* earlier/later than normal can override initOrder to return
* a lower/higher value than DEFAULT_INIT_ORDER.
*/
QPID_COMMON_EXTERN virtual int initOrder() const;

The cluster plugin sets a higher initOrder so it will initialize after the store and can test whether broker.getStore() is a null store.

This feature was added without sufficient discussion. The goal of this JIRA is to determine if there's a better solution that would apply more generally. If so we'll implement that instead.

--
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-subscribe@...

[jira] Created: (QPID-2222) changes to enable Base64MD5PasswordFilePrincipalDataase support for the .net client were not merged to trunk

2009-11-27T02:57:39Z

changes to enable Base64MD5PasswordFilePrincipalDataase support for the .net client were not merged to trunk
------------------------------------------------------------------------------------------------------------

Key: QPID-2222
URL: https://issues.apache.org/jira/browse/QPID-2222
Project: Qpid
Issue Type: Bug
Components: Dot Net Client, Java Broker
Affects Versions: 0.5, M4, M3
Reporter: Robbie Gemmell
Assignee: Robbie Gemmell
Fix For: 0.6

When QPID-1058 was completed to support connecting the .net client to the Java broker when a Base64MD5PasswordFilePrincipalDataase was in use, the patches were not merged from the M2.x branch to trunk.

--
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-subscribe@...

[jira] Created: (QPID-2221) Get cluster tests working under cmake.

2009-11-26T11:50:39Z

Get cluster tests working under cmake.
--------------------------------------

Key: QPID-2221
URL: https://issues.apache.org/jira/browse/QPID-2221
Project: Qpid
Issue Type: Task
Components: Build Tools
Affects Versions: 0.5
Reporter: Alan Conway
Assignee: Alan Conway
Fix For: 0.6

Get all the cluster tests working under cmake.

--
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-subscribe@...

[jira] Resolved: (QPID-1475) failover soak test for cluster

2009-11-26T10:56:39Z

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

Alan Conway resolved QPID-1475.
-------------------------------

Resolution: Fixed

This test has been comitted

> failover soak test for cluster
> ------------------------------
>
> Key: QPID-1475
> URL: https://issues.apache.org/jira/browse/QPID-1475
> Project: Qpid
> Issue Type: Improvement
> Components: C++ Client
> Reporter: michael j. goulish
> Attachments: failover_soak.diff
>
>
> This test creates a cluster of 3 brokers, creates a sending and a receiving client that runs against them, then starts killing brokers and adding new ones to the cluster while the clients are sending and receiving.
> It detects clients hanging, or the case where the receiving client finds gaps in the 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-subscribe@...

[jira] Closed: (QPID-1249) Distribution created on system where openais is not installed fails make check on system where it is

2009-11-26T10:56:39Z

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

Alan Conway closed QPID-1249.
-----------------------------

Resolution: Won't Fix

This doesn't appear to be causing any problems in practice.

> Distribution created on system where openais is not installed fails make check on system where it is
> ----------------------------------------------------------------------------------------------------
>
> Key: QPID-1249
> URL: https://issues.apache.org/jira/browse/QPID-1249
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Affects Versions: M3
> Reporter: Gordon Sim
> Assignee: Alan Conway
> Priority: Minor
>
> If the distribution (e.g. the latest m3 beta tarball) is created on a system where openais is not installed then the cluster specific test scripts are not included. However if the tarball is unpacked and built on a system where openais _is_ installed, then make check fails due to the abscence of the ais_check script.
> The workaround is to specify --without-cpg to configure, but the real solution is (I think) to include all the files in the distribution regardless of whats installed on the platform creating the dist tarballs.

[jira] Resolved: (QPID-2211) API change to qpid::broker::MessageStore not portable

2009-11-26T10:52:39Z

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

Alan Conway resolved QPID-2211.
-------------------------------

Resolution: Not A Problem

I'm marking this resolved, there's actually no need to get access to the store directory. It works fine just using the brokers data-dir.

There's still an open question about cluster-store collaboration in QPID-2220

> API change to qpid::broker::MessageStore not portable
> -----------------------------------------------------
>
> Key: QPID-2211
> URL: https://issues.apache.org/jira/browse/QPID-2211
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Affects Versions: 0.6
> Reporter: Steve Huston
> Assignee: Alan Conway
>
> The following pure virtual function was added to qpid::broker::MessageStore:
> virtual std::string getStoreDir() const = 0;
> Two problems as a result:
> 1. No corresponding change was made to the qpid/store/MessageStorePlugin.cpp, which is the portable persistence plug-in layer (or, that's it's purpose, anyway). This broker the Windows build.
> 2. Not all message stores have a store dir - this is (at this point, anyway) an option only for the Red Hat store.
> Could this addition be explained please? Also, if it needs to stay as is, please fix the Windows build.

[jira] Commented: (QPID-2220) Assisting manual recovery from a complete persistent cluster crash.

2009-11-26T10:52:39Z

[ https://issues.apache.org/jira/browse/QPID-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782961#action_12782961 ]

Alan Conway commented on QPID-2220:
-----------------------------------

To clarify the situation: the problem is recovering from a total cluster failure, no clean stores. We want to identify the store that is the most up to date, i.e. the last one modifed in respect of cluster order. We can do a pretty good job just in cluster code by recording config changes.

Now if 2 or more brokers were killed at the same configuration , we'd like a more fine grained comparison.

Using the Persistence ID works for the Red Hat store because it is a monotonically increasing value that gets incremented for (almost) every change to the store (currently not incremented for deleting queues/exchanges/bindings.) So if we record the PID value N with the config-change and in recovery we find the store is at PID M then we know there were M-N changes to that store since the config change. Thats a number we can meaningfully compare for brokers that died at the same membership.

Factors that make this work:
- value that increases with each change to the db.
- at runtime we can query the current value to save at each config change
- in recovery we can find the value associated with the database

Is that something we could have as an optional API on a MessageStore, or should we put it on a separate plugin that can optionally be provided by the store plugin.

> Assisting manual recovery from a complete persistent cluster crash.
> -------------------------------------------------------------------
>
> Key: QPID-2220
> URL: https://issues.apache.org/jira/browse/QPID-2220
> Project: Qpid
> Issue Type: Improvement
> Components: C++ Broker
> Affects Versions: 0.5
> Reporter: Alan Conway
> Assignee: Alan Conway
>
> If every member of a persistent cluster crashes then manual intervention is required to identify which store is most up-to-date, so it can be used to recover. We need to provide tools to assist in this identification.
> The cluster can save a config-change counter with each config change (cluster membership change). In recovery, the broker with the highest config-change counter has the best store.
> However if the last brokers in the cluster crash so close together that none can record a config-change we need an additional decider.
> The store at http://qpidcomponents.org/download.html#persistence maintains a global Persistence ID, a 64 bit value that is incremented for each enqueue, dequeue. If the cluster stores (config-change,PID) pairs then in recovery we can use actual-PID - config-change PID as a tiebreaker.
> Proposed change to MessageStore API:
> /** Returns a monotonically increasing value reflecting changes to the store.
> * The value can wrap-around to 0.
> * Stores need not implement this function, they can simply return 0.
> */
> uint64_t getChangeCounter();
> The default implementation just returns 0 and the cluster must fall back to relying on config-change counts.

[jira] Resolved: (QPID-2157) Persistent cluster restart

2009-11-26T10:34:39Z

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

Alan Conway resolved QPID-2157.
-------------------------------

Resolution: Fixed

Fixed by commits from 883842 to 884226.
Manual recovery from a complete cluster failure is not addressed yet, see QPID-2220

> Persistent cluster restart
> --------------------------
>
> Key: QPID-2157
> URL: https://issues.apache.org/jira/browse/QPID-2157
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Affects Versions: 0.5
> Reporter: Alan Conway
> Assignee: Alan Conway
>
> Currently, when restarting a persistent cluster, the first broker to start loads from its store and all other brokers move their store aside and update from the cluster. If some brokers failed and have out-of-date stores, we assume manual intervention to ensure that the correct broker is started first.
> The goal is to have the brokers automatically compare their stores, allowing all brokers with clean stores to load from store and all other brokers to update from the cluster.
> A design note for this issue is at http://cwiki.apache.org/confluence/display/qpid/Persistent+Cluster+Restart+Design+Note

[jira] Updated: (QPID-2172) [Java] Merge race condition fixes from trunk to 0.5.x-dev branch

2009-11-26T08:26:39Z

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

Robbie Gemmell updated QPID-2172:
---------------------------------

Status: Ready To Review (was: In Progress)

> [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)

[jira] Assigned: (QPID-2172) [Java] Merge race condition fixes from trunk to 0.5.x-dev branch

2009-11-26T08:20:39Z

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

Robbie Gemmell reassigned QPID-2172:
------------------------------------

Assignee: Robbie Gemmell

[jira] Commented: (QPID-2220) Assisting manual recovery from a complete persistent cluster crash.

2009-11-25T14:16:42Z

[ https://issues.apache.org/jira/browse/QPID-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782655#action_12782655 ]

Carl Trieloff commented on QPID-2220:
-------------------------------------

One note is we should use PID, as that will also include adding bindings, exchanges and queues and all enqueues and dequeues.

Carl.

[jira] Updated: (QPID-2220) Assisting manual recovery from a complete persistent cluster crash.

2009-11-25T13:32:39Z

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

Alan Conway updated QPID-2220:
------------------------------

Description:
If every member of a persistent cluster crashes then manual intervention is required to identify which store is most up-to-date, so it can be used to recover. We need to provide tools to assist in this identification.

The cluster can save a config-change counter with each config change (cluster membership change). In recovery, the broker with the highest config-change counter has the best store.

However if the last brokers in the cluster crash so close together that none can record a config-change we need an additional decider.
The store at http://qpidcomponents.org/download.html#persistence maintains a global Persistence ID, a 64 bit value that is incremented for each enqueue, dequeue. If the cluster stores (config-change,PID) pairs then in recovery we can use actual-PID - config-change PID as a tiebreaker.

Proposed change to MessageStore API:
/** Returns a monotonically increasing value reflecting changes to the store.
* The value can wrap-around to 0.
* Stores need not implement this function, they can simply return 0.
*/
uint64_t getChangeCounter();

The default implementation just returns 0 and the cluster must fall back to relying on config-change counts.

was:
If every member of a persistent cluster crashes then manual intervention is required to identify which store is most up-to-date, so it can be used to recover. We need to provide tools to assist in this identification.

The cluster can save a config-change counter with each config change (cluster membership change). In recovery, the broker with the highest config-change counter has the best store. However if the last brokers in the cluster crash so close together that none can record a config-change we need an additional decider.

The store at http://qpidcomponents.org/download.html#persistence maintains a global Record Identifier (RID), a 64 bit value that is incremented for each enqueue and dequeue. If the cluster stores (config-change,RID) pairs then in recovery we can use actual-RID - RID at config-change as a tiebreaker.

Proposed change to MessageStore API:
/** Returns a monotonically increasing value reflecting the number of changes to the store.
* The value can wrap-around to 0.
* Stores need not implement this function, they can simply return 0.
*/
uint64_t getChangeCounter();

The default implementation just returns 0 and the cluster must fall back to relying on config-change counts.

[jira] Commented: (QPID-2220) Assisting manual recovery from a complete persistent cluster crash.

2009-11-25T12:56:39Z

[ https://issues.apache.org/jira/browse/QPID-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782616#action_12782616 ]

Carl Trieloff commented on QPID-2220:
-------------------------------------

I would change recover to return the current PID on recover & not void. That should solve your issue.

I.e. I get the highest PID, and if it is then not the latest, I re-init the store --- question, if I do an update does PID get synced. If not this will not work

Carl.

> Assisting manual recovery from a complete persistent cluster crash.
> -------------------------------------------------------------------
>
> Key: QPID-2220
> URL: https://issues.apache.org/jira/browse/QPID-2220
> Project: Qpid
> Issue Type: Improvement
> Components: C++ Broker
> Affects Versions: 0.5
> Reporter: Alan Conway
> Assignee: Alan Conway
>
> If every member of a persistent cluster crashes then manual intervention is required to identify which store is most up-to-date, so it can be used to recover. We need to provide tools to assist in this identification.
> The cluster can save a config-change counter with each config change (cluster membership change). In recovery, the broker with the highest config-change counter has the best store. However if the last brokers in the cluster crash so close together that none can record a config-change we need an additional decider.
> The store at http://qpidcomponents.org/download.html#persistence maintains a global Record Identifier (RID), a 64 bit value that is incremented for each enqueue and dequeue. If the cluster stores (config-change,RID) pairs then in recovery we can use actual-RID - RID at config-change as a tiebreaker.
> Proposed change to MessageStore API:
> /** Returns a monotonically increasing value reflecting the number of changes to the store.
> * The value can wrap-around to 0.
> * Stores need not implement this function, they can simply return 0.
> */
> uint64_t getChangeCounter();
> The default implementation just returns 0 and the cluster must fall back to relying on config-change counts.

[jira] Updated: (QPID-2220) Assisting manual recovery from a complete persistent cluster crash.

2009-11-25T12:54:39Z

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

Alan Conway updated QPID-2220:
------------------------------

Summary: Assisting manual recovery from a complete persistent cluster crash. (was: Assisign manual recovery from a complete persistent cluster crash.)

> Assisting manual recovery from a complete persistent cluster crash.
> -------------------------------------------------------------------
>
> Key: QPID-2220
> URL: https://issues.apache.org/jira/browse/QPID-2220
> Project: Qpid
> Issue Type: Improvement
> Components: C++ Broker
> Affects Versions: 0.5
> Reporter: Alan Conway
> Assignee: Alan Conway
>
> If every member of a persistent cluster crashes then manual intervention is required to identify which store is most up-to-date, so it can be used to recover. We need to provide tools to assist in this identification.
> The cluster can save a config-change counter with each config change (cluster membership change). In recovery, the broker with the highest config-change counter has the best store. However if the last brokers in the cluster crash so close together that none can record a config-change we need an additional decider.
> The store at http://qpidcomponents.org/download.html#persistence maintains a global Record Identifier (RID), a 64 bit value that is incremented for each enqueue and dequeue. If the cluster stores (config-change,RID) pairs then in recovery we can use actual-RID - RID at config-change as a tiebreaker.
> Proposed change to MessageStore API:
> /** Returns a monotonically increasing value reflecting the number of changes to the store.
> * The value can wrap-around to 0.
> * Stores need not implement this function, they can simply return 0.
> */
> uint64_t getChangeCounter();
> The default implementation just returns 0 and the cluster must fall back to relying on config-change counts.

[jira] Resolved: (QPID-1866) Durable plug-in exchanges cause broker failure on recovery

2009-11-25T12:48:39Z

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

Ted Ross resolved QPID-1866.
----------------------------

Resolution: Fixed

Several changes have occurred on the trunk related to recovery and plug-in initialization since this issue was raised. I tried to reproduce the failure by creating a durable XML exchange and recovering the broker. The problem appears to be fixed.

> Durable plug-in exchanges cause broker failure on recovery
> ----------------------------------------------------------
>
> Key: QPID-1866
> URL: https://issues.apache.org/jira/browse/QPID-1866
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Affects Versions: 0.5
> Reporter: Ted Ross
> Fix For: 0.6
>
>
> When an exchange, of a type supplied by a plug-in, is declared as durable, the broker crashes on subsequent startup and recovery.
> Apparently, the store is recovered before plugin exchanges are registered. When recovered, the exchange type is unknown.

[jira] Commented: (QPID-2220) Assisign manual recovery from a complete persistent cluster crash.

2009-11-25T12:48:39Z

[ https://issues.apache.org/jira/browse/QPID-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782613#action_12782613 ]

Carl Trieloff commented on QPID-2220:
-------------------------------------

Alan,

The PID can use used, which maps thethe RID. PID is a count for all store operations, so adding so making init take an initial ID for new store joining, and getID may do it.

I think we may already have the former

Carl.

> Assisign manual recovery from a complete persistent cluster crash.
> ------------------------------------------------------------------
>
> Key: QPID-2220
> URL: https://issues.apache.org/jira/browse/QPID-2220
> Project: Qpid
> Issue Type: Improvement
> Components: C++ Broker
> Affects Versions: 0.5
> Reporter: Alan Conway
> Assignee: Alan Conway
>
> If every member of a persistent cluster crashes then manual intervention is required to identify which store is most up-to-date, so it can be used to recover. We need to provide tools to assist in this identification.
> The cluster can save a config-change counter with each config change (cluster membership change). In recovery, the broker with the highest config-change counter has the best store. However if the last brokers in the cluster crash so close together that none can record a config-change we need an additional decider.
> The store at http://qpidcomponents.org/download.html#persistence maintains a global Record Identifier (RID), a 64 bit value that is incremented for each enqueue and dequeue. If the cluster stores (config-change,RID) pairs then in recovery we can use actual-RID - RID at config-change as a tiebreaker.
> Proposed change to MessageStore API:
> /** Returns a monotonically increasing value reflecting the number of changes to the store.
> * The value can wrap-around to 0.
> * Stores need not implement this function, they can simply return 0.
> */
> uint64_t getChangeCounter();
> The default implementation just returns 0 and the cluster must fall back to relying on config-change counts.

[jira] Updated: (QPID-2220) Assisign manual recovery from a complete persistent cluster crash.

2009-11-25T12:48:39Z

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

Alan Conway updated QPID-2220:
------------------------------

Description:
If every member of a persistent cluster crashes then manual intervention is required to identify which store is most up-to-date, so it can be used to recover. We need to provide tools to assist in this identification.

The cluster can save a config-change counter with each config change (cluster membership change). In recovery, the broker with the highest config-change counter has the best store. However if the last brokers in the cluster crash so close together that none can record a config-change we need an additional decider.

The store at http://qpidcomponents.org/download.html#persistence maintains a global Record Identifier (RID), a 64 bit value that is incremented for each enqueue and dequeue. If the cluster stores (config-change,RID) pairs then in recovery we can use actual-RID - RID at config-change as a tiebreaker.

Proposed change to MessageStore API:
/** Returns a monotonically increasing value reflecting the number of changes to the store.
* The value can wrap-around to 0.
* Stores need not implement this function, they can simply return 0.
*/
uint64_t getChangeCounter();

The default implementation just returns 0 and the cluster must fall back to relying on config-change counts.

was:
If every member of a persistent cluster crashes then manual intervention is required to identify which store is most up-to-date, so it can be used to recover.
We need to provide tools to assist in this identification.

The cluster can save a config-change counter with each config change. In recovery, the broker with the highest config-change counter has the best store. However if the last brokers in the cluster crash so close together that none can record a config-change we need an additional decider.

The store at http://qpidcomponents.org/download.html#persistence maintains a global counter called the RecordIdentifier (RID) that is incremented for each enqueue and dequeue. If the cluster stores (config-change,RID) pairs then in recovery we can use actual-RID - RID at config-change as a tiebreaker.

Is it reasonable to provide access to this counter in the generic MessageStore API? Stores that don't implement it can simply return 0, and the cluster must fall back to relying on config-change counts.

[jira] Created: (QPID-2220) Assisign manual recovery from a complete persistent cluster crash.

2009-11-25T12:42:39Z

Assisign manual recovery from a complete persistent cluster crash.
------------------------------------------------------------------

Key: QPID-2220
URL: https://issues.apache.org/jira/browse/QPID-2220
Project: Qpid
Issue Type: Improvement
Components: C++ Broker
Affects Versions: 0.5
Reporter: Alan Conway
Assignee: Alan Conway

If every member of a persistent cluster crashes then manual intervention is required to identify which store is most up-to-date, so it can be used to recover.
We need to provide tools to assist in this identification.

The cluster can save a config-change counter with each config change. In recovery, the broker with the highest config-change counter has the best store. However if the last brokers in the cluster crash so close together that none can record a config-change we need an additional decider.

The store at http://qpidcomponents.org/download.html#persistence maintains a global counter called the RecordIdentifier (RID) that is incremented for each enqueue and dequeue. If the cluster stores (config-change,RID) pairs then in recovery we can use actual-RID - RID at config-change as a tiebreaker.

Is it reasonable to provide access to this counter in the generic MessageStore API? Stores that don't implement it can simply return 0, and the cluster must fall back to relying on config-change counts.

--
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-subscribe@...

[jira] Commented: (QPID-1866) Durable plug-in exchanges cause broker failure on recovery

2009-11-25T12:32:39Z

[ https://issues.apache.org/jira/browse/QPID-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782603#action_12782603 ]

Alan Conway commented on QPID-1866:
-----------------------------------

I recently added Plugin::initOrder() which allows you to specify ordering of plug-in initialization. We could give exchange plug-ins a lower initOrder() than the store to ensure they initialize first.

[jira] Commented: (QPID-1866) Durable plug-in exchanges cause broker failure on recovery

2009-11-25T12:26:39Z

[ https://issues.apache.org/jira/browse/QPID-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782602#action_12782602 ]

Carl Trieloff commented on QPID-1866:
-------------------------------------

Which store and which version of the broker are you using?

[jira] Resolved: (QPID-2219) Example tests hang when run in a vpath build

2009-11-25T11:23:39Z

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

Ted Ross resolved QPID-2219.
----------------------------

Resolution: Fixed

> Example tests hang when run in a vpath build
> --------------------------------------------
>
> Key: QPID-2219
> URL: https://issues.apache.org/jira/browse/QPID-2219
> Project: Qpid
> Issue Type: Bug
> Components: Qpid Examples
> Affects Versions: 0.5
> Reporter: Ted Ross
> Assignee: Ted Ross
> Priority: Minor
>
> The example tests (i.e. make check -C examples) do not run in a vpath build. The example programs fail to execute and the test then hangs forever waiting for the expected output.
> ...
> make[2]: Entering directory `/home/ross/svn/qpid/build-vpath/examples'
> ../../cpp/examples/verify_all /home/ross/svn/qpid/build-vpath/../cpp/.. /home/ross/svn/qpid/build-vpath "--no-module-dir --data-dir \"\" --auth no --load-module ../src/.libs/xml.so"
> == /home/ross/svn/qpid/build-vpath/../cpp/../cpp/examples/pub-sub/verify
> ../../cpp/examples/verify: line 61: ./topic_listener: No such file or directory
> ...
> The verify_all script makes no distinction between the source directory and the build directory. The verify scripts are in the source dir but the compiled C++ example programs are in the build dir.

[jira] Commented: (QPID-1866) Durable plug-in exchanges cause broker failure on recovery

2009-11-25T11:23:39Z

[ https://issues.apache.org/jira/browse/QPID-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782567#action_12782567 ]

Lisa Winkler commented on QPID-1866:
------------------------------------

Can anyone on the qpid team offer any information on if/when this problem is to be addressed?

[jira] Created: (QPID-2219) Example tests hang when run in a vpath build

2009-11-25T08:21:39Z

Example tests hang when run in a vpath build
--------------------------------------------

Key: QPID-2219
URL: https://issues.apache.org/jira/browse/QPID-2219
Project: Qpid
Issue Type: Bug
Components: Qpid Examples
Affects Versions: 0.5
Reporter: Ted Ross
Assignee: Ted Ross
Priority: Minor

The example tests (i.e. make check -C examples) do not run in a vpath build. The example programs fail to execute and the test then hangs forever waiting for the expected output.

...
make[2]: Entering directory `/home/ross/svn/qpid/build-vpath/examples'
../../cpp/examples/verify_all /home/ross/svn/qpid/build-vpath/../cpp/.. /home/ross/svn/qpid/build-vpath "--no-module-dir --data-dir \"\" --auth no --load-module ../src/.libs/xml.so"
== /home/ross/svn/qpid/build-vpath/../cpp/../cpp/examples/pub-sub/verify
../../cpp/examples/verify: line 61: ./topic_listener: No such file or directory
...

The verify_all script makes no distinction between the source directory and the build directory. The verify scripts are in the source dir but the compiled C++ example programs are in the build dir.

--
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-subscribe@...

[jira] Commented: (QPID-1899) --require-encryption doesn't work unless cyrus sasl authentication is turned on

2009-11-25T06:23:39Z

[ https://issues.apache.org/jira/browse/QPID-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782446#action_12782446 ]

Ken Giusti commented on QPID-1899:
----------------------------------

Looks good. fyi, here's a good reference on sasl & ssf: http://docs.sun.com/app/docs/doc/816-4863/sasl.intro?a=view

-K

> --require-encryption doesn't work unless cyrus sasl authentication is turned on
> -------------------------------------------------------------------------------
>
> Key: QPID-1899
> URL: https://issues.apache.org/jira/browse/QPID-1899
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Affects Versions: 0.5
> Reporter: Gordon Sim
> Assignee: Steve Huston
> Fix For: 0.6
>
> Attachments: qpid-1899-10_26.patch, qpid-1899-10_30.patch, qpid-1899-9-17.patch, qpid-1899-hacky.patch, qpid-1899.patch, qpid-1899.patch
>
>
> If you specify --require-encryption and --auth no then the broker will allow un-encrypted conections. (If on the other hand you have authentication on, it will prevent you connecting with anything other than a mech that supports encryption and will require an encrypting sasl security layer - or of course an ssl connection)

[jira] Resolved: (QPID-2218) Dead link in website

2009-11-25T06:02:39Z

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

Carl Trieloff resolved QPID-2218.
---------------------------------

Resolution: Fixed

link fixed

> Dead link in website
> --------------------
>
> Key: QPID-2218
> URL: https://issues.apache.org/jira/browse/QPID-2218
> Project: Qpid
> Issue Type: Bug
> Components: website
> Reporter: Edlira Nano
> Priority: Trivial
>
> In the "Getting Started" section of the Qpid website (link : http://qpid.apache.org/getting-started.html) the link named "Running the C++ Examples"
> to https://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/examples/README is not working.
> I suppose the desired address to link to is https://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/examples/README.txt

[jira] Created: (QPID-2218) Dead link in website

2009-11-25T05:58:39Z

Dead link in website
--------------------

Key: QPID-2218
URL: https://issues.apache.org/jira/browse/QPID-2218
Project: Qpid
Issue Type: Bug
Components: website
Reporter: Edlira Nano
Priority: Trivial

In the "Getting Started" section of the Qpid website (link : http://qpid.apache.org/getting-started.html) the link named "Running the C++ Examples"
to https://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/examples/README is not working.

I suppose the desired address to link to is https://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/examples/README.txt

--
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-subscribe@...

[jira] Commented: (QPID-2216) Error for missing ssl-cert-db option reports wrong option name

2009-11-24T18:18:39Z

[ https://issues.apache.org/jira/browse/QPID-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782282#action_12782282 ]

Carl Trieloff commented on QPID-2216:
-------------------------------------

Flip it to Notice ??

Carl.

> Error for missing ssl-cert-db option reports wrong option name
> --------------------------------------------------------------
>
> Key: QPID-2216
> URL: https://issues.apache.org/jira/browse/QPID-2216
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Affects Versions: 0.6
> Environment: Linux
> Reporter: Steve Huston
> Priority: Minor
>
> On Linux, trying to run the broker with the ssl module, but forgetting the ssl-cert-db option, yields:
> 2009-11-24 18:48:18 info SSL plugin not enabled, you must set --qpid-ssl-cert-db to enable it.
> Two problems:
> 1. It's an 'info' message, so is not visible with default logging level set; I added -t to see this.
> 2. the option that must be set is --ssl-cert-db, not --qpid-ssl-cert-db (--help reports it correctly)

[jira] Resolved: (QPID-2217) New qpid::Plugin::initOrder() not exported for Windows

2009-11-24T17:20:39Z

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

Steve Huston resolved QPID-2217.
--------------------------------

Resolution: Fixed
Fix Version/s: 0.6

Fixed on trunk r883948.

> New qpid::Plugin::initOrder() not exported for Windows
> ------------------------------------------------------
>
> Key: QPID-2217
> URL: https://issues.apache.org/jira/browse/QPID-2217
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Affects Versions: 0.6
> Environment: Windows
> Reporter: Steve Huston
> Assignee: Alan Conway
> Fix For: 0.6
>
>
> Windows broker build failed today (from the dashboard):
> *Error* (first 5)
> TCPIOPlugin.obj : error LNK2001: unresolved external symbol "public: virtual int __thiscall qpid::Plugin::initOrder(void)const " (?initOrder@Plugin@qpid@@UBEHXZ)
> C:\qpid\trunk\build\src\Release\qpidbroker.dll : fatal error LNK1120: 1 unresolved externals

[jira] Created: (QPID-2217) New qpid::Plugin::initOrder() not exported for Windows

2009-11-24T17:00:43Z

New qpid::Plugin::initOrder() not exported for Windows
------------------------------------------------------

Key: QPID-2217
URL: https://issues.apache.org/jira/browse/QPID-2217
Project: Qpid
Issue Type: Bug
Components: C++ Broker
Affects Versions: 0.6
Environment: Windows
Reporter: Steve Huston
Assignee: Alan Conway

Windows broker build failed today (from the dashboard):

*Error* (first 5)
TCPIOPlugin.obj : error LNK2001: unresolved external symbol "public: virtual int __thiscall qpid::Plugin::initOrder(void)const " (?initOrder@Plugin@qpid@@UBEHXZ)

C:\qpid\trunk\build\src\Release\qpidbroker.dll : fatal error LNK1120: 1 unresolved externals

--
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-subscribe@...

[jira] Created: (QPID-2216) Error for missing ssl-cert-db option reports wrong option name

2009-11-24T16:24:39Z

Error for missing ssl-cert-db option reports wrong option name
--------------------------------------------------------------

Key: QPID-2216
URL: https://issues.apache.org/jira/browse/QPID-2216
Project: Qpid
Issue Type: Bug
Components: C++ Broker
Affects Versions: 0.6
Environment: Linux
Reporter: Steve Huston
Priority: Minor

On Linux, trying to run the broker with the ssl module, but forgetting the ssl-cert-db option, yields:

2009-11-24 18:48:18 info SSL plugin not enabled, you must set --qpid-ssl-cert-db to enable it.

Two problems:
1. It's an 'info' message, so is not visible with default logging level set; I added -t to see this.
2. the option that must be set is --ssl-cert-db, not --qpid-ssl-cert-db (--help reports it correctly)

--
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-subscribe@...

[jira] Commented: (QPID-2128) Transaction support for the WCF channel

2009-11-24T16:03:39Z

[ https://issues.apache.org/jira/browse/QPID-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782253#action_12782253 ]

Carl Trieloff commented on QPID-2128:
-------------------------------------

ok, I don't either, thus the Q :-)

> Transaction support for the WCF channel
> ---------------------------------------
>
> Key: QPID-2128
> URL: https://issues.apache.org/jira/browse/QPID-2128
> Project: Qpid
> Issue Type: New Feature
> Components: WCF/C++ Client
> Affects Versions: 0.6
> Environment: Windows
> Reporter: Cliff Jansen
> Attachments: cppbld.patch, qpid2128_1.patch, wcfbld.patch
>
>
> Transaction support is currently lacking from the WCF channel.
> As an initial implementation, full distributed transaction support from within .NET is proposed using the dtx AMQP classes and creating a plugin to the MSDTC infrastructure to drive recovery.
> Added performance from promotable transaction enlistment is deferred to a later date.

[jira] Commented: (QPID-2128) Transaction support for the WCF channel

2009-11-24T15:59:39Z

[ https://issues.apache.org/jira/browse/QPID-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782252#action_12782252 ]

Cliff Jansen commented on QPID-2128:
------------------------------------

> is there any reason not to just register it even if not used?

I have no experience with Microsoft install issues, but I would think
it could be done with "average" registry-related headaches.

The registry key in question was specifically introduced to improve
security on Windows, so some thought will need to be given to maintaining
that as best as possible.

Cliff

[jira] Commented: (QPID-1899) --require-encryption doesn't work unless cyrus sasl authentication is turned on

2009-11-24T15:45:39Z

[ https://issues.apache.org/jira/browse/QPID-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782245#action_12782245 ]

Steve Huston commented on QPID-1899:
------------------------------------

Is this correct?

Index: Sasl.h
===================================================================
--- Sasl.h (revision 883558)
+++ Sasl.h (working copy)
@@ -37,11 +37,27 @@
struct ConnectionSettings;

/**
- * Interface to SASL support
+ * Interface to SASL support. This class is implemented by platform-specific
+ * SASL providers.
*/
class Sasl
{
public:
+ /**
+ * Start SASL negotiation with the broker.
+ *
+ * @param mechanisms Comma-separated list of the SASL mechanism the
+ * client supports.
+ * @param ssf Security Strength Factor (SSF). SSF is used to negotiate
+ * a SASL security layer on top of the connection should both
+ * parties require and support it. The value indicates the
+ * required level of security for communication. Possible
+ * values are:
+ * @li 0 No security
+ * @li 1 Integrity checking only
+ * @li >1 Integrity and confidentiality with the number
+ * giving the encryption key length.
+ */
virtual std::string start(const std::string& mechanisms, unsigned int ssf) = 0;
virtual std::string step(const std::string& challenge) = 0;
virtual std::string getMechanism() = 0;

[jira] Updated: (QPID-2128) Transaction support for the WCF channel

2009-11-24T15:39:39Z

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

Cliff Jansen updated QPID-2128:
-------------------------------

Attachment: wcfbld.patch
cppbld.patch

Here are sample patches for building.

The cmake side is what I use, but would need an install component too.

The wcf vcproj file should work. I have a self imposed "TODO" to fix up this
aspect of the build, and integrate with cmake if I can.

[jira] Commented: (QPID-1555) When run with -d option, C++ broker dies with "No Such Transport (tcp)" error

2009-11-24T15:21:39Z

[ https://issues.apache.org/jira/browse/QPID-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782232#action_12782232 ]

Steve Huston commented on QPID-1555:
------------------------------------

Gordon, should this be revisited since there were SASL security layer changes recently?

> When run with -d option, C++ broker dies with "No Such Transport (tcp)" error
> -----------------------------------------------------------------------------
>
> Key: QPID-1555
> URL: https://issues.apache.org/jira/browse/QPID-1555
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Affects Versions: M4
> Environment: CentOS 5.2: nss-3.12.1.1-1.el5.centos.1, cyrus-sasl-lib-2.1.22-4, openais-0.80.3-15.el5. Qpid resides under /opt/qpid-m4.
> Reporter: Joshua Kramer
> Priority: Minor
> Attachments: qpidd.log
>
>
> When using 'head' as checked out of SVN at approx. 1 AM EST on Saturday, 03-Jan-09, the following occurs.
> If I run the broker using these options:
> sbin/qpidd -t --config /opt/qpid-m4/etc/qpidd.conf
> The broker runs, and I can connect to the broker. If I add the -d option to run as a daemon, the broker dies right away. In the logfile is an error:
> 2009-jan-04 01:43:45 debug Exception constructed: No such transport: 'tcp' (qpid/broker/Broker.cpp:389)
> 2009-jan-04 01:43:45 critical Daemon startup failed: No such transport: 'tcp' (qpid/broker/Broker.cpp:389)
> 2009-jan-04 01:43:45 notice Shut down
> Note that I have created the NSS / SSL certificates exactly as described in the 'SSL' file in the 'cpp' directory.
> /opt/qpid-m4/etc/qpidd.conf is as follows:
> data-dir=/opt/qpid-m4/var/lib/qpidd/data
> pid-dir=/opt/qpid-m4/var/lib/qpid
> auth=yes
> realm=devbox
> require-encryption=yes
> log-to-file=/opt/qpid-m4/var/log/qpidd.log
> ssl-cert-db=/opt/qpid-m4/etc/qpid_cert_db
> ssl-cert-password-file=/opt/qpid-m4/etc/cert.password
> ssl-cert-name=home-av-server.home-av
> ssl-port=5671
> load-module=/opt/qpid-m4/lib/qpid/daemon/ssl.so
> /etc/sasl2/qpidd.conf is as follows:
> mech_list: plain anonymous
> pwcheck_method: auxprop
> auxprop_plugin: sasldb
> sasldb_path: /opt/qpid-m4/var/lib/qpidd/qpidd.sasldb