You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geode.apache.org by Avital Amity <Av...@Amdocs.com> on 2017/01/16 16:21:50 UTC
messages repeating when using CQ Query mechanism
Hi,
When using CQQuery mechanism, when moving from GEMFIRE to GEODE we see differences in server log files including many of the following messages:
[info ...] Entry expiry tasks disabled because the queue became primary. Old messageTimeToLive was: 180
[fine ...] Started closing CQ CqName: ... SendRequestToServer: false
These messages appear only once when working with Gemfire Server and many (too many) times when working with GEODE server
Any idea what could cause that? In the GEODE client there is only once the CLOSE_CQ trigger
Thanks
Avital
This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
Re: messages repeating when using CQ Query mechanism
Posted by Michael Stolz <ms...@pivotal.io>.
And what versions of Geode and GemFire and C++ client are you trying?
--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: 631-835-4771
On Mon, Jan 16, 2017 at 1:30 PM, Avital Amity <Av...@amdocs.com>
wrote:
> Thanks Jason for your comments
>
> Just to emphasize I'm running the exact same flow once with GEODE and once
> with GF, and tried it on several environments and go consistent results. I
> assume it can eliminate network issues
> These repeating messages are only when using the C++ client (no problem
> with using the java client with GEODE)
> There is only 1 client in this test
>
> Also please see inline
>
> -----Original Message-----
> From: Jason Huynh [mailto:jhuynh@pivotal.io]
> Sent: Monday, January 16, 2017 7:47 PM
> To: dev@geode.apache.org
> Subject: Re: messages repeating when using CQ Query mechanism
>
> Hello,
>
> I am not sure what would cause that to happen. Just some questions and
> ideas, it looks like the first log about disabling expiry is logged when we
> create the ha region queue, become a primary queue or start/restop (and
> only if the old time to live is > 0. After being the log, it should be set
> to 0, not sure why it keeps getting set back).
> [Avital Amity] I see this message usually prior to the expiry message:
> (again only in GEODE)
> invoking listeners: [org.apache.geode.internal.cache.ha.HARegionQueue$1@
> 63668e3a]
>
> The second message is logged obviously when the cq is closed. If the
> client is only doing it one time, I am not sure why you would see so many.
> Is it possible that there are many clients or some sort of loop? Is it
> closing the cq for the same cq name and is it on the same server? [Avital
> Amity] the name is the same for all closure messages, there are 2 servers
> with the exact same messages (and same name)
> Is it possible that there is some network issue that is causing the client
> to have to reconnect/re-establish a primary queue? Is the region getting
> destroyed?
>
>
> -Jason
>
>
> On Mon, Jan 16, 2017 at 8:31 AM Avital Amity <Av...@amdocs.com>
> wrote:
>
> > Hi,
> >
> > When using CQQuery mechanism, when moving from GEMFIRE to GEODE we see
> > differences in server log files including many of the following messages:
> >
> > [info ...] Entry expiry tasks disabled because the queue became primary.
> > Old messageTimeToLive was: 180
> > [fine ...] Started closing CQ CqName: ... SendRequestToServer: false
> >
> > These messages appear only once when working with Gemfire Server and
> > many (too many) times when working with GEODE server Any idea what
> > could cause that? In the GEODE client there is only once the CLOSE_CQ
> > trigger
> >
> > Thanks
> > Avital
> >
> > This message and the information contained herein is proprietary and
> > confidential and subject to the Amdocs policy statement, you may
> > review at http://www.amdocs.com/email_disclaimer.asp
> > This message and the information contained herein is proprietary and
> > confidential and subject to the Amdocs policy statement,
> >
> > you may review at http://www.amdocs.com/email_disclaimer.asp
> >
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at http://www.amdocs.com/email_disclaimer.asp
>
RE: messages repeating when using CQ Query mechanism
Posted by Avital Amity <Av...@Amdocs.com>.
Thanks Jason for your comments
Just to emphasize I'm running the exact same flow once with GEODE and once with GF, and tried it on several environments and go consistent results. I assume it can eliminate network issues
These repeating messages are only when using the C++ client (no problem with using the java client with GEODE)
There is only 1 client in this test
Also please see inline
-----Original Message-----
From: Jason Huynh [mailto:jhuynh@pivotal.io]
Sent: Monday, January 16, 2017 7:47 PM
To: dev@geode.apache.org
Subject: Re: messages repeating when using CQ Query mechanism
Hello,
I am not sure what would cause that to happen. Just some questions and ideas, it looks like the first log about disabling expiry is logged when we create the ha region queue, become a primary queue or start/restop (and only if the old time to live is > 0. After being the log, it should be set to 0, not sure why it keeps getting set back).
[Avital Amity] I see this message usually prior to the expiry message: (again only in GEODE)
invoking listeners: [org.apache.geode.internal.cache.ha.HARegionQueue$1@63668e3a]
The second message is logged obviously when the cq is closed. If the client is only doing it one time, I am not sure why you would see so many.
Is it possible that there are many clients or some sort of loop? Is it closing the cq for the same cq name and is it on the same server? [Avital Amity] the name is the same for all closure messages, there are 2 servers with the exact same messages (and same name)
Is it possible that there is some network issue that is causing the client to have to reconnect/re-establish a primary queue? Is the region getting destroyed?
-Jason
On Mon, Jan 16, 2017 at 8:31 AM Avital Amity <Av...@amdocs.com>
wrote:
> Hi,
>
> When using CQQuery mechanism, when moving from GEMFIRE to GEODE we see
> differences in server log files including many of the following messages:
>
> [info ...] Entry expiry tasks disabled because the queue became primary.
> Old messageTimeToLive was: 180
> [fine ...] Started closing CQ CqName: ... SendRequestToServer: false
>
> These messages appear only once when working with Gemfire Server and
> many (too many) times when working with GEODE server Any idea what
> could cause that? In the GEODE client there is only once the CLOSE_CQ
> trigger
>
> Thanks
> Avital
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement, you may
> review at http://www.amdocs.com/email_disclaimer.asp
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at http://www.amdocs.com/email_disclaimer.asp
>
This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
Re: messages repeating when using CQ Query mechanism
Posted by Jason Huynh <jh...@pivotal.io>.
Hello,
I am not sure what would cause that to happen. Just some questions and
ideas, it looks like the first log about disabling expiry is logged when we
create the ha region queue, become a primary queue or start/restop (and
only if the old time to live is > 0. After being the log, it should be set
to 0, not sure why it keeps getting set back).
The second message is logged obviously when the cq is closed. If the
client is only doing it one time, I am not sure why you would see so many.
Is it possible that there are many clients or some sort of loop? Is it
closing the cq for the same cq name and is it on the same server? Is is
possible that there is some network issue that is causing the client to
have to reconnect/re-establish a primary queue? Is the region getting
destroyed?
-Jason
On Mon, Jan 16, 2017 at 8:31 AM Avital Amity <Av...@amdocs.com>
wrote:
> Hi,
>
> When using CQQuery mechanism, when moving from GEMFIRE to GEODE we see
> differences in server log files including many of the following messages:
>
> [info ...] Entry expiry tasks disabled because the queue became primary.
> Old messageTimeToLive was: 180
> [fine ...] Started closing CQ CqName: ... SendRequestToServer: false
>
> These messages appear only once when working with Gemfire Server and many
> (too many) times when working with GEODE server
> Any idea what could cause that? In the GEODE client there is only once the
> CLOSE_CQ trigger
>
> Thanks
> Avital
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
> you may review at http://www.amdocs.com/email_disclaimer.asp
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at http://www.amdocs.com/email_disclaimer.asp
>
messages repeating when using CQ Query mechanism
Posted by Avital Amity <Av...@Amdocs.com>.
Hi,
When using CQQuery mechanism, when moving from GEMFIRE to GEODE we see differences in server log files including many of the following messages:
[info ...] Entry expiry tasks disabled because the queue became primary. Old messageTimeToLive was: 180
[fine ...] Started closing CQ CqName: ... SendRequestToServer: false
These messages appear only once when working with Gemfire Server and many (too many) times when working with GEODE server
Any idea what could cause that? In the GEODE client there is only once the CLOSE_CQ trigger
Thanks
Avital
This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp