Wes, If you're actually using the tcServer session module you should be reading this: http://gemfire.docs.pivotal.io/latest/tools_modules/http_session_mgmt/tc_changing_gf_default_cfg.html
How are you starting the servers? What are the startup options and configuration (cache.xml and properties). --Jens On Wed, Sep 30, 2015 at 11:16 AM, Real Wes Williams <[email protected]> wrote: > Hi Dan, > > I can see that this issue is becoming more nuanced. No files were moved > and it is extremely unlikely that disk corruption is involved. gfsh reports > that a disk store is missing and “revoke missing-disk-stores” alleviates > the problem. However, I am also using the HTTP Session Replication Module, > which I just learned has its own embedded cache.xml ( > http://gemfire.docs.pivotal.io/latest/tools_modules/http_session_mgmt/weblogic_changing_gf_default_cfg.html > < > http://gemfire.docs.pivotal.io/latest/tools_modules/http_session_mgmt/weblogic_changing_gf_default_cfg.html > >). > > The original thought was to share a single cluster between user-defined > regions and the http session module. The cache.xml for the user-defined > regions has a disk-store defined. I suspect that the http session module > cache.xml may also... the region is defined as persistent. > > My working hypothesis at present is that the two definitions are colliding > with one another somehow? > > The repeatable problem occurs when: > 1) cluster starts > 2) tomcat starts > 3) cluster bounces - “missing disk store” - missing for the sessions > region but not the user region? > > I am investigating but I will need to coordinate with others to get the > http session module cache.xml. > > Do you know if a single cluster can be shared between the http session > module cache.xml and a different set of xml? The regions specified in each > get created. > > Thank you for the reply! > > > On Sep 30, 2015, at 1:41 PM, Dan Smith <[email protected]> wrote: > > > > Hi Wes, > > > > A few questions: > > 1) Are you sure your disk store is actually there - in the same location > > as reported by list missing disk stores? > > 2) Are you sure you've started all members and the members are still > > waiting? Use list members and list disk missing disk stores in gfsh to > > confirm. > > 3) Did you move or delete files from that location at some point? Even if > > gemfire recreates files in the same location, it will still report the > old > > files as missing, because the disk store is a assigned a unique id which > is > > what geode really cares about. > > > > -Dan > > > > On Wed, Sep 30, 2015 at 10:29 AM, Real Wes Williams < > [email protected]> > > wrote: > > > >> > >> Page 779 of the User's Guide at > >> http://gemfire.docs.pivotal.io/pdf/pivotal-gemfire-ug.pdf < > >> http://gemfire.docs.pivotal.io/pdf/pivotal-gemfire-ug.pdf> describes > the > >> administrative procedure "revoke missing-disk-store” to cleanly proceed > >> when there is a missing disk store. > >> > >> I am experiencing this but there are disk stores in the cache server on > >> which other cache servers are waiting. All I did was a shutdown via gfsh > >> and restarted using a new jar and a cache.xml function name change. > >> > >> Why do disk store’s report as missing when they are ostensibly not > >> missing ?? > >> > >> -rw-r--r--. 1 gemfire pivotal 1829 Sep 28 15:49 BACKUPDEFAULT_3.crf > >> -rw-r--r--. 1 gemfire pivotal 260 Sep 28 15:49 BACKUPDEFAULT_3.drf > >> -rw-r--r--. 1 gemfire pivotal 1758 Sep 23 12:50 BACKUPDEFAULT_3.krf > >> -rw-r--r--. 1 gemfire pivotal 2951 Sep 29 13:18 BACKUPDEFAULT_5.crf > >> -rw-r--r--. 1 gemfire pivotal 260 Sep 29 13:18 BACKUPDEFAULT_5.drf > >> -rw-r--r--. 1 gemfire pivotal 5242880 Sep 28 15:49 BACKUPDEFAULT.if > >> > >> > >> > >
