Maybe you shouldn't be using registerInterest at all if you don't have a
CacheListener.

If all you want is to ensure that you always get the latest version of data
on a client get(key), just switch your client Region to PROXY instead of
CACHING_PROXY, and don't even bother registering interest.

Interest registration without a CacheListener is very unusual.


--
Mike Stolz
Principal Engineer, GemFire Product Lead
Mobile: +1-631-835-4771

On Tue, Oct 24, 2017 at 11:37 AM, Mangesh Deshmukh <[email protected]>
wrote:

> The only workaround (unless your case is different) for this is to restart
> the client for which there is a queue build up. Not an elegant solution but
> have to deal with it until we have some kind of fix.
>
>
>
> Thanks,
>
> Mangesh
>
>
>
>
>
> *From: *Vahram Aharonyan <[email protected]>
> *Reply-To: *"[email protected]" <[email protected]>
> *Date: *Tuesday, October 24, 2017 at 7:37 AM
> *To: *"[email protected]" <[email protected]>
> *Subject: *RE: Client queue full
>
>
>
> Hi Mangesh, Anil,
>
>
>
> Thank you for useful info – I will go through the ticket and also
> heapdump/statistics locally to understand whether symptoms are the same or
> not.
>
> Meanwhile could you please help me with following. Once this situation is
> hit, it goes forever without recovering. What could help us to go out from
> that? Is cluster or specific node restart only way to get rid of this?
>
>
>
> Thanks,
>
> Vahram.
>
>
>
> *From:* Anilkumar Gingade [mailto:[email protected]]
> *Sent:* Monday, October 23, 2017 10:24 PM
> *To:* [email protected]
> *Subject:* Re: Client queue full
>
>
>
> Hi Vahram,
>
>
>
> The issue you are encountering and mangesh is seeing may be different...I
> would encourage you to see the ticket created for Mangesh's issue and the
> comments added, to see if they are same...Also the comments could help you
> to understand/diagnose your issue:
>
>
>
> https://issues.apache.org/jira/browse/GEODE-3709
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_GEODE-2D3709&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=wpTWSXVvcGFCkFEMePbOecdHHTbyiIj9aWq7oqKb0J8&m=zoGVUQTVlv3Hx2fRepad_fU7y0zAqgga8zDP4FJEiAg&s=e9RZ2otccA340_CHp7k5b-qwsV_IGfvTCWRMBZQQ49Y&e=>
>
>
>
> -Anil.
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Oct 23, 2017 at 9:42 AM, Mangesh Deshmukh <[email protected]>
> wrote:
>
> Hi Vahram,
>
>
>
> We are faced with similar issue resulting in the same kind of log
> statements. I have another thread with subject "Subscription Queue Full”.
> There is no resolution yet for that.
>
>
>
> Thanks,
>
> Mangesh
>
>
>
>
>
> *From: *Vahram Aharonyan <[email protected]>
> *Reply-To: *"[email protected]" <[email protected]>
> *Date: *Monday, October 23, 2017 at 6:33 AM
> *To: *"[email protected]" <[email protected]>
> *Subject: *Client queue full
>
>
>
> Hi,
>
>
>
> We have partitioned region and trying to invoke create(key, value) on
> that. On the other side we have listener registered so once new entry is
> created we should get notified. Instead of that we’re hitting this kind of
> messages continuously:
>
>
>
> [warning 2017/10/23 05:23:38.145 PDT 31d0a20b-d81d-490b-b2ff-19645ed52387
> <Task Processor worker thread 4> tid=0x5c0] Client queue for
> _gfe_non_durable_client_with_id_remote(74e9ba70-d7fc-47a1-
> abbc-4d9066511049:20486:loner):44573:bbf05510: 
> 74e9ba70-d7fc-47a1-abbc-4d9066511049_2_queue
> client is full.
>
>
>
> [info 2017/10/23 05:23:38.497 PDT 31d0a20b-d81d-490b-b2ff-19645ed52387
> <Task Processor worker thread 4> tid=0x5c0] Resuming with processing puts
> ...
>
>
>
> [warning 2017/10/23 05:43:54.778 PDT 31d0a20b-d81d-490b-b2ff-19645ed52387
> <SavePropertiesCompletionHandler> tid=0x100] Client queue for
> _gfe_non_durable_client_with_id_remote(74e9ba70-d7fc-47a1-
> abbc-4d9066511049:20486:loner):44573:bbf05510: 
> 74e9ba70-d7fc-47a1-abbc-4d9066511049_2_queue
> client is full.
>
>
>
> [info 2017/10/23 05:43:54.879 PDT 31d0a20b-d81d-490b-b2ff-19645ed52387 <
> SavePropertiesCompletionHandler> tid=0x100] Resuming with processing puts
> ...
>
>
>
> Could someone provide some information in which circumstances this queue
> gets full and how it should be emptied?
>
>
>
> Thanks,
>
> Vahram.
>
>
>

Reply via email to