The C++ automake system has 2 install phases, exec and data. Module
libraries are installed incorrectly in the data phase. Fix the
makefiles to install them in the exec phase.

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1083077 13f79535-47bb-0310-9956-ffa450edef68

Described in https://bugzilla.redhat.com/show_bug.cgi?id=655078.  The
management agent's deleted-object list was not being replicated to new
members joining the cluster, so management generated fewer deleted
object notifications on the newer member, causing it to fail with an
invalid-argument error. The list is now being replicated correctly.

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1041181 13f79535-47bb-0310-9956-ffa450edef68

Reverts revisions:
r1023966 "Introduce broker::Cluster interface."
r1024275 "Fix compile error: outline set/getCluster fucntions on Broker."
r1027210 "New cluster: core framework and initial implementation of enqueue logic."

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1028055 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1027210 13f79535-47bb-0310-9956-ffa450edef68

- no version info for modules
- no $(PLUGINLDFLAGS)  on libqmfconsole, typo in previous merge.


git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@956001 13f79535-47bb-0310-9956-ffa450edef68

Each library libfoo or plugin foo has a variable FOO_VERSION_INFO with
a value passed as -version-info to libtool.


git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@955672 13f79535-47bb-0310-9956-ffa450edef68

-----------------------------------

* initial observation of a problem was a 2% failure rate in perftests
  of 20,000 messages against a cluster with security enabled.
  Problem was occasional receit of encrypted frames before the
  security codec had been enabled.  This is fixed with locking in
  cluster code (no new locks in broker code) and a callback that is
  fired by broker::ConnectionHandler::Handler to tell the cluster
  code when the opening handshake has finished.
  This was never a problem in the non-clustered broker before because
  everything happened in a single thread.

* the brokers that "shadow" the connection must not have null
  authenticators rather than real ones, so that they go through all
  the motions but don't do anythig.  Only the directly-connected
  broker can perform the security handshake.

* once the directly-connected broker receives the real user ID
  from its callback, it mcasts that ID to all other brokers.
  Otherwise the shadowing brokers will al think that the user ID
  is "anonymous".
  Check this by doing a substantial perftest, and using
      qpid-stat -c localhost:PORT
  to confirm that the brokers all have the same userID for the
  same connection.

* the user ID, negotiated during the Sasl security startup, is
   communicated from the directly connected broker to all other
   cluster brokers.

* If security is *not* being used, then this code should *not* tell
  the brokers anything about the userID -- or it will step on the value
  that is being set by other code pathways.

* test program at cpp/src/tests/cluster_authentication_soak is not yet
  fully automated -- run it with something like
  "sudo ./cluster_authentication_soak 500"



git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@944158 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@904656 13f79535-47bb-0310-9956-ffa450edef68

The cluster implementation multicast periodic-timer controls and
executes the task when those controls are delivered, which is in the
cluster delivery thread context and so consistent across the cluster.


git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@903867 13f79535-47bb-0310-9956-ffa450edef68

Fix for the problem with a test to verify that messages going to the store
have the same headers and content-size for an updatee or a broker that
receives the publish directly.


git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@889813 13f79535-47bb-0310-9956-ffa450edef68