<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Gemfire timeout problems - Distributed Visual Analytics in Administration and Deployment</title>
    <link>https://communities.sas.com/t5/Administration-and-Deployment/Gemfire-timeout-problems-Distributed-Visual-Analytics/m-p/371552#M9177</link>
    <description>&lt;P&gt;&lt;a href="https://communities.sas.com/t5/user/viewprofilepage/user-id/74922"&gt;@miki7&lt;/a&gt;,&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Yes, you can increase the timeout value. Stop all the midtier services, SAS Cache Locator, then edit /&amp;lt;SASConfig&amp;gt;/Lev&amp;lt;X&amp;gt;/Web/gemfire/instances/ins_41415/gemfire-start-locator-sas.sh, add the following JVM parameters to the JAVA_ARGS="" value:&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;PRE&gt;-Dgemfire.conserve-sockets=false -Dgemfire.member-timeout=30000&lt;/PRE&gt;
&lt;P&gt;Also, its worth to adjust Dgemfire.member-timeout in /&amp;lt;SASConfig&amp;gt;/Lev&amp;lt;X&amp;gt;/Web/WebAppServer/SASServer1_1/bin/setenv.sh (JVM_OPTS):&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;PRE&gt;-Dgemfire.member-timeout=30000&lt;/PRE&gt;
&lt;P&gt;Start all the midtier services after these changes.&lt;/P&gt;</description>
    <pubDate>Thu, 29 Jun 2017 07:17:29 GMT</pubDate>
    <dc:creator>alexal</dc:creator>
    <dc:date>2017-06-29T07:17:29Z</dc:date>
    <item>
      <title>Gemfire timeout problems - Distributed Visual Analytics</title>
      <link>https://communities.sas.com/t5/Administration-and-Deployment/Gemfire-timeout-problems-Distributed-Visual-Analytics/m-p/371539#M9175</link>
      <description>&lt;P&gt;Dear SAS Communities,&lt;/P&gt;&lt;P&gt;as a partner of SAS we have client with Visual Analytics distributed solution installed.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;In this solution we have these servers:&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;1 compute node&lt;/P&gt;&lt;P&gt;2 middle-tiers&lt;/P&gt;&lt;P&gt;1 metadata&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;In last few weeks, we started to have problems with failing gemfire locator, which led to complete fall of web applications where login screen says "blablah&amp;nbsp;&lt;/P&gt;&lt;P&gt;Please contact your administrator for assistance"&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;The problem is &amp;nbsp;(as we believe) with communication between middle-tier 1 and middle-tier 2, where all webapps including VA and SASStudio runs.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;My main question is: &lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;What do you think about increasing the timeout value for gemfire communication between servers? Could be 5 sec too little time? Could be increasing it to like 1 min or more problem?&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Here's short sample from gemfire.log on one of middtiers (this one from mid_tier02, but mid_tier01 has nearly same log just with swapped server-name values):&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;[info 2017/06/28 21:12:10.310 CEST &amp;lt;VERIFY_SUSPECT.TimerThread&amp;gt; tid=0x55] No suspect verification response received from %MID_TIER01%(54776)&amp;lt;v3&amp;gt;:37678 in 5989 milliseconds: I believe it is gone.&lt;/P&gt;&lt;P&gt;[info 2017/06/28 21:12:11.312 CEST &amp;lt;UDP ucast receiver&amp;gt; tid=0x1e] Member %MID_TIER01%(50790)&amp;lt;v1&amp;gt;:50358 is no longer suspect&lt;/P&gt;&lt;P&gt;[info 2017/06/28 21:12:11.312 CEST &amp;lt;UDP ucast receiver&amp;gt; tid=0x1e] failure detection received notification that %MID_TIER01%(50790)&amp;lt;v1&amp;gt;:50358 is no longer suspect&lt;/P&gt;&lt;P&gt;[info 2017/06/28 21:12:12.315 CEST &amp;lt;UDP ucast receiver&amp;gt; tid=0x1e] Member %MID_TIER01%(50790)&amp;lt;v1&amp;gt;:50358 is no longer suspect&lt;/P&gt;&lt;P&gt;[info 2017/06/28 21:12:12.315 CEST &amp;lt;UDP ucast receiver&amp;gt; tid=0x1e] failure detection received notification that %MID_TIER01%(50790)&amp;lt;v1&amp;gt;:50358 is no longer suspect&lt;/P&gt;&lt;P&gt;[info 2017/06/28 21:12:13.317 CEST &amp;lt;UDP ucast receiver&amp;gt; tid=0x1e] Member %MID_TIER01%(54776)&amp;lt;v3&amp;gt;:37678 is no longer suspect&lt;/P&gt;&lt;P&gt;[info 2017/06/28 21:12:13.317 CEST &amp;lt;UDP ucast receiver&amp;gt; tid=0x1e] failure detection received notification that %MID_TIER01%(54776)&amp;lt;v3&amp;gt;:37678 is no longer suspect&lt;/P&gt;&lt;P&gt;[info 2017/06/28 21:12:14.319 CEST &amp;lt;UDP ucast receiver&amp;gt; tid=0x1e] Member %MID_TIER01%(50790)&amp;lt;v1&amp;gt;:50358 is no longer suspect&lt;/P&gt;&lt;P&gt;[info 2017/06/28 21:12:14.319 CEST &amp;lt;UDP ucast receiver&amp;gt; tid=0x1e] failure detection received notification that %MID_TIER01%(50790)&amp;lt;v1&amp;gt;:50358 is no longer suspect&lt;/P&gt;&lt;P&gt;[info 2017/06/28 21:12:15.031 CEST &amp;lt;FD_SOCK Ping thread&amp;gt; tid=0x24] suspecting member %MID_TIER02%(63477)&amp;lt;v6&amp;gt;:40788&lt;/P&gt;&lt;P&gt;[info 2017/06/28 21:12:15.031 CEST &amp;lt;UDP Incoming Message Handler&amp;gt; tid=0x1d] Received Suspect notification for member(s) [%MID_TIER02%(60274)&amp;lt;v5&amp;gt;:21007] from %MID_TIER02%(59925)&amp;lt;v4&amp;gt;:7935.&lt;/P&gt;&lt;P&gt;[info 2017/06/28 21:12:15.180 CEST &amp;lt;ViewHandler&amp;gt; tid=0x44] Membership: sending new view [[%MID_TIER02%(59925)&amp;lt;v4&amp;gt;:7935|19] [%MID_TIER02%(59925)&amp;lt;v4&amp;gt;:7935/56543, %MID_TIER02%(63477)&amp;lt;v6&amp;gt;:40788/56113, %MID_TIER02%(64709)&amp;lt;v7&amp;gt;:55906/49673]] (3 mbrs)&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;[info 2017/06/28 21:12:15.321 CEST &amp;lt;UDP ucast receiver&amp;gt; tid=0x1e] Member %MID_TIER01%(50790)&amp;lt;v1&amp;gt;:50358 is no longer suspect&lt;/P&gt;&lt;P&gt;[info 2017/06/28 21:12:15.322 CEST &amp;lt;UDP ucast receiver&amp;gt; tid=0x1e] failure detection received notification that %MID_TIER01%(50790)&amp;lt;v1&amp;gt;:50358 is no longer suspect&lt;/P&gt;&lt;P&gt;[info 2017/06/28 21:12:15.322 CEST &amp;lt;UDP ucast receiver&amp;gt; tid=0x1e] Member %MID_TIER01%(54776)&amp;lt;v3&amp;gt;:37678 is no longer suspect&lt;/P&gt;&lt;P&gt;[info 2017/06/28 21:12:15.323 CEST &amp;lt;UDP ucast receiver&amp;gt; tid=0x1e] failure detection received notification that %MID_TIER01%(54776)&amp;lt;v3&amp;gt;:37678 is no longer suspect&lt;/P&gt;&lt;P&gt;[info 2017/06/28 21:12:15.323 CEST &amp;lt;UDP Incoming Message Handler&amp;gt; tid=0x1d] Received Suspect notification for member(s) [%MID_TIER02%(60274)&amp;lt;v5&amp;gt;:21007, %MID_TIER02%(63477)&amp;lt;v6&amp;gt;:40788] from %MID_TIER02%(59925)&amp;lt;v4&amp;gt;:7935.&lt;/P&gt;&lt;P&gt;[info 2017/06/28 21:12:15.324 CEST &amp;lt;UDP Incoming Message Handler&amp;gt; tid=0x1d] Membership: received new view [%MID_TIER02%(59925)&amp;lt;v4&amp;gt;:7935|19] [%MID_TIER02%(59925)&amp;lt;v4&amp;gt;:7935/56543, %MID_TIER02%(63477)&amp;lt;v6&amp;gt;:40788/56113, %MID_TIER02%(64709)&amp;lt;v7&amp;gt;:55906/49673]&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thank you very much and have a nice day!&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Michal&lt;/P&gt;</description>
      <pubDate>Thu, 29 Jun 2017 06:23:11 GMT</pubDate>
      <guid>https://communities.sas.com/t5/Administration-and-Deployment/Gemfire-timeout-problems-Distributed-Visual-Analytics/m-p/371539#M9175</guid>
      <dc:creator>miki7</dc:creator>
      <dc:date>2017-06-29T06:23:11Z</dc:date>
    </item>
    <item>
      <title>Re: Gemfire timeout problems - Distributed Visual Analytics</title>
      <link>https://communities.sas.com/t5/Administration-and-Deployment/Gemfire-timeout-problems-Distributed-Visual-Analytics/m-p/371552#M9177</link>
      <description>&lt;P&gt;&lt;a href="https://communities.sas.com/t5/user/viewprofilepage/user-id/74922"&gt;@miki7&lt;/a&gt;,&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Yes, you can increase the timeout value. Stop all the midtier services, SAS Cache Locator, then edit /&amp;lt;SASConfig&amp;gt;/Lev&amp;lt;X&amp;gt;/Web/gemfire/instances/ins_41415/gemfire-start-locator-sas.sh, add the following JVM parameters to the JAVA_ARGS="" value:&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;PRE&gt;-Dgemfire.conserve-sockets=false -Dgemfire.member-timeout=30000&lt;/PRE&gt;
&lt;P&gt;Also, its worth to adjust Dgemfire.member-timeout in /&amp;lt;SASConfig&amp;gt;/Lev&amp;lt;X&amp;gt;/Web/WebAppServer/SASServer1_1/bin/setenv.sh (JVM_OPTS):&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;PRE&gt;-Dgemfire.member-timeout=30000&lt;/PRE&gt;
&lt;P&gt;Start all the midtier services after these changes.&lt;/P&gt;</description>
      <pubDate>Thu, 29 Jun 2017 07:17:29 GMT</pubDate>
      <guid>https://communities.sas.com/t5/Administration-and-Deployment/Gemfire-timeout-problems-Distributed-Visual-Analytics/m-p/371552#M9177</guid>
      <dc:creator>alexal</dc:creator>
      <dc:date>2017-06-29T07:17:29Z</dc:date>
    </item>
  </channel>
</rss>

