Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
MIME-Version: 1.0
Sender: tbain98@gmail.com
In-Reply-To: <1506597254294-0.post@n4.nabble.com>
References: <1505744755822-0.post@n4.nabble.com> <1a02cefb-df45-4a43-d601-2eb844a8eb89@gmail.com>
 <1505799291832-0.post@n4.nabble.com> <CAPVVMa85fSLZ-en31iC9yVjKD2AStyPkiH1pBmrqgzqMFgAbbA@mail.gmail.com>
 <1505997867450-0.post@n4.nabble.com> <CAPVVMa88PV91FVPKhw01T3rce8kNuaA==GMx35cbh8FHRfY4tg@mail.gmail.com>
 <1506575107375-0.post@n4.nabble.com> <CAPVVMa-g2NZdHcnBHqE9nygjZVh5vJJ1WNSM52CgKoBrunr5DA@mail.gmail.com>
 <1506597254294-0.post@n4.nabble.com>
From: Tim Bain <tbain@alumni.duke.edu>
Date: Thu, 28 Sep 2017 07:07:40 -0600
Message-ID: <CAPVVMa8Gjtm3eGfvyagp_zvM5qti8VnZ7omWP3xqBdf4Hk+MhQ@mail.gmail.com>
Subject: Re: "allowLinkStealing" as a client configuration
To: ActiveMQ Users <users@activemq.apache.org>
Content-Type: multipart/alternative; boundary="001a114ab5d606495e055a3f9855"
archived-at: Thu, 28 Sep 2017 13:07:53 -0000

--001a114ab5d606495e055a3f9855
Content-Type: text/plain; charset="UTF-8"

Hmmm, interesting. That means one of two things:

1. Following the broker restart, multiple client processes/threads are
trying to connect using the same client ID. For a given client ID, the
first process/thread to attempt the connection will succeed, and the later
ones will fail. I would expect that enabling link stealing would result in
either a stalemate where all threads keep detecting that the link was
stolen from them and trying to steal it back, or a situation where the last
process/thread steals the link and keeps it. I expect the former, but have
never used link stealing so I'm not sure if that's actually how it works.
2. Following a broker restart, only one process/thread is using a given
client ID, but before it even connects the broker believes that a client is
already connected for that client ID and rejects all connections for that
client ID, which would be a bug. Enabling link stealing would result in
normal operation.

Based on what you've previously observed, can you tell which of the two
situations is actually occurring? I'd be looking for something like "I
examined all the connections in the MBeans tab of JConsole when this
problem was occurring, and I determined that none of them matched the
client ID that was getting rejected" to show conclusively that it was
situation #2 rather than #1, rather than something like "I'm sure I don't
have two process/threads for the same client ID."

If it's #2, is your organization open to attaching a debugger to the
production broker the next time this occurs, to allow you to step through
the broker initialization code to help us figure out what's going on?

Tim

On Sep 28, 2017 5:14 AM, "khandelwalanuj" <anuj.cool.khandelwal@gmail.com>
wrote:

> > Does restarting the broker without enabling link stealing also let you
> work
> > around the problem?
> Unfortunately No.  Restarting broker also doesn't solve the problem. Only
> when you restart it with link stealing resolves the issue.
>
> Thanks,
> Anuj
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> f2341805.html
>

--001a114ab5d606495e055a3f9855--