Queue Channel backed by GemfireMessageStore restricted to LOCAL_PERSISTENT?

[bout01]

My team has recently been working on putting together a Spring Integration system that uses, as an error channel, a GemfireMessageStore-backed queue channel. Our initial attempts were to use a PROXY (failed miserably - all messages were dropped.) We then attempted a CACHING_PROXY. In the CACHING_PROXY model, the queue would work until the system failed, then when the system was brought back up, all of the messages resident in the GemfireMessageStore were subsequently dropped - unless we wrote to the GemfireMessageStore before it had emptied itself!)

It now appears that if we run with our GemfireMessageStore set to a LOCAL_PERSISTENT, things work out okay. However, this isn't really what we want to have happening. Ideally, we'd want the PROXY setup, and if that wouldn't work we'd want the CACHING_PROXY setup.

Which part of the picture are we not understanding, here?

Here are the relevant parts of the setup:

   <bean id="gemfireMessageStore" class="org.springframework.integration.gemfire.store.GemfireMessageStore">
      <constructor-arg ref="MessageStoreCache"/>
   </bean>

   <int:channel id="failedDeliveryMessageStoreQueueChannel">
      <int:queue message-store="gemfireMessageStore"/>
   </int:channel>

   <gfe:client-cache id="MessageStoreCache" pool-name="MessageStorePool"/>
   <gfe:client-region id="messageStoreRegion" cache-ref="MessageStoreCache" shortcut="LOCAL_PERSISTENT"/>

   <gfe:pool id="MessageStorePool" subscription-enabled="true">
      <gfe:server host="localhost" port="40404"/>
   </gfe:pool>

The 'int' ns is, of course, Spring Integration, and 'gfe' is Gemfire.

Any help would be greatly appreciated.

[dturanski]

I can look into this. Can you tell me what version of spring-gemfire and gemfire you are using?

[bout01]

You bet.

Spring-Gemfire: 1.1.1.RELEASE
Gemfire: 6.6.2

Thx.

[dturanski]

I assume you have the region 'messageStroreRegion' configured in the cache server? If so, how is it configured?

[bout01]

When attempting to use the PROXY and the CACHING_PROXY shortcuts, we did have the messageStoreRegion defined in the cache server. On the LOCAL_PERSISTENCE, no (as, if I'm not mistaken, it does not matter.)

[bout01]

When it was defined on the cache server, it was defined as:

<?xml version="1.0"?>

<!DOCTYPE cache PUBLIC
  "-//GemStone Systems, Inc.//GemFire Declarative Caching 6.5//EN"
  "http://www.gemstone.com/dtd/cache6_5.dtd">
<cache>

   <cache-server port="40404"/>

   <disk-store name="ds1" auto-compact="true" max-oplog-size="1024" queue-size="10000" time-interval="60">
      <disk-dirs>
         <disk-dir dir-size="4096">DatastoreDir</disk-dir>
      </disk-dirs>
   </disk-store>

   <region name="messageStoreRegion">
      <region-attributes refid="REPLICATE_PERSISTENT" disk-store-name="ds1" disk-synchronous="false" scope="distributed-no-ack">
      </region-attributes>
   </region>

</cache>

[dturanski]

'PROXY' is what you ultimately want. This should maintain the state in the cache server and no messages should be lost. However when I set shortcut="PROXY" in your configuration , I get

Caused by: java.lang.UnsupportedOperationException: operation is not supported on a client cache
	at com.gemstone.gemfire.internal.cache.GemFireCacheImpl.createRegionFactory(GemFireCacheImpl.java:4035)
	at org.springframework.data.gemfire.RegionFactoryBean.lookupFallback(RegionFactoryBean.java:86)
	at org.springframework.data.gemfire.RegionLookupFactoryBean.afterPropertiesSet(RegionLookupFactoryBean.java:59)
	at org.springframework.data.gemfire.RegionFactoryBean.afterPropertiesSet(RegionFactoryBean.java:71)
	at org.springframework.integration.gemfire.store.GemfireMessageStore.afterPropertiesSet(GemfireMessageStore.java:71)
	... 40 more

This is bug in GemfireMessageStore, due to Gemfire API changes introduced in 6.6.1. I will create a JIRA for it.

[bout01]

That is exactly the response we were getting!

Nice to hear that we're not completely crazy on this side.

Looking forward to the JIRA outcome.

Thanks.

[oleg.zhurakousky]

Actually it would be more appropriate if you guys raise a JIRA since you've discovered a problem and you can link it to this forum to maintain traceability. https://jira.springsource.org/browse/INT

Thanks

[dturanski]

https://jira.springsource.org/browse/INT-2552