Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 885201

Summary: unresponsive cluster set-up using mixed auth yes/no
Product: Red Hat Enterprise MRG Reporter: Petr Matousek <pematous>
Component: qpid-cppAssignee: mick <mgoulish>
Status: CLOSED UPSTREAM QA Contact: MRG Quality Engineering <mrgqe-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: DevelopmentCC: jross
Target Milestone: ---Keywords: Documentation
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2025-02-10 03:27:08 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
broker5672.gdbinfo broker_5672.log broker_5673.gdbinfo broker_5673.log spout_pstack.txt none

Description Petr Matousek 2012-12-07 18:38:33 UTC
Description of problem:

Try to set-up two node cluster, use auth=yes for broker1 and auth=no for broker2.

Broker1 notices following event:
2012-12-07 20:05:08 [HA] error Un-authenticated attempt to join the cluster

Broker2 tries to get updates from broker1:
2012-12-07 20:05:08 [HA] notice cluster(192.168.122.240:17938 UPDATEE) receiving update from 192.168.122.240:17929

After that the cluster appears to be in some corrupted state. It is not possible to communicate with the broker using clients. The clients seems to be hanged.

ie. following command never ends:
# spout amq.direct

Also qpid-tools are unresponsive.

This situation remains even if broker2 is stopped.

Version-Release number of selected component (if applicable):
qpid-cpp-*-0.18-12

How reproducible:
100%

Steps to Reproduce:
1. qpidd --cluster-name pematous --data-dir=broker1 auth=yes >&broker1.log &
2. qpidd -p 5673 --cluster-name pematous --data-dir=broker2 --auth=no >&broker2.log
3. run some client
  
Actual results:
Client is not able to communicate with the cluster

Expected results:
Broker2 exits with authentication required by broker1, broker1 remains functional

Comment 1 Petr Matousek 2012-12-07 18:44:01 UTC
Created attachment 659547 [details]
broker5672.gdbinfo  broker_5672.log  broker_5673.gdbinfo  broker_5673.log  spout_pstack.txt

brokers logs and traces

Comment 2 Ted Ross 2012-12-07 18:49:15 UTC
This is an unsupported configuration.  All members of a cluster must be configured identically.

Comment 3 Justin Ross 2012-12-10 18:45:22 UTC
(In reply to comment #2)
> This is an unsupported configuration.  All members of a cluster must be
> configured identically.

I'll move this to 2.4 just to do some extra checking that the documentation is clear on this point.

Comment 4 Red Hat Bugzilla 2025-02-10 03:27:08 UTC
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.