If a client is using CACHING_PROXY for a region in this scenario would its puts block on the full client queue in this scenario?
On Wednesday, October 14, 2015, Barry Oglesby <[email protected]> wrote: > Processing a client queue is asynchronous to the client operations, but > adding to the queue is synchronous with them. So any client operation that > needs to access the full queue will be blocked waiting for space to become > available in it. That means any put operation from any client will block if > the client with the full queue cares about that event. Depending on your > client pool read-timeout, you could see client put operations timing out. > > The processing of other client queues shouldn't be affected by this since > that processing is asynchronous from anything going on with the full queue. > My guess would be those client queues are empty and only sporadically > getting events added to them because a bunch of the putting threads are > blocked. > > There is a property called remove-unresponsive-client (false by default) > that you can use to kick out the full client so that other client > operations are not affected. > > You can also raise the cache-server maximum-message-count, but that will > probably just delay the issue. > > > Barry Oglesby > GemFire Advanced Customer Engineering (ACE) > For immediate support please contact Pivotal Support at > http://support.pivotal.io/ > > > On Wed, Oct 14, 2015 at 2:29 PM, Eric Pederson <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> Dear all: >> >> I was tracking down an issue with a client that was receiving events late >> (receipt time minutes later than sending time) and started spuriously >> connecting/reconnecting to the server, ultimately losing some events. >> >> In the server log I saw this during the same time period: >> >> [warning 2015/10/13 16:28:48.551 EDT server-psclxfiprdsp104 >> <ServerConnection on port 37386 Thread 696> tid=0x66b] Client queue for >> _gfe_non_durable_client_with_id_NYCWD28244(:loner):62826:929faf61_1_queue >> client is full. >> >> >> >> [info 2015/10/13 16:28:48.693 EDT server-psclxfiprdsp104 >> <ServerConnection on port 37386 Thread 696> tid=0x66b] Resuming with >> processing puts ... >> >> >> The client that was full was a different client from the one that was >> getting its events late. >> >> >> Is it possible that if a client is slow consuming its events (via CQ) and >> its server-side queue becomes full that other clients will be effected? GC >> activity looked normal on that server during the time period. >> >> >> Thanks, >> >> -- Eric >> > > -- Sent from Gmail Mobile
