The client configuration won't make any difference to the server behavior. The server threads processing the client requests are the ones that block on the put into the queue (or waiting for a replicate to do it).
Barry Oglesby GemFire Advanced Customer Engineering (ACE) For immediate support please contact Pivotal Support at http://support.pivotal.io/ On Thu, Oct 15, 2015 at 2:26 PM, Eric Pederson <[email protected]> wrote: > 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]> 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 >
