Hi Mark, We use org.apache.geode.cache.Region#registerInterestRegex(java.lang.String) that is without specifying return policy. Does it mean that all keys and values matching this regexp will be returned to caller immediately during registerInterest() call even irrespective to the Region type that is set to PROXY in our case?
Thanks, Vahram. From: Mark Secrist [mailto:[email protected]] Sent: Monday, February 19, 2018 6:59 PM To: [email protected] Subject: Re: IOExcpetion with Part length () and number of parts () inconsistent during registerInterest I'm not sure exactly what your registerInterest call looks like, but you may want to use the method that takes an additional argument of enum type InterestResultPolicy as that specifies the behavior when making the call. The default is to immediately return all keys and values to the caller. You may consider instead an enum value of NONE or KEYS. On Feb 19, 2018 7:48 AM, "Vahram Aharonyan" <[email protected]<mailto:[email protected]>> wrote: Hi All, We are getting following exception while trying to register interest on some Region on client boot. 2018-02-12 19:12:22,975 INFO [Heartbeat] com.integrien.alive.collector.HeartbeatThread.doHeartBeat - Heartbeat failed: Pool unexpected IOException connection=SubscriptionConnectionImpl[10.194.13.202:10000:closed]). Server unreachable: could not connect after 1 attempts 2018-02-12 19:12:22,975 DEBUG [Heartbeat] com.integrien.alive.collector.HeartbeatThread.doHeartBeat - The reason was: org.apache.geode.cache.client.ServerConnectivityException: Pool unexpected IOException connection=SubscriptionConnectionImpl[10.194.13.202:10000:closed]). Server unreachable: could not connect after 1 attempts at org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:798) at org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:623) at org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnQueuesAndReturnPrimaryResult(OpExecutorImpl.java:569) at org.apache.geode.cache.client.internal.PoolImpl.executeOnQueuesAndReturnPrimaryResult(PoolImpl.java:805) at org.apache.geode.cache.client.internal.RegisterInterestOp.execute(RegisterInterestOp.java:58) at org.apache.geode.cache.client.internal.ServerRegionProxy.registerInterest(ServerRegionProxy.java:362) at org.apache.geode.internal.cache.LocalRegion.processSingleInterest(LocalRegion.java:3917) at org.apache.geode.internal.cache.LocalRegion.registerInterestRegex(LocalRegion.java:3999) at org.apache.geode.internal.cache.LocalRegion.registerInterestRegex(LocalRegion.java:3982) at org.apache.geode.internal.cache.LocalRegion.registerInterestRegex(LocalRegion.java:3978) at com.vmware.vcops.platform.common.collector.GemfireCommunicator.registerInterest(GemfireCommunicator.java:336) at com.vmware.vcops.platform.common.collector.GemfireCommunicator.heartbeat(GemfireCommunicator.java:100) at com.integrien.alive.collector.HeartbeatThread.doHeartBeat(HeartbeatThread.java:77) at com.integrien.alive.collector.HeartbeatThread.run(HeartbeatThread.java:113) at com.integrien.alive.common.util.BaseThread$BaseThreadRunnable.run(BaseThread.java:176) at java.lang.Thread.run(Thread.java:748) Caused by: java.io.IOException: Part length ( -1,791,928,534 ) and number of parts ( 1 ) inconsistent at org.apache.geode.internal.cache.tier.sockets.Message.readPayloadFields(Message.java:826) at org.apache.geode.internal.cache.tier.sockets.ChunkedMessage.readChunk(ChunkedMessage.java:275) at org.apache.geode.internal.cache.tier.sockets.ChunkedMessage.receiveChunk(ChunkedMessage.java:227) at org.apache.geode.cache.client.internal.RegisterInterestOp$RegisterInterestOpImpl.processResponse(RegisterInterestOp.java:184) at org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:159) at org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:382) at org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:266) at org.apache.geode.cache.client.internal.QueueConnectionImpl.execute(QueueConnectionImpl.java:165) at org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:900) at org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnQueuesAndReturnPrimaryResult(OpExecutorImpl.java:562) ... 13 more 1. I’ve seen couple of tickets on Geode with similar stacktraces: GEODE-2517<https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_GEODE-2D2517&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=wpTWSXVvcGFCkFEMePbOecdHHTbyiIj9aWq7oqKb0J8&m=MuQ2hlU1zYFVwrnTUeHb1gchZX6fgQMMkBVUP-5MtJg&s=NpR9Caf3G7MXsQxBAAxec-XrUlgT4Oog-1vnnFPTFIk&e=>, GEODE-478<https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_GEODE-2D478&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=wpTWSXVvcGFCkFEMePbOecdHHTbyiIj9aWq7oqKb0J8&m=MuQ2hlU1zYFVwrnTUeHb1gchZX6fgQMMkBVUP-5MtJg&s=Zd1jc0HIe19Na0SyZFmJwT5rMKg8CHv1NfwFZjm_z2E&e=> and they all refer to the fact that huge amount of data is being transferred between client and server. But for me it is strange what can cause large data transfer during generic registerInterest call from client side. Could someone have info what kind of response client is receiving from Server during RegisterInterest that is so huge? And is there any workaround (parameter value tune) we can try to get out of this situation? Thanks, Vahram.
