[jira] [Updated] (GEODE-2775) Pulse is not using certificate to connect to JMX when ssl is turned for jmx connection

[Jinmei Liao (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jinmei Liao updated GEODE-2775:
---
Affects Version/s: 1.1.1

> Pulse is not using certificate to connect to JMX when ssl is turned for jmx 
> connection
> --
>
> Key: GEODE-2775
> URL: https://issues.apache.org/jira/browse/GEODE-2775
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.1.1
>Reporter: Jinmei Liao
>
> Steps to reproduce:
> 1) start a locator with a SecurityManager and with this property: 
> ssl-enabled-components=jmx
> 2) start a browser and tries to login to pulse.
> Actual result: not able to log in using valid username/password



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2775) Pulse is not using certificate to connect to JMX when ssl is turned for jmx connection

[Jinmei Liao (JIRA)]

Jinmei Liao created GEODE-2775:
--

 Summary: Pulse is not using certificate to connect to JMX when ssl 
is turned for jmx connection
 Key: GEODE-2775
 URL: https://issues.apache.org/jira/browse/GEODE-2775
 Project: Geode
  Issue Type: Bug
  Components: pulse
Reporter: Jinmei Liao


Steps to reproduce:

1) start a locator with a SecurityManager and with this property: 
ssl-enabled-components=jmx
2) start a browser and tries to login to pulse.

Actual result: not able to log in using valid username/password



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 58372: GEODE-2694: recovered from disk user bit after gii

[anilkumar gingade]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58372/#review171662
---


Ship it!




Ship It!

- anilkumar gingade


On April 11, 2017, 11:40 p.m., Eric Shu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58372/
> ---
> 
> (Updated April 11, 2017, 11:40 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Darrel Schneider, and Lynn 
> Gallinat.
> 
> 
> Bugs: GEODE-2694
> https://issues.apache.org/jira/browse/GEODE-2694
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> It seems that the current implementation of clearing recovered from disk bit 
> is correct. The bit will be used to removed the entry with unfinished op when 
> finishing the gii.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/GIIDeltaDUnitTest.java
>  950eb43 
> 
> 
> Diff: https://reviews.apache.org/r/58372/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin.
> 
> 
> Thanks,
> 
> Eric Shu
> 
>

[jira] [Updated] (GEODE-2774) CI failure: LuceneIndexDestroyDUnitTest.verifyDestroyAllIndexesWhileDoingPuts

[Shelley Lynn Hughes-Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shelley Lynn Hughes-Godfrey updated GEODE-2774:
---
Affects Version/s: 1.2.0

> CI failure: LuceneIndexDestroyDUnitTest.verifyDestroyAllIndexesWhileDoingPuts
> -
>
> Key: GEODE-2774
> URL: https://issues.apache.org/jira/browse/GEODE-2774
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>
> {noformat}
> :geode-lucene:testClassesat 
> org.apache.geode.internal.Assert.fail(Assert.java:68)
> at 
> org.apache.geode.cache.lucene.LuceneIndexDestroyDUnitTest.verifyDestroyAllIndexesWhileDoingPuts(LuceneIndexDestroyDUnitTest.java:215)
> org.apache.geode.cache.RegionDestroyedException: Partitioned Region 
> @1a3e3379 [path='/region'; dataPolicy=PERSISTENT_PARTITION; prId=76; 
> isDestroyed=false; isClosed=false; retryTimeout=360; serialNumber=1315; 
> partition 
> attributes=PartitionAttributes@1060958737[redundantCopies=0;localMaxMemory=100;totalMaxMemory=2147483647;totalNumBuckets=10;partitionResolver=null;colocatedWith=null;recoveryDelay=-1;startupRecoveryDelay=0;FixedPartitionAttributes=null;partitionListeners=null];
>  on VM 172.17.0.5(154):32770], caused by 
> org.apache.geode.cache.RegionDestroyedException: 
> 172.17.0.5(154):32770@org.apache.geode.internal.cache.PartitionedRegionDataStore@983990329
>  name: /AsyncEventQueue_index1#_region_PARALLEL_GATEWAY_SENDER_QUEUE bucket 
> count: 2, caused by org.apache.geode.cache.RegionDestroyedException: 
> Partitioned Region @32c5de26 
> [path='/AsyncEventQueue_index1#_region_PARALLEL_GATEWAY_SENDER_QUEUE'; 
> dataPolicy=PERSISTENT_PARTITION; prId=78; isDestroyed=true; isClosed=false; 
> retryTimeout=360; serialNumber=1340; partition 
> attributes=PartitionAttributes@2128111693[redundantCopies=0;localMaxMemory=1000;totalMaxMemory=2147483647;totalNumBuckets=10;partitionResolver=null;colocatedWith=/region;recoveryDelay=-1;startupRecoveryDelay=0;FixedPartitionAttributes=null;partitionListeners=null];
>  on VM 172.17.0.5(154):32770]
> at 
> org.apache.geode.internal.cache.PartitionedRegion.virtualPut(PartitionedRegion.java:1954)
> at 
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:151)
> at 
> org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5194)
> at 
> org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1605)
> at 
> org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1592)
> at 
> org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:279)
> at 
> org.apache.geode.cache.lucene.LuceneIndexDestroyDUnitTest.doPutsUntilStopped(LuceneIndexDestroyDUnitTest.java:523)
> at 
> org.apache.geode.cache.lucene.LuceneIndexDestroyDUnitTest.lambda$verifyDestroyAllIndexesWhileDoingPuts$b814fe7d$1(LuceneIndexDestroyDUnitTest.java:197)
> org.apache.geode.cache.RegionDestroyedException: 
> 172.17.0.5(154):32770@org.apache.geode.internal.cache.PartitionedRegionDataStore@983990329
>  name: /AsyncEventQueue_index1#_region_PARALLEL_GATEWAY_SENDER_QUEUE bucket 
> count: 2, caused by org.apache.geode.cache.RegionDestroyedException: 
> Partitioned Region @32c5de26 
> [path='/AsyncEventQueue_index1#_region_PARALLEL_GATEWAY_SENDER_QUEUE'; 
> dataPolicy=PERSISTENT_PARTITION; prId=78; isDestroyed=true; isClosed=false; 
> retryTimeout=360; serialNumber=1340; partition 
> attributes=PartitionAttributes@2128111693[redundantCopies=0;localMaxMemory=1000;totalMaxMemory=2147483647;totalNumBuckets=10;partitionResolver=null;colocatedWith=/region;recoveryDelay=-1;startupRecoveryDelay=0;FixedPartitionAttributes=null;partitionListeners=null];
>  on VM 172.17.0.5(154):32770]
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucket(PartitionedRegionDataStore.java:482)
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucketRecursively(PartitionedRegionDataStore.java:282)
> at 
> org.apache.geode.internal.cache.PartitionedRegion.virtualPut(PartitionedRegion.java:1916)
> ... 7 more
> Caused by:
> org.apache.geode.cache.RegionDestroyedException: Partitioned 
> Region @32c5de26 
> [path='/AsyncEventQueue_index1#_region_PARALLEL_GATEWAY_SENDER_QUEUE'; 
> dataPolicy=PERSISTENT_PARTITION; prId=78; isDestroyed=true; isClosed=false; 
> retryTimeout=360; serialNumber=1340; partition 
> 

[jira] [Created] (GEODE-2774) CI failure: LuceneIndexDestroyDUnitTest.verifyDestroyAllIndexesWhileDoingPuts

[Shelley Lynn Hughes-Godfrey (JIRA)]

Shelley Lynn Hughes-Godfrey created GEODE-2774:
--

 Summary: CI failure: 
LuceneIndexDestroyDUnitTest.verifyDestroyAllIndexesWhileDoingPuts
 Key: GEODE-2774
 URL: https://issues.apache.org/jira/browse/GEODE-2774
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Shelley Lynn Hughes-Godfrey


{noformat}
:geode-lucene:testClassesat 
org.apache.geode.internal.Assert.fail(Assert.java:68)
at 
org.apache.geode.cache.lucene.LuceneIndexDestroyDUnitTest.verifyDestroyAllIndexesWhileDoingPuts(LuceneIndexDestroyDUnitTest.java:215)
org.apache.geode.cache.RegionDestroyedException: Partitioned Region 
@1a3e3379 [path='/region'; dataPolicy=PERSISTENT_PARTITION; prId=76; 
isDestroyed=false; isClosed=false; retryTimeout=360; serialNumber=1315; 
partition 
attributes=PartitionAttributes@1060958737[redundantCopies=0;localMaxMemory=100;totalMaxMemory=2147483647;totalNumBuckets=10;partitionResolver=null;colocatedWith=null;recoveryDelay=-1;startupRecoveryDelay=0;FixedPartitionAttributes=null;partitionListeners=null];
 on VM 172.17.0.5(154):32770], caused by 
org.apache.geode.cache.RegionDestroyedException: 
172.17.0.5(154):32770@org.apache.geode.internal.cache.PartitionedRegionDataStore@983990329
 name: /AsyncEventQueue_index1#_region_PARALLEL_GATEWAY_SENDER_QUEUE bucket 
count: 2, caused by org.apache.geode.cache.RegionDestroyedException: 
Partitioned Region @32c5de26 
[path='/AsyncEventQueue_index1#_region_PARALLEL_GATEWAY_SENDER_QUEUE'; 
dataPolicy=PERSISTENT_PARTITION; prId=78; isDestroyed=true; isClosed=false; 
retryTimeout=360; serialNumber=1340; partition 
attributes=PartitionAttributes@2128111693[redundantCopies=0;localMaxMemory=1000;totalMaxMemory=2147483647;totalNumBuckets=10;partitionResolver=null;colocatedWith=/region;recoveryDelay=-1;startupRecoveryDelay=0;FixedPartitionAttributes=null;partitionListeners=null];
 on VM 172.17.0.5(154):32770]
at 
org.apache.geode.internal.cache.PartitionedRegion.virtualPut(PartitionedRegion.java:1954)
at 
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:151)
at 
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5194)
at 
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1605)
at 
org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1592)
at 
org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:279)
at 
org.apache.geode.cache.lucene.LuceneIndexDestroyDUnitTest.doPutsUntilStopped(LuceneIndexDestroyDUnitTest.java:523)
at 
org.apache.geode.cache.lucene.LuceneIndexDestroyDUnitTest.lambda$verifyDestroyAllIndexesWhileDoingPuts$b814fe7d$1(LuceneIndexDestroyDUnitTest.java:197)
org.apache.geode.cache.RegionDestroyedException: 
172.17.0.5(154):32770@org.apache.geode.internal.cache.PartitionedRegionDataStore@983990329
 name: /AsyncEventQueue_index1#_region_PARALLEL_GATEWAY_SENDER_QUEUE bucket 
count: 2, caused by org.apache.geode.cache.RegionDestroyedException: 
Partitioned Region @32c5de26 
[path='/AsyncEventQueue_index1#_region_PARALLEL_GATEWAY_SENDER_QUEUE'; 
dataPolicy=PERSISTENT_PARTITION; prId=78; isDestroyed=true; isClosed=false; 
retryTimeout=360; serialNumber=1340; partition 
attributes=PartitionAttributes@2128111693[redundantCopies=0;localMaxMemory=1000;totalMaxMemory=2147483647;totalNumBuckets=10;partitionResolver=null;colocatedWith=/region;recoveryDelay=-1;startupRecoveryDelay=0;FixedPartitionAttributes=null;partitionListeners=null];
 on VM 172.17.0.5(154):32770]
at 
org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucket(PartitionedRegionDataStore.java:482)
at 
org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucketRecursively(PartitionedRegionDataStore.java:282)
at 
org.apache.geode.internal.cache.PartitionedRegion.virtualPut(PartitionedRegion.java:1916)
... 7 more
Caused by:
org.apache.geode.cache.RegionDestroyedException: Partitioned 
Region @32c5de26 
[path='/AsyncEventQueue_index1#_region_PARALLEL_GATEWAY_SENDER_QUEUE'; 
dataPolicy=PERSISTENT_PARTITION; prId=78; isDestroyed=true; isClosed=false; 
retryTimeout=360; serialNumber=1340; partition 
attributes=PartitionAttributes@2128111693[redundantCopies=0;localMaxMemory=1000;totalMaxMemory=2147483647;totalNumBuckets=10;partitionResolver=null;colocatedWith=/region;recoveryDelay=-1;startupRecoveryDelay=0;FixedPartitionAttributes=null;partitionListeners=null];
 on VM 172.17.0.5(154):32770]
at 
org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7655)
at 
org.apache.geode.internal.cache.LocalRegion.checkReadiness(LocalRegion.java:2786)
   

[jira] [Commented] (GEODE-2773) AssertionError shown in GIIDeltaDUnitTest.testFullGIITriggeredByHigherRVVGC

[Eric Shu (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965171#comment-15965171
 ] 

Eric Shu commented on GEODE-2773:
-

Because of the async invocation, the following 
assertEquals(regionVersionForThisOp, region_version) call could be executed 
after doOnePut(R, 6, "key1");  This will cause the assertion to fail as the 
current region version is 6 now instead of expected 5.

As the waitForToVerifyRVV() call correctly verifies the region version, there 
is no need for the assertEquals(regionVersionForThisOp, region_version) if it 
was invoked asynchronously. 

{noformat}
AsyncInvocation async2 = doOneDestroyAsync(R, 5, "key5");
waitForToVerifyRVV(R, memberR, 5, null, 0); // P's rvv=r5, gc=0

doOnePut(R, 6, "key1"); // r6 will pass
waitForToVerifyRVV(R, memberR, 6, null, 0); // P's rvv=r6, gc=0
{noformat}

> AssertionError shown in GIIDeltaDUnitTest.testFullGIITriggeredByHigherRVVGC
> ---
>
> Key: GEODE-2773
> URL: https://issues.apache.org/jira/browse/GEODE-2773
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Eric Shu
>
> Though the test is passing, the following Assertion was thrown in one of the 
> VM.invokeAysc call.
> {noformat}
> [vm0] [info 2017/04/11 16:42:03.214 PDT  
> tid=72] Got result: EXCEPTION_OCCURRED
> [vm0] java.lang.AssertionError: expected:<5> but was:<6>
> [vm0] at org.junit.Assert.fail(Assert.java:88)
> [vm0] at org.junit.Assert.failNotEquals(Assert.java:834)
> [vm0] at org.junit.Assert.assertEquals(Assert.java:645)
> [vm0] at org.junit.Assert.assertEquals(Assert.java:631)
> [vm0] at 
> org.apache.geode.internal.cache.GIIDeltaDUnitTest$55.run(GIIDeltaDUnitTest.java:2587)
> [vm0] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [vm0] at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [vm0] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm0] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm0] at hydra.MethExecutor.executeObject(MethExecutor.java:245)
> [vm0] at 
> org.apache.geode.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:73)
> [vm0] at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> [vm0] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm0] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm0] at 
> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:324)
> [vm0] at sun.rmi.transport.Transport$1.run(Transport.java:200)
> [vm0] at sun.rmi.transport.Transport$1.run(Transport.java:197)
> [vm0] at java.security.AccessController.doPrivileged(Native Method)
> [vm0] at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> [vm0] at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> [vm0] at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> [vm0] at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
> [vm0] at java.security.AccessController.doPrivileged(Native Method)
> [vm0] at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
> [vm0] at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [vm0] at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [vm0] at java.lang.Thread.run(Thread.java:745)
> [vm0]  from org.apache.geode.internal.cache.GIIDeltaDUnitTest$55.run with 0 
> args on object: "destroy key5" (took 682 ms)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2694) RECOVERED_FROM_DISK bit is cleared during gii, but should be restored if the recovered entry and gii entry has the same version tag

[Eric Shu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Shu reassigned GEODE-2694:
---

Assignee: Eric Shu

> RECOVERED_FROM_DISK bit is cleared during gii, but should be restored if the 
> recovered entry and gii entry has the same version tag
> ---
>
> Key: GEODE-2694
> URL: https://issues.apache.org/jira/browse/GEODE-2694
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Eric Shu
>Assignee: Eric Shu
>
> Currently for all gii entries, product clears the RECOVERED_FROM_DISK bit for 
> DiskEntry. However, if entry comes from gii has the same version as recovered 
> entry, the RECOVERED_FROM_DISK bit should be restored but does not.
> {noformat}
> synchronized (re) { // fixes bug 41409
>   if (dr.testIsRecoveredAndClear(re)) {
> wasRecovered = true;
> if (tmpValue == null) {
>   tmpValue = entry.isLocalInvalid() ? Token.LOCAL_INVALID : 
> Token.INVALID;
> }
> // Compare the version stamps, and if they are equal
> // we can skip adding the entry we receive as part of GII.
> VersionStamp stamp = re.getVersionStamp();
> boolean entriesEqual = stamp != null && 
> stamp.asVersionTag().equals(tag);
> // If the received entry and what we have in the cache
> // actually are equal, keep don't put the received
> // entry into the cache (this avoids writing a record to disk)
> if (entriesEqual) {
>   continue;
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2097) Offheap persistent heapLRU regions can run out of offheap memory during recovery

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965160#comment-15965160
 ] 

ASF subversion and git services commented on GEODE-2097:


Commit 6f956e2e4e482f4ebecb65e605fd7e01321ffaa4 in geode's branch 
refs/heads/feature/GEODE-2097 from [~dschneider]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=6f956e2 ]

Merge remote-tracking branch 'origin/develop' into feature/GEODE-2097


> Offheap persistent heapLRU regions can run out of offheap memory during 
> recovery
> 
>
> Key: GEODE-2097
> URL: https://issues.apache.org/jira/browse/GEODE-2097
> Project: Geode
>  Issue Type: Bug
>  Components: offheap
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> When the data for a persistent region is being recovered from the disk store 
> the lru limit is constantly checked. If the lru limit is exceeded then value 
> recovery will cease. But for off-heap regions this lru limit should be 
> checking how much off-heap memory has been allocated.
> During recovery the amount of heap memory is being checked for an offheap 
> regions. So we can end up recovering too many values to off-heap and running 
> out of off-heap memory during recovery.
> The code that causes this problem is: 
> org.apache.geode.internal.cache.lru.HeapLRUCapacityController.createLRUHelper().new
>  AbstractEnableLRU() {...}.mustEvict(LRUStatistics, Region, int)
> During off-heap disk store recovery the Region parameter passed to this 
> method is "null". This causes the following heap check to be done:
>if (region == null) {
>   return resourceManager.getHeapMonitor().getState().isEviction();
> }



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2097) Offheap persistent heapLRU regions can run out of offheap memory during recovery

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965161#comment-15965161
 ] 

ASF subversion and git services commented on GEODE-2097:


Commit bf20e0aa26c83295651db2b872b16a0363e30549 in geode's branch 
refs/heads/feature/GEODE-2097 from [~dschneider]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=bf20e0a ]

Merge remote-tracking branch 'origin/develop' into feature/GEODE-2097


> Offheap persistent heapLRU regions can run out of offheap memory during 
> recovery
> 
>
> Key: GEODE-2097
> URL: https://issues.apache.org/jira/browse/GEODE-2097
> Project: Geode
>  Issue Type: Bug
>  Components: offheap
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> When the data for a persistent region is being recovered from the disk store 
> the lru limit is constantly checked. If the lru limit is exceeded then value 
> recovery will cease. But for off-heap regions this lru limit should be 
> checking how much off-heap memory has been allocated.
> During recovery the amount of heap memory is being checked for an offheap 
> regions. So we can end up recovering too many values to off-heap and running 
> out of off-heap memory during recovery.
> The code that causes this problem is: 
> org.apache.geode.internal.cache.lru.HeapLRUCapacityController.createLRUHelper().new
>  AbstractEnableLRU() {...}.mustEvict(LRUStatistics, Region, int)
> During off-heap disk store recovery the Region parameter passed to this 
> method is "null". This causes the following heap check to be done:
>if (region == null) {
>   return resourceManager.getHeapMonitor().getState().isEviction();
> }



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2097) Offheap persistent heapLRU regions can run out of offheap memory during recovery

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965162#comment-15965162
 ] 

ASF subversion and git services commented on GEODE-2097:


Commit 4d069fbc5e9830c644eb006dd5a77020e25b8d85 in geode's branch 
refs/heads/feature/GEODE-2097 from [~dschneider]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=4d069fb ]

Merge remote-tracking branch 'origin/develop' into feature/GEODE-2097


> Offheap persistent heapLRU regions can run out of offheap memory during 
> recovery
> 
>
> Key: GEODE-2097
> URL: https://issues.apache.org/jira/browse/GEODE-2097
> Project: Geode
>  Issue Type: Bug
>  Components: offheap
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> When the data for a persistent region is being recovered from the disk store 
> the lru limit is constantly checked. If the lru limit is exceeded then value 
> recovery will cease. But for off-heap regions this lru limit should be 
> checking how much off-heap memory has been allocated.
> During recovery the amount of heap memory is being checked for an offheap 
> regions. So we can end up recovering too many values to off-heap and running 
> out of off-heap memory during recovery.
> The code that causes this problem is: 
> org.apache.geode.internal.cache.lru.HeapLRUCapacityController.createLRUHelper().new
>  AbstractEnableLRU() {...}.mustEvict(LRUStatistics, Region, int)
> During off-heap disk store recovery the Region parameter passed to this 
> method is "null". This causes the following heap check to be done:
>if (region == null) {
>   return resourceManager.getHeapMonitor().getState().isEviction();
> }



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2097) Offheap persistent heapLRU regions can run out of offheap memory during recovery

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965163#comment-15965163
 ] 

ASF subversion and git services commented on GEODE-2097:


Commit 98c56f6e0e6be30fb9e344f9cd846eb03bcdd640 in geode's branch 
refs/heads/feature/GEODE-2097 from [~dschneider]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=98c56f6 ]

Merge remote-tracking branch 'origin/develop' into feature/GEODE-2097


> Offheap persistent heapLRU regions can run out of offheap memory during 
> recovery
> 
>
> Key: GEODE-2097
> URL: https://issues.apache.org/jira/browse/GEODE-2097
> Project: Geode
>  Issue Type: Bug
>  Components: offheap
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> When the data for a persistent region is being recovered from the disk store 
> the lru limit is constantly checked. If the lru limit is exceeded then value 
> recovery will cease. But for off-heap regions this lru limit should be 
> checking how much off-heap memory has been allocated.
> During recovery the amount of heap memory is being checked for an offheap 
> regions. So we can end up recovering too many values to off-heap and running 
> out of off-heap memory during recovery.
> The code that causes this problem is: 
> org.apache.geode.internal.cache.lru.HeapLRUCapacityController.createLRUHelper().new
>  AbstractEnableLRU() {...}.mustEvict(LRUStatistics, Region, int)
> During off-heap disk store recovery the Region parameter passed to this 
> method is "null". This causes the following heap check to be done:
>if (region == null) {
>   return resourceManager.getHeapMonitor().getState().isEviction();
> }



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2485) CacheTransactionManager suspend/resume can leak memory for 30 minutes

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider resolved GEODE-2485.
-
Resolution: Fixed

> CacheTransactionManager suspend/resume can leak memory for 30 minutes
> -
>
> Key: GEODE-2485
> URL: https://issues.apache.org/jira/browse/GEODE-2485
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> Each time you suspend/resume a transaction it leaves about 80 bytes of heap 
> allocated for 30 minutes. If you are doing a high rate of suspend/resume 
> calls then this could cause you to run out of memory in that 30 minute window.
> As a workaround you can set -Dgemfire.suspendedTxTimeout to a value as small 
> as 1 (which would cause the memory to be freed up after 1 minute instead of 
> 30 minutes).
> One fix for this is to periodically call cache.getCCPTimer().timerPurge() 
> after a certain number of resume calls have been done (for example 1000). 
> Currently resume is calling cancel on the TimerTask but that leaves the task 
> in the SystemTimer queue until it expires. Calling timerPurge it addition to 
> cancel will fix this bug. Calling timerPurge for every cancel may cause the 
> resume method to take too long and keep in mind the getCCPTimer is used by 
> other things so the size of the SystemTimer queue that is being purged will 
> not only be the number of suspended txs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2485) CacheTransactionManager suspend/resume can leak memory for 30 minutes

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965156#comment-15965156
 ] 

ASF subversion and git services commented on GEODE-2485:


Commit 2bf910a31beb624ab1033a5ed7890f5d4b0ff865 in geode's branch 
refs/heads/develop from [~dschneider]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=2bf910a ]

GEODE-2485: fix leak in tx suspend/resume

test now closes the cache it creates


> CacheTransactionManager suspend/resume can leak memory for 30 minutes
> -
>
> Key: GEODE-2485
> URL: https://issues.apache.org/jira/browse/GEODE-2485
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> Each time you suspend/resume a transaction it leaves about 80 bytes of heap 
> allocated for 30 minutes. If you are doing a high rate of suspend/resume 
> calls then this could cause you to run out of memory in that 30 minute window.
> As a workaround you can set -Dgemfire.suspendedTxTimeout to a value as small 
> as 1 (which would cause the memory to be freed up after 1 minute instead of 
> 30 minutes).
> One fix for this is to periodically call cache.getCCPTimer().timerPurge() 
> after a certain number of resume calls have been done (for example 1000). 
> Currently resume is calling cancel on the TimerTask but that leaves the task 
> in the SystemTimer queue until it expires. Calling timerPurge it addition to 
> cancel will fix this bug. Calling timerPurge for every cancel may cause the 
> resume method to take too long and keep in mind the getCCPTimer is used by 
> other things so the size of the SystemTimer queue that is being purged will 
> not only be the number of suspended txs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2773) AssertionError shown in GIIDeltaDUnitTest.testFullGIITriggeredByHigherRVVGC

[Eric Shu (JIRA)]

Eric Shu created GEODE-2773:
---

 Summary: AssertionError shown in 
GIIDeltaDUnitTest.testFullGIITriggeredByHigherRVVGC
 Key: GEODE-2773
 URL: https://issues.apache.org/jira/browse/GEODE-2773
 Project: Geode
  Issue Type: Bug
  Components: persistence
Reporter: Eric Shu


Though the test is passing, the following Assertion was thrown in one of the 
VM.invokeAysc call.

{noformat}
[vm0] [info 2017/04/11 16:42:03.214 PDT  
tid=72] Got result: EXCEPTION_OCCURRED
[vm0] java.lang.AssertionError: expected:<5> but was:<6>
[vm0]   at org.junit.Assert.fail(Assert.java:88)
[vm0]   at org.junit.Assert.failNotEquals(Assert.java:834)
[vm0]   at org.junit.Assert.assertEquals(Assert.java:645)
[vm0]   at org.junit.Assert.assertEquals(Assert.java:631)
[vm0]   at 
org.apache.geode.internal.cache.GIIDeltaDUnitTest$55.run(GIIDeltaDUnitTest.java:2587)
[vm0]   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[vm0]   at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[vm0]   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[vm0]   at java.lang.reflect.Method.invoke(Method.java:498)
[vm0]   at hydra.MethExecutor.executeObject(MethExecutor.java:245)
[vm0]   at 
org.apache.geode.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:73)
[vm0]   at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
[vm0]   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[vm0]   at java.lang.reflect.Method.invoke(Method.java:498)
[vm0]   at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:324)
[vm0]   at sun.rmi.transport.Transport$1.run(Transport.java:200)
[vm0]   at sun.rmi.transport.Transport$1.run(Transport.java:197)
[vm0]   at java.security.AccessController.doPrivileged(Native Method)
[vm0]   at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
[vm0]   at 
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
[vm0]   at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
[vm0]   at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
[vm0]   at java.security.AccessController.doPrivileged(Native Method)
[vm0]   at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
[vm0]   at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[vm0]   at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[vm0]   at java.lang.Thread.run(Thread.java:745)
[vm0]  from org.apache.geode.internal.cache.GIIDeltaDUnitTest$55.run with 0 
args on object: "destroy key5" (took 682 ms)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: One class loader vs multiple class loaders for deployed jars

[Jinmei Liao]

I believe with the current fix, we at least do not have the "eager loading"
problem anymore. The classloader isolation was a problem before and would
remain as a problem after this for further larger scale changes. +1 for
merging the fix.

On Tue, Apr 11, 2017 at 4:04 PM, Swapnil Bawaskar 
wrote:

> +1 for merging Jared's fix. it gets us closer to fixing classloading in a
> later release.
>
> On Tue, Apr 11, 2017 at 1:41 PM Jacob Barrett  wrote:
>
> > I can support the idea of taking the small step of fixing the eager class
> > loading if it doesn't:
> > 1) break the current expected behavior.
> > 2) dig is deeper into a hole with class loading isolation in the future.
> >
> > If it breaks the current expected behavior, that in itself is ok until
> you
> > consider that adding class loader isolation later will most definitely
> > break the expected behavior, can we afford do break it twice?
> >
> > -Jake
> >
> > On Tue, Apr 11, 2017 at 10:06 AM Jared Stewart 
> > wrote:
> >
> > > I would like to distinguish between the following two objectives:
> > >  1) Do not eagerly load every class contained in a deployed jar
> > >  2) Establish robust classloader isolation for deployed jars
> > >
> > > The aim of my current line of work is to fix 1) (GEODE-2290).  This is
> > not
> > > to say that 2) is not a valuable pursuit, but I think getting 2) done
> > > correctly is a larger task than fixing 1) in isolation.
> > >
> > > To get into the specifics of the libraries you mentioned,
> > >
> > > JCL:
> > >  - JCL has no support for removing/undeploying jars.  In this respect,
> I
> > > don't see anything that JCL would add over simply using a
> URLClassLoader.
> > > We would have to rebuild the JCL class loader in exactly the same set
> of
> > > circumstances that we would need to rebuild a URLClassLoader.
> > >  - I have seen a fair number of warnings from people that JCL is buggy
> > and
> > > incomplete, e.g. (
> > >
> > http://stackoverflow.com/questions/60764/how-should-i-
> load-jars-dynamically-at-runtime#comment43066872_1450837
> > )
> > > This would seem to be supported by a quick look at the github issues
> page
> > > for JCL, which includes things like a bug report of a deadlock from Jun
> > > 2016 to which the developers have never responded.
> > >
> > > JBoss Modules:
> > >  - JBoss Modules (or Java 9/Jigsaw Modules) seem like a good strategic
> > > direction towards which to strive.  Yet the fact that they require an
> > > external module descriptor (XML) would again seem to make this a much
> > > larger task than 1) alone.  (If the idea here is to have a user provide
> > us
> > > with a JBoss Module rather than a plain jar file, this would be a large
> > > breaking change for existing users.  On the other hand, if the idea is
> > for
> > > us to autogenerate the necessary metainformation to transform the
> user's
> > > jar file into a JBoss Module, this would seem to be a large task which
> is
> > > again independent from the goals of 1).
> > >
> > > - Jared
> > >
> > > > On Apr 10, 2017, at 9:41 PM, Jacob Barrett 
> > wrote:
> > > >
> > > > There are certainly many projects in the OS community that have
> solved
> > > this
> > > > same problem. Perhaps we can find a class loader from a project that
> > > would
> > > > suite this need.
> > > >
> > > > Quick search of standalone frameworks comes up with a few popular
> hits:
> > > > https://github.com/kamranzafar/JCL
> > > > https://github.com/jboss-modules/jboss-modules
> > > >
> > > > -Jake
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Apr 10, 2017 at 1:40 PM Kirk Lund  wrote:
> > > >
> > > >> I think Jared started down this path because we had a custom
> > classloader
> > > >> implementation that he was trying to get rid of -- that impl was
> > pretty
> > > >> limited and forced loading of all classes up-front.
> > > >>
> > > >> Now the code uses fast classpath scanner and that old custom
> > classloader
> > > >> can't be used. The old classloader is so simplistic and limited that
> > > trying
> > > >> to modify it looks like more work than writing a new one from
> scratch.
> > > >> Implementing a new custom classloader or switching our codebase to
> > use a
> > > >> new classloader container (using an existing solution) are both
> > possible
> > > >> directions. Until that's completed the "deploy jar" command will
> > > continue
> > > >> to force ALL classes to be loaded up-front.
> > > >>
> > > >> One major concern is that implementing a new custom classloader is
> > > >> non-trivial and could also introduce some new classloader bugs -- of
> > > >> particular interest to "deploy jar" is the fact that Java remembers
> > TWO
> > > >> classloaders for each class [1] -- the CL that *loaded* the class
> AND
> > > the
> > > >> CL that *initiated* the request to load the class -- dropping the
> > > >> *initiating* CL at runtime can result in failures 

[jira] [Commented] (GEODE-2694) RECOVERED_FROM_DISK bit is cleared during gii, but should be restored if the recovered entry and gii entry has the same version tag

[Eric Shu (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965147#comment-15965147
 ] 

Eric Shu commented on GEODE-2694:
-

There are two places that entry will be destroyed when recovered_from_disk bit 
is set to true.

After processing a full gii, all entries with the recovered_from_disk bit set 
to true will be destroyed, possibly try to remove the unfinished operations.
  final void finishInitializeOwner(LocalRegion drs, GIIStatus giiStatus) {
if (isReadyForRecovery()) {
  // this.scheduleCompaction();
  if (GIIStatus.didFullGII(giiStatus)) {
-->destroyRemainingRecoveredEntries(drs);
  } else if (GIIStatus.didDeltaGII(giiStatus)) {
// TODO: not sure if we should destroy old tombstones for deltaGII
  } else if (getRegionVersionVector() != null) {
destroyOldTomstones(drs);
  }
  releaseRecoveryData();
}

and here in InitialImageOperation.getFromOne
  // review unfinished keys and remove untouched entries
  if (this.region.getDataPolicy().withPersistence() && 
keysOfUnfinishedOps != null
  && !keysOfUnfinishedOps.isEmpty()) {
final DiskRegion dr = this.region.getDiskRegion();
assert dr != null;
for (Object key : keysOfUnfinishedOps) {
  RegionEntry re = this.entries.getEntry(key);
  if (re == null) {
continue;
  }
  if (logger.isTraceEnabled(LogMarker.GII)) {
logger.trace(LogMarker.GII, "Processing unfinished 
operation:entry={}", re);
  }
  DiskEntry de = (DiskEntry) re;
  synchronized (de) {
DiskId id = de.getDiskId();
if (id != null && 
EntryBits.isRecoveredFromDisk(id.getUserBits())) {
  this.region.destroyRecoveredEntry(key);
  if (isDebugEnabled) {
logger.debug("Deleted unfinished keys:key={}", key);
  }
}
  }

The bit set in dr.testIsRecoveredAndClear is clearly needed during finishing 
gii.

During full gii, we could rewrite the entry to disk -- the optimization in the 
following could be thought as the entry was rewritten to disk as they have the 
same version tag.

// If the received entry and what we have in the cache
// actually are equal, keep don't put the received
// entry into the cache (this avoids writing a record to disk)
if (entriesEqual) {
  continue;
}

Will add unit tests to verify the RECOVERED_FROM_DISK bit after GII.

> RECOVERED_FROM_DISK bit is cleared during gii, but should be restored if the 
> recovered entry and gii entry has the same version tag
> ---
>
> Key: GEODE-2694
> URL: https://issues.apache.org/jira/browse/GEODE-2694
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Eric Shu
>
> Currently for all gii entries, product clears the RECOVERED_FROM_DISK bit for 
> DiskEntry. However, if entry comes from gii has the same version as recovered 
> entry, the RECOVERED_FROM_DISK bit should be restored but does not.
> {noformat}
> synchronized (re) { // fixes bug 41409
>   if (dr.testIsRecoveredAndClear(re)) {
> wasRecovered = true;
> if (tmpValue == null) {
>   tmpValue = entry.isLocalInvalid() ? Token.LOCAL_INVALID : 
> Token.INVALID;
> }
> // Compare the version stamps, and if they are equal
> // we can skip adding the entry we receive as part of GII.
> VersionStamp stamp = re.getVersionStamp();
> boolean entriesEqual = stamp != null && 
> stamp.asVersionTag().equals(tag);
> // If the received entry and what we have in the cache
> // actually are equal, keep don't put the received
> // entry into the cache (this avoids writing a record to disk)
> if (entriesEqual) {
>   continue;
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2632) Integrated Security performance improvements

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965145#comment-15965145
 ] 

ASF GitHub Bot commented on GEODE-2632:
---

Github user kirklund commented on the issue:

https://github.com/apache/geode/pull/450
  
Example results from running the benchmark (I think we'll want to reduce 
the time or # of iterations -- this is probably going to require some 
experimentation and comparing benchmarks as we write more):

Result "performPutFromClient":
  21097.236 ±(99.9%) 1817.639 ops/s [Average]
  (min, avg, max) = (19178.006, 21097.236, 22161.856), stdev = 1081.648
  CI (99.9%): [19279.596, 22914.875] (assumes normal distribution)


# Run complete. Total time: 00:42:30

Benchmark  Mode  Cnt  Score  Error  
Units
ClientCachePutBench.performPutFromClient  thrpt9  21097.236 ± 1817.639  
ops/s

Benchmark result is saved to build/reports/jmh/results.txt

BUILD SUCCESSFUL

Total time: 43 mins 8.11 secs



> Integrated Security performance improvements
> 
>
> Key: GEODE-2632
> URL: https://issues.apache.org/jira/browse/GEODE-2632
> Project: Geode
>  Issue Type: Improvement
>  Components: security
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: performance
>
> There is a security check in Put65.cmdExecute() that, if removed, improved 
> the performance.
> The expense of this security call needs to be reduced in order to get the 
> performance back.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #450: GEODE-2632: create ClientCachePutBench

[kirklund]

Github user kirklund commented on the issue:

https://github.com/apache/geode/pull/450
  
Example results from running the benchmark (I think we'll want to reduce 
the time or # of iterations -- this is probably going to require some 
experimentation and comparing benchmarks as we write more):

Result "performPutFromClient":
  21097.236 ±(99.9%) 1817.639 ops/s [Average]
  (min, avg, max) = (19178.006, 21097.236, 22161.856), stdev = 1081.648
  CI (99.9%): [19279.596, 22914.875] (assumes normal distribution)


# Run complete. Total time: 00:42:30

Benchmark  Mode  Cnt  Score  Error  
Units
ClientCachePutBench.performPutFromClient  thrpt9  21097.236 ± 1817.639 
 ops/s

Benchmark result is saved to build/reports/jmh/results.txt

BUILD SUCCESSFUL

Total time: 43 mins 8.11 secs



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Review Request 58372: GEODE-2694: recovered from disk user bit after gii

[Eric Shu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58372/
---

Review request for geode, anilkumar gingade, Darrel Schneider, and Lynn 
Gallinat.


Bugs: GEODE-2694
https://issues.apache.org/jira/browse/GEODE-2694


Repository: geode


Description
---

It seems that the current implementation of clearing recovered from disk bit is 
correct. The bit will be used to removed the entry with unfinished op when 
finishing the gii.


Diffs
-

  
geode-core/src/test/java/org/apache/geode/internal/cache/GIIDeltaDUnitTest.java 
950eb43 


Diff: https://reviews.apache.org/r/58372/diff/1/


Testing
---

precheckin.


Thanks,

Eric Shu

[jira] [Commented] (GEODE-2632) Integrated Security performance improvements

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965126#comment-15965126
 ] 

ASF GitHub Bot commented on GEODE-2632:
---

Github user kirklund commented on the issue:

https://github.com/apache/geode/pull/450
  
Additional reviewers beyond those I tagged are also welcome! Thanks.


> Integrated Security performance improvements
> 
>
> Key: GEODE-2632
> URL: https://issues.apache.org/jira/browse/GEODE-2632
> Project: Geode
>  Issue Type: Improvement
>  Components: security
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: performance
>
> There is a security check in Put65.cmdExecute() that, if removed, improved 
> the performance.
> The expense of this security call needs to be reduced in order to get the 
> performance back.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #450: GEODE-2632: create ClientCachePutBench

[kirklund]

Github user kirklund commented on the issue:

https://github.com/apache/geode/pull/450
  
Additional reviewers beyond those I tagged are also welcome! Thanks.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2764) Index entry not entered into cluster config xml if region name contains a function call like entrySet()

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965125#comment-15965125
 ] 

ASF GitHub Bot commented on GEODE-2764:
---

Github user nabarunnag commented on a diff in the pull request:

https://github.com/apache/geode/pull/449#discussion_r111037135
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/CreateIndexFunction.java
 ---
@@ -93,6 +91,31 @@ public void execute(FunctionContext context) {
 }
   }
 
+  private void setResultInSender(FunctionContext context, IndexInfo 
indexInfo, String memberId,
+  Cache cache, String regionPath) {
+if (regionPath == null) {
+  String message = 
CliStrings.format(CliStrings.CREATE_INDEX__INVALID__REGIONPATH,
+  indexInfo.getRegionPath());
+  context.getResultSender().lastResult(new CliFunctionResult(memberId, 
false, message));
+} else {
+  XmlEntity xmlEntity =
+  new XmlEntity(CacheXml.REGION, "name", 
cache.getRegion(regionPath).getName());
+  context.getResultSender().lastResult(new CliFunctionResult(memberId, 
xmlEntity));
+}
+  }
+
+  private String getValidRegionName(Cache cache, String regionPath) {
+while (cache.getRegion(regionPath) == null && regionPath != null) {
--- End diff --

Its fixed now.
thank you !!


> Index entry not entered into cluster config xml if region name contains a 
> function call like entrySet()
> ---
>
> Key: GEODE-2764
> URL: https://issues.apache.org/jira/browse/GEODE-2764
> Project: Geode
>  Issue Type: Bug
>Reporter: nabarun
>
> Steps to recreate the issue type the following in a gfsh instance:
> 1. start locator --name=locator
> 2. start server --name=server
> 3. create region --name=regionName --type=REPLICATE_PERSISTENT 
> 4. create index --name=regionIndex --region="regionName.entrySet() r" 
> --expression=r.key
> -- this will result in an error message 
> {noformat}
> Failed to create index "regionIndex" due to following reasons
> null
> {noformat}
> Cause:
> The index is created but while putting the entry into the clusterconfig it 
> tries to put the region name as regionName.entrySet() which does not exist. 
> cache.getRegion(regionName.entrySet()) will result in null and no xml entry 
> is added to the clusterconfig. So when the server is restarted, there is no 
> index entry in the cluster config xml hence the index is not re-created.
> Solution:
> If the region name contains the character '(' and ')' spilt the region name 
> at the index of '.' and check if the region exists. 
> If the check returns successful only then enter the entry into the cluster 
> config.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #449: GEODE-2764: Added checks on the region name

[nabarunnag]

Github user nabarunnag commented on a diff in the pull request:

https://github.com/apache/geode/pull/449#discussion_r111037135
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/CreateIndexFunction.java
 ---
@@ -93,6 +91,31 @@ public void execute(FunctionContext context) {
 }
   }
 
+  private void setResultInSender(FunctionContext context, IndexInfo 
indexInfo, String memberId,
+  Cache cache, String regionPath) {
+if (regionPath == null) {
+  String message = 
CliStrings.format(CliStrings.CREATE_INDEX__INVALID__REGIONPATH,
+  indexInfo.getRegionPath());
+  context.getResultSender().lastResult(new CliFunctionResult(memberId, 
false, message));
+} else {
+  XmlEntity xmlEntity =
+  new XmlEntity(CacheXml.REGION, "name", 
cache.getRegion(regionPath).getName());
+  context.getResultSender().lastResult(new CliFunctionResult(memberId, 
xmlEntity));
+}
+  }
+
+  private String getValidRegionName(Cache cache, String regionPath) {
+while (cache.getRegion(regionPath) == null && regionPath != null) {
--- End diff --

Its fixed now.
thank you !!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2632) Integrated Security performance improvements

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965123#comment-15965123
 ] 

ASF GitHub Bot commented on GEODE-2632:
---

GitHub user kirklund opened a pull request:

https://github.com/apache/geode/pull/450

GEODE-2632: create ClientCachePutBench

* add jmh to geode-core
* prevent dunit launching due to static Rule
* define ClientCachePutBench to measure throughput of puts from a cache 
client to a loner server

Notes: this is a macro benchmark which uses a Client (in the JMH JVM) and a 
Server JVM. The intention of this benchmark is to verify that the later changes 
I make for GEODE-2632 (including refactoring of classes in 
org.apache.geode.internal.cache.tier.sockets) do not adversely affect 
performance. Following this commit will be changes to the constructors of some 
cache client classes and introduction a micro benchmark that directly measures 
Put65 for improving performance involving its interaction with SecurityService.

I added jmh to geode-core because I want to introduce creation of micro 
benchmarks in the same module and same package(s) as the class(es) being 
measured.

The change to LocatorServerStartupRule.java was necessary because locators 
and servers scan the org.apache.geode.management.internal.cli.commands package 
for Spring Shell commands at start-up which forces static initialization of 
every class in that package. There is at least one dunit test in that same 
package with a static instance of LocatorServerStartupRule. Because jmh creates 
its own jar and puts all of the geode-core classes, including tests, in that 
jar, the constructor of LocatorServerStartupRule will currently cause dunit to 
launch. Jared is working on an additional change to prevent test classes from 
being class loaded as potential command classes.

I'd like to have this PR reviewed by @bschuchardt @galen-pivotal 
@kohlmu-pivotal @hiteshk25 @metatype.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/kirklund/geode 
feature/GEODE-2632-ClientCachePutBench

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/450.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #450


commit c80daa9aef14503ba10ebacb730e2cd334947c31
Author: Kirk Lund 
Date:   2017-04-11T22:58:26Z

GEODE-2632: create ClientCachePutBench

* add jmh to geode-core
* prevent dunit launching due to static Rule




> Integrated Security performance improvements
> 
>
> Key: GEODE-2632
> URL: https://issues.apache.org/jira/browse/GEODE-2632
> Project: Geode
>  Issue Type: Improvement
>  Components: security
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: performance
>
> There is a security check in Put65.cmdExecute() that, if removed, improved 
> the performance.
> The expense of this security call needs to be reduced in order to get the 
> performance back.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #450: GEODE-2632: create ClientCachePutBench

[kirklund]

GitHub user kirklund opened a pull request:

https://github.com/apache/geode/pull/450

GEODE-2632: create ClientCachePutBench

* add jmh to geode-core
* prevent dunit launching due to static Rule
* define ClientCachePutBench to measure throughput of puts from a cache 
client to a loner server

Notes: this is a macro benchmark which uses a Client (in the JMH JVM) and a 
Server JVM. The intention of this benchmark is to verify that the later changes 
I make for GEODE-2632 (including refactoring of classes in 
org.apache.geode.internal.cache.tier.sockets) do not adversely affect 
performance. Following this commit will be changes to the constructors of some 
cache client classes and introduction a micro benchmark that directly measures 
Put65 for improving performance involving its interaction with SecurityService.

I added jmh to geode-core because I want to introduce creation of micro 
benchmarks in the same module and same package(s) as the class(es) being 
measured.

The change to LocatorServerStartupRule.java was necessary because locators 
and servers scan the org.apache.geode.management.internal.cli.commands package 
for Spring Shell commands at start-up which forces static initialization of 
every class in that package. There is at least one dunit test in that same 
package with a static instance of LocatorServerStartupRule. Because jmh creates 
its own jar and puts all of the geode-core classes, including tests, in that 
jar, the constructor of LocatorServerStartupRule will currently cause dunit to 
launch. Jared is working on an additional change to prevent test classes from 
being class loaded as potential command classes.

I'd like to have this PR reviewed by @bschuchardt @galen-pivotal 
@kohlmu-pivotal @hiteshk25 @metatype.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/kirklund/geode 
feature/GEODE-2632-ClientCachePutBench

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/450.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #450


commit c80daa9aef14503ba10ebacb730e2cd334947c31
Author: Kirk Lund 
Date:   2017-04-11T22:58:26Z

GEODE-2632: create ClientCachePutBench

* add jmh to geode-core
* prevent dunit launching due to static Rule




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2764) Index entry not entered into cluster config xml if region name contains a function call like entrySet()

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965117#comment-15965117
 ] 

ASF GitHub Bot commented on GEODE-2764:
---

Github user jhuynh1 commented on a diff in the pull request:

https://github.com/apache/geode/pull/449#discussion_r111036455
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/CreateIndexFunction.java
 ---
@@ -93,6 +91,31 @@ public void execute(FunctionContext context) {
 }
   }
 
+  private void setResultInSender(FunctionContext context, IndexInfo 
indexInfo, String memberId,
+  Cache cache, String regionPath) {
+if (regionPath == null) {
+  String message = 
CliStrings.format(CliStrings.CREATE_INDEX__INVALID__REGIONPATH,
+  indexInfo.getRegionPath());
+  context.getResultSender().lastResult(new CliFunctionResult(memberId, 
false, message));
+} else {
+  XmlEntity xmlEntity =
+  new XmlEntity(CacheXml.REGION, "name", 
cache.getRegion(regionPath).getName());
+  context.getResultSender().lastResult(new CliFunctionResult(memberId, 
xmlEntity));
+}
+  }
+
+  private String getValidRegionName(Cache cache, String regionPath) {
+while (cache.getRegion(regionPath) == null && regionPath != null) {
--- End diff --

If regionPath is null, will cache.getRegion(regionPath) throw an exception? 
 Shouldn't the regionPath check for null be first?


> Index entry not entered into cluster config xml if region name contains a 
> function call like entrySet()
> ---
>
> Key: GEODE-2764
> URL: https://issues.apache.org/jira/browse/GEODE-2764
> Project: Geode
>  Issue Type: Bug
>Reporter: nabarun
>
> Steps to recreate the issue type the following in a gfsh instance:
> 1. start locator --name=locator
> 2. start server --name=server
> 3. create region --name=regionName --type=REPLICATE_PERSISTENT 
> 4. create index --name=regionIndex --region="regionName.entrySet() r" 
> --expression=r.key
> -- this will result in an error message 
> {noformat}
> Failed to create index "regionIndex" due to following reasons
> null
> {noformat}
> Cause:
> The index is created but while putting the entry into the clusterconfig it 
> tries to put the region name as regionName.entrySet() which does not exist. 
> cache.getRegion(regionName.entrySet()) will result in null and no xml entry 
> is added to the clusterconfig. So when the server is restarted, there is no 
> index entry in the cluster config xml hence the index is not re-created.
> Solution:
> If the region name contains the character '(' and ')' spilt the region name 
> at the index of '.' and check if the region exists. 
> If the check returns successful only then enter the entry into the cluster 
> config.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #449: GEODE-2764: Added checks on the region name

[jhuynh1]

Github user jhuynh1 commented on a diff in the pull request:

https://github.com/apache/geode/pull/449#discussion_r111036455
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/CreateIndexFunction.java
 ---
@@ -93,6 +91,31 @@ public void execute(FunctionContext context) {
 }
   }
 
+  private void setResultInSender(FunctionContext context, IndexInfo 
indexInfo, String memberId,
+  Cache cache, String regionPath) {
+if (regionPath == null) {
+  String message = 
CliStrings.format(CliStrings.CREATE_INDEX__INVALID__REGIONPATH,
+  indexInfo.getRegionPath());
+  context.getResultSender().lastResult(new CliFunctionResult(memberId, 
false, message));
+} else {
+  XmlEntity xmlEntity =
+  new XmlEntity(CacheXml.REGION, "name", 
cache.getRegion(regionPath).getName());
+  context.getResultSender().lastResult(new CliFunctionResult(memberId, 
xmlEntity));
+}
+  }
+
+  private String getValidRegionName(Cache cache, String regionPath) {
+while (cache.getRegion(regionPath) == null && regionPath != null) {
--- End diff --

If regionPath is null, will cache.getRegion(regionPath) throw an exception? 
 Shouldn't the regionPath check for null be first?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: One class loader vs multiple class loaders for deployed jars

[Swapnil Bawaskar]

+1 for merging Jared's fix. it gets us closer to fixing classloading in a
later release.

On Tue, Apr 11, 2017 at 1:41 PM Jacob Barrett  wrote:

> I can support the idea of taking the small step of fixing the eager class
> loading if it doesn't:
> 1) break the current expected behavior.
> 2) dig is deeper into a hole with class loading isolation in the future.
>
> If it breaks the current expected behavior, that in itself is ok until you
> consider that adding class loader isolation later will most definitely
> break the expected behavior, can we afford do break it twice?
>
> -Jake
>
> On Tue, Apr 11, 2017 at 10:06 AM Jared Stewart 
> wrote:
>
> > I would like to distinguish between the following two objectives:
> >  1) Do not eagerly load every class contained in a deployed jar
> >  2) Establish robust classloader isolation for deployed jars
> >
> > The aim of my current line of work is to fix 1) (GEODE-2290).  This is
> not
> > to say that 2) is not a valuable pursuit, but I think getting 2) done
> > correctly is a larger task than fixing 1) in isolation.
> >
> > To get into the specifics of the libraries you mentioned,
> >
> > JCL:
> >  - JCL has no support for removing/undeploying jars.  In this respect, I
> > don't see anything that JCL would add over simply using a URLClassLoader.
> > We would have to rebuild the JCL class loader in exactly the same set of
> > circumstances that we would need to rebuild a URLClassLoader.
> >  - I have seen a fair number of warnings from people that JCL is buggy
> and
> > incomplete, e.g. (
> >
> http://stackoverflow.com/questions/60764/how-should-i-load-jars-dynamically-at-runtime#comment43066872_1450837
> )
> > This would seem to be supported by a quick look at the github issues page
> > for JCL, which includes things like a bug report of a deadlock from Jun
> > 2016 to which the developers have never responded.
> >
> > JBoss Modules:
> >  - JBoss Modules (or Java 9/Jigsaw Modules) seem like a good strategic
> > direction towards which to strive.  Yet the fact that they require an
> > external module descriptor (XML) would again seem to make this a much
> > larger task than 1) alone.  (If the idea here is to have a user provide
> us
> > with a JBoss Module rather than a plain jar file, this would be a large
> > breaking change for existing users.  On the other hand, if the idea is
> for
> > us to autogenerate the necessary metainformation to transform the user's
> > jar file into a JBoss Module, this would seem to be a large task which is
> > again independent from the goals of 1).
> >
> > - Jared
> >
> > > On Apr 10, 2017, at 9:41 PM, Jacob Barrett 
> wrote:
> > >
> > > There are certainly many projects in the OS community that have solved
> > this
> > > same problem. Perhaps we can find a class loader from a project that
> > would
> > > suite this need.
> > >
> > > Quick search of standalone frameworks comes up with a few popular hits:
> > > https://github.com/kamranzafar/JCL
> > > https://github.com/jboss-modules/jboss-modules
> > >
> > > -Jake
> > >
> > >
> > >
> > >
> > > On Mon, Apr 10, 2017 at 1:40 PM Kirk Lund  wrote:
> > >
> > >> I think Jared started down this path because we had a custom
> classloader
> > >> implementation that he was trying to get rid of -- that impl was
> pretty
> > >> limited and forced loading of all classes up-front.
> > >>
> > >> Now the code uses fast classpath scanner and that old custom
> classloader
> > >> can't be used. The old classloader is so simplistic and limited that
> > trying
> > >> to modify it looks like more work than writing a new one from scratch.
> > >> Implementing a new custom classloader or switching our codebase to
> use a
> > >> new classloader container (using an existing solution) are both
> possible
> > >> directions. Until that's completed the "deploy jar" command will
> > continue
> > >> to force ALL classes to be loaded up-front.
> > >>
> > >> One major concern is that implementing a new custom classloader is
> > >> non-trivial and could also introduce some new classloader bugs -- of
> > >> particular interest to "deploy jar" is the fact that Java remembers
> TWO
> > >> classloaders for each class [1] -- the CL that *loaded* the class AND
> > the
> > >> CL that *initiated* the request to load the class -- dropping the
> > >> *initiating* CL at runtime can result in failures to load additional
> > >> classes from the CL that directly loaded the class even though that CL
> > is
> > >> intact and available.
> > >>
> > >> [1] states: "When one class loader delegates to another class loader,
> > the
> > >> loader that initiates the loading is not necessarily the same loader
> > that
> > >> completes the loading and defines the class. If L creates C, either by
> > >> defining it directly or by delegation, we say that L initiates loading
> > of C
> > >> or, equivalently, that L is an *initiating* loader of C."
> > >>
> > >> For 

[jira] [Commented] (GEODE-2764) Index entry not entered into cluster config xml if region name contains a function call like entrySet()

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965093#comment-15965093
 ] 

ASF GitHub Bot commented on GEODE-2764:
---

GitHub user nabarunnag opened a pull request:

https://github.com/apache/geode/pull/449

GEODE-2764: Added checks on the region name

* Substring the region name till the last occurance of '.'
* Check if this substring is a valid region name
* Continue this till we get valid region name
* If there are no '.' left to substring on, send region not found 
exception.

@jhuynh1 @ladyVader @gesterzhou 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nabarunnag/incubator-geode feature/GEODE-2764

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/449.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #449


commit b1f4f8ba53cf25d5df8a0cdbbf8e9fcc29763bb2
Author: nabarun 
Date:   2017-04-10T18:41:14Z

GEODE-2764: Added checks on the region name

* Substring the region name till the last occurance of '.'
* Check if this substring is a valid region name
* Continue this till we get valid region name
* If there are no '.' left to substring on, send region not found 
exception.




> Index entry not entered into cluster config xml if region name contains a 
> function call like entrySet()
> ---
>
> Key: GEODE-2764
> URL: https://issues.apache.org/jira/browse/GEODE-2764
> Project: Geode
>  Issue Type: Bug
>Reporter: nabarun
>
> Steps to recreate the issue type the following in a gfsh instance:
> 1. start locator --name=locator
> 2. start server --name=server
> 3. create region --name=regionName --type=REPLICATE_PERSISTENT 
> 4. create index --name=regionIndex --region="regionName.entrySet() r" 
> --expression=r.key
> -- this will result in an error message 
> {noformat}
> Failed to create index "regionIndex" due to following reasons
> null
> {noformat}
> Cause:
> The index is created but while putting the entry into the clusterconfig it 
> tries to put the region name as regionName.entrySet() which does not exist. 
> cache.getRegion(regionName.entrySet()) will result in null and no xml entry 
> is added to the clusterconfig. So when the server is restarted, there is no 
> index entry in the cluster config xml hence the index is not re-created.
> Solution:
> If the region name contains the character '(' and ')' spilt the region name 
> at the index of '.' and check if the region exists. 
> If the check returns successful only then enter the entry into the cluster 
> config.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #449: GEODE-2764: Added checks on the region name

[nabarunnag]

GitHub user nabarunnag opened a pull request:

https://github.com/apache/geode/pull/449

GEODE-2764: Added checks on the region name

* Substring the region name till the last occurance of '.'
* Check if this substring is a valid region name
* Continue this till we get valid region name
* If there are no '.' left to substring on, send region not found 
exception.

@jhuynh1 @ladyVader @gesterzhou 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nabarunnag/incubator-geode feature/GEODE-2764

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/449.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #449


commit b1f4f8ba53cf25d5df8a0cdbbf8e9fcc29763bb2
Author: nabarun 
Date:   2017-04-10T18:41:14Z

GEODE-2764: Added checks on the region name

* Substring the region name till the last occurance of '.'
* Check if this substring is a valid region name
* Continue this till we get valid region name
* If there are no '.' left to substring on, send region not found 
exception.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2765) gfsh help should consistently use log4j log levels

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965091#comment-15965091
 ] 

ASF subversion and git services commented on GEODE-2765:


Commit d7e9bf7059cca915e201fa6867f3ee1124315e6e in geode's branch 
refs/heads/develop from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=d7e9bf7 ]

GEODE-2765: change gfsh help to consistently use log4j levels


> gfsh help should consistently use log4j log levels
> --
>
> Key: GEODE-2765
> URL: https://issues.apache.org/jira/browse/GEODE-2765
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> The fix for GEODE-2634 changed the gfsh commands that use --log-level option 
> to use log4j2 log levels. The gfsh help text needs to also change.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #521 was SUCCESSFUL (with 1843 tests)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #521 was successful.
---
Scheduled
1845 tests in total.

https://build.spring.io/browse/SGF-NAG-521/





--
This message is automatically generated by Atlassian Bamboo

[jira] [Commented] (GEODE-2745) The AsyncEventQueueImpl waitUntilFlushed method waits longer than it should for events to be flushed

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965021#comment-15965021
 ] 

ASF subversion and git services commented on GEODE-2745:


Commit 332df09059f4d5a3a1626b80340559c0717ae63f in geode's branch 
refs/heads/feature/GEODE-2745 from [~lhughesgodfrey]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=332df09 ]

GEODE-2745: WaitUntilBucketRegionQueueFlushedCallable gets 
BucketRegionQueue.latestQueuedKey in constructor vs. setting when callable 
invoked.

- Added getter in BucketRegionQueue for latestQueuedKey
- WaitUntilBucketRegionQueueFlushedCallable constructor now gets/maintains the 
BucketRegionQueue.latestQueuedKey


> The AsyncEventQueueImpl waitUntilFlushed method waits longer than it should 
> for events to be flushed
> 
>
> Key: GEODE-2745
> URL: https://issues.apache.org/jira/browse/GEODE-2745
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Barry Oglesby
>
> With the changes to waitUntilFlushed to process 10 buckets at a time, if 
> events are happening while waitUntilFlushed is in progress, then all the 
> buckets after the first 10 will have processed more than it should before 
> returning.
> If the update rate is causing the queue to always contain 113000 events, and 
> the events are spread evenly across the buckets, each bucket will have 1000 
> events to wait for. The first 10 buckets will wait for their 1000 events. 
> When those have been processed, the next 10 buckets will wait for their 1000 
> events starting from that point, but they've already processed 1000 events. 
> So, these buckets will actually wait for 2000 events to be processed before 
> returning. This pattern continues until all the buckets are done.
> The WaitUntilBucketRegionQueueFlushedCallable needs to track not only the 
> BucketRegionQueue but also the latestQueuedKey.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-230) Remove deprecated AttributesFactory

[Joey McAllister (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joey McAllister updated GEODE-230:
--
Component/s: docs

> Remove deprecated AttributesFactory
> ---
>
> Key: GEODE-230
> URL: https://issues.apache.org/jira/browse/GEODE-230
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs
>Reporter: Darrel Schneider
>
> Should AttributesFactory be remove since it has been deprecated since 6.5.
> In that release we started telling customers to use Cache.createRegionFactory 
> or ClientCache.createClientRegionFactory.
> However here are a couple of reasons why we might not want to get rid of 
> AttributesFactory:
> - The corresponding PartitionAttributesFactory is not deprecated.
> - We have had customers request that it not be deprecated so that they have a 
> way to create a RegionAttributes on a client, send it to the server in a 
> function, and have the function create a region using the un-deprecated 
> Cache.createRegionFactory(RegionAttributes).
> We could argue that Cache.createRegionFactory(RegionAttributes) is not 
> deprecated so that given an existing region you could get its 
> RegionAttributes by calling Region.getAttributes. But it seems reasonable to 
> want to be able to create a RegionAttributes (and its nested 
> PartitionAttributes) without needing to create the region in the same jvm 
> that is creating the attributes.
>  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2193) a member is kicked out immediately after joining

[Hitesh Khamesra (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hitesh Khamesra reassigned GEODE-2193:
--

Assignee: Hitesh Khamesra  (was: Bruce Schuchardt)

> a member is kicked out immediately after joining
> 
>
> Key: GEODE-2193
> URL: https://issues.apache.org/jira/browse/GEODE-2193
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Hitesh Khamesra
> Fix For: 1.1.0
>
>
> We have observed a number of cases where a member is kicked out immediately 
> after joining.  The problem seems to be this:
> 1) the member sends a join request to the current coordinator
> 2) the current coordinator is in the process of shutting down
> 3) the current coordinator sends a view preparation message admitting the new 
> member
> 4) another member receives the current coordinator's shutdown message and 
> initiates becoming the coordinator
> 5) the new coordinator sends out a membership view that does not include the 
> new member
> 6) the new member receives the prepared view and continues with startup
> 7) the new member sends startup messages to other members
> 8) the other members have the new coordinator's view and request removal of 
> the new member as being rogue
> 9) the new coordinator sends a Leave message to the new member, causing it to 
> issue a ForcedDisconnect
> The old coordinator should not initiate a new view if it is shutting down.  
> It needs to have cancellation & shutdown checks in its view transmission 
> methods.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 58325: GEODE-2737: Change Pulse UI tests to use random port for JMX connections

[Ken Howe]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58325/
---

(Updated April 11, 2017, 9:28 p.m.)


Review request for geode, Jinmei Liao, Jared Stewart, Kirk Lund, and Patrick 
Rhomberg.


Changes
---

Ran spotlessApply to reformat the previous change


Repository: geode


Description
---

GEODE-2737: Change Pulse UI tests to use random port for JMX connections


Diffs (updated)
-

  geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/Server.java 
ebf291b481c78533adab9006e32a9dcb5d1d8d39 
  
geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/rules/ServerRule.java
 af3d64bd5118ff870fadc16dcdeb3cde858611ce 


Diff: https://reviews.apache.org/r/58325/diff/3/

Changes: https://reviews.apache.org/r/58325/diff/2-3/


Testing (updated)
---

==> Precheckin was clean other than spotlessCheck. Re-runing the precheckin 
after reformatting to correct the failure

All Pulse UI tests run locally pass.

Precheckin is running


Thanks,

Ken Howe

[jira] [Commented] (GEODE-2745) The AsyncEventQueueImpl waitUntilFlushed method waits longer than it should for events to be flushed

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964958#comment-15964958
 ] 

ASF GitHub Bot commented on GEODE-2745:
---

Github user ladyVader commented on a diff in the pull request:

https://github.com/apache/geode/pull/448#discussion_r111012023
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/internal/cache/BucketRegionQueue.java 
---
@@ -464,16 +464,21 @@ private void setLatestAcknowledgedKey(Long key) {
 this.latestAcknowledgedKey.set(key);
   }
 
-  public boolean waitUntilFlushed(long timeout, TimeUnit unit) throws 
InterruptedException {
+  public long getLatestQueuedKey() {
+return this.latestQueuedKey.get();
+  }
+
+  public boolean waitUntilFlushed(long latestQueuedKey, long timeout, 
TimeUnit unit)
+  throws InterruptedException {
 long then = System.currentTimeMillis();
 if (logger.isDebugEnabled()) {
-  logger.debug("BucketRegionQueue: waitUntilFlushed bucket=" + getId() 
+ "; timeout=" + timeout
-  + "; unit=" + unit);
+  logger.debug("BucketRegionQueue: waitUntilFlushed bucket=" + getId() 
+ "; latestQueuedKey="
+  + latestQueuedKey + "; timeout=" + timeout + "; unit=" + unit);
 }
 boolean result = false;
 // Wait until latestAcknowledgedKey > latestQueuedKey or the queue is 
empty
 if (this.initialized) {
-  long latestQueuedKeyToCheck = this.latestQueuedKey.get();
+  long latestQueuedKeyToCheck = latestQueuedKey;
--- End diff --

Ah, yes ... that does seem more straightforward.   Thanks!


> The AsyncEventQueueImpl waitUntilFlushed method waits longer than it should 
> for events to be flushed
> 
>
> Key: GEODE-2745
> URL: https://issues.apache.org/jira/browse/GEODE-2745
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Barry Oglesby
>
> With the changes to waitUntilFlushed to process 10 buckets at a time, if 
> events are happening while waitUntilFlushed is in progress, then all the 
> buckets after the first 10 will have processed more than it should before 
> returning.
> If the update rate is causing the queue to always contain 113000 events, and 
> the events are spread evenly across the buckets, each bucket will have 1000 
> events to wait for. The first 10 buckets will wait for their 1000 events. 
> When those have been processed, the next 10 buckets will wait for their 1000 
> events starting from that point, but they've already processed 1000 events. 
> So, these buckets will actually wait for 2000 events to be processed before 
> returning. This pattern continues until all the buckets are done.
> The WaitUntilBucketRegionQueueFlushedCallable needs to track not only the 
> BucketRegionQueue but also the latestQueuedKey.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #448: GEODE-2745: WaitUntilBucketRegionQueueFlushedCallab...

[ladyVader]

Github user ladyVader commented on a diff in the pull request:

https://github.com/apache/geode/pull/448#discussion_r111012023
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/internal/cache/BucketRegionQueue.java 
---
@@ -464,16 +464,21 @@ private void setLatestAcknowledgedKey(Long key) {
 this.latestAcknowledgedKey.set(key);
   }
 
-  public boolean waitUntilFlushed(long timeout, TimeUnit unit) throws 
InterruptedException {
+  public long getLatestQueuedKey() {
+return this.latestQueuedKey.get();
+  }
+
+  public boolean waitUntilFlushed(long latestQueuedKey, long timeout, 
TimeUnit unit)
+  throws InterruptedException {
 long then = System.currentTimeMillis();
 if (logger.isDebugEnabled()) {
-  logger.debug("BucketRegionQueue: waitUntilFlushed bucket=" + getId() 
+ "; timeout=" + timeout
-  + "; unit=" + unit);
+  logger.debug("BucketRegionQueue: waitUntilFlushed bucket=" + getId() 
+ "; latestQueuedKey="
+  + latestQueuedKey + "; timeout=" + timeout + "; unit=" + unit);
 }
 boolean result = false;
 // Wait until latestAcknowledgedKey > latestQueuedKey or the queue is 
empty
 if (this.initialized) {
-  long latestQueuedKeyToCheck = this.latestQueuedKey.get();
+  long latestQueuedKeyToCheck = latestQueuedKey;
--- End diff --

Ah, yes ... that does seem more straightforward.   Thanks!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2745) The AsyncEventQueueImpl waitUntilFlushed method waits longer than it should for events to be flushed

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964954#comment-15964954
 ] 

ASF GitHub Bot commented on GEODE-2745:
---

Github user jhuynh1 commented on a diff in the pull request:

https://github.com/apache/geode/pull/448#discussion_r111011735
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/internal/cache/BucketRegionQueue.java 
---
@@ -464,16 +464,21 @@ private void setLatestAcknowledgedKey(Long key) {
 this.latestAcknowledgedKey.set(key);
   }
 
-  public boolean waitUntilFlushed(long timeout, TimeUnit unit) throws 
InterruptedException {
+  public long getLatestQueuedKey() {
+return this.latestQueuedKey.get();
+  }
+
+  public boolean waitUntilFlushed(long latestQueuedKey, long timeout, 
TimeUnit unit)
+  throws InterruptedException {
 long then = System.currentTimeMillis();
 if (logger.isDebugEnabled()) {
-  logger.debug("BucketRegionQueue: waitUntilFlushed bucket=" + getId() 
+ "; timeout=" + timeout
-  + "; unit=" + unit);
+  logger.debug("BucketRegionQueue: waitUntilFlushed bucket=" + getId() 
+ "; latestQueuedKey="
+  + latestQueuedKey + "; timeout=" + timeout + "; unit=" + unit);
 }
 boolean result = false;
 // Wait until latestAcknowledgedKey > latestQueuedKey or the queue is 
empty
 if (this.initialized) {
-  long latestQueuedKeyToCheck = this.latestQueuedKey.get();
+  long latestQueuedKeyToCheck = latestQueuedKey;
--- End diff --

Not an actual problem, but we probably could just replace this variable 
altogether and only use latestQueueKey instead.  


> The AsyncEventQueueImpl waitUntilFlushed method waits longer than it should 
> for events to be flushed
> 
>
> Key: GEODE-2745
> URL: https://issues.apache.org/jira/browse/GEODE-2745
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Barry Oglesby
>
> With the changes to waitUntilFlushed to process 10 buckets at a time, if 
> events are happening while waitUntilFlushed is in progress, then all the 
> buckets after the first 10 will have processed more than it should before 
> returning.
> If the update rate is causing the queue to always contain 113000 events, and 
> the events are spread evenly across the buckets, each bucket will have 1000 
> events to wait for. The first 10 buckets will wait for their 1000 events. 
> When those have been processed, the next 10 buckets will wait for their 1000 
> events starting from that point, but they've already processed 1000 events. 
> So, these buckets will actually wait for 2000 events to be processed before 
> returning. This pattern continues until all the buckets are done.
> The WaitUntilBucketRegionQueueFlushedCallable needs to track not only the 
> BucketRegionQueue but also the latestQueuedKey.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #448: GEODE-2745: WaitUntilBucketRegionQueueFlushedCallab...

[jhuynh1]

Github user jhuynh1 commented on a diff in the pull request:

https://github.com/apache/geode/pull/448#discussion_r111011735
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/internal/cache/BucketRegionQueue.java 
---
@@ -464,16 +464,21 @@ private void setLatestAcknowledgedKey(Long key) {
 this.latestAcknowledgedKey.set(key);
   }
 
-  public boolean waitUntilFlushed(long timeout, TimeUnit unit) throws 
InterruptedException {
+  public long getLatestQueuedKey() {
+return this.latestQueuedKey.get();
+  }
+
+  public boolean waitUntilFlushed(long latestQueuedKey, long timeout, 
TimeUnit unit)
+  throws InterruptedException {
 long then = System.currentTimeMillis();
 if (logger.isDebugEnabled()) {
-  logger.debug("BucketRegionQueue: waitUntilFlushed bucket=" + getId() 
+ "; timeout=" + timeout
-  + "; unit=" + unit);
+  logger.debug("BucketRegionQueue: waitUntilFlushed bucket=" + getId() 
+ "; latestQueuedKey="
+  + latestQueuedKey + "; timeout=" + timeout + "; unit=" + unit);
 }
 boolean result = false;
 // Wait until latestAcknowledgedKey > latestQueuedKey or the queue is 
empty
 if (this.initialized) {
-  long latestQueuedKeyToCheck = this.latestQueuedKey.get();
+  long latestQueuedKeyToCheck = latestQueuedKey;
--- End diff --

Not an actual problem, but we probably could just replace this variable 
altogether and only use latestQueueKey instead.  


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2745) The AsyncEventQueueImpl waitUntilFlushed method waits longer than it should for events to be flushed

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964942#comment-15964942
 ] 

ASF GitHub Bot commented on GEODE-2745:
---

GitHub user ladyVader opened a pull request:

https://github.com/apache/geode/pull/448

GEODE-2745: WaitUntilBucketRegionQueueFlushedCallable gets BucketRegi…


GEODE-2745: waitUntilFlushed method waits longer than it should

- Added getter in BucketRegionQueue for latestQueuedKey
- WaitUntilBucketRegionQueueFlushedCallable constructor now gets/maintains 
the BucketRegionQueue.latestQueuedKey

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/geode feature/GEODE-2745

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/448.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #448


commit ba3b28adc48884bb5d697d307a28f4831f5d9301
Author: Lynn Hughes-Godfrey 
Date:   2017-04-07T18:57:16Z

GEODE-2745: WaitUntilBucketRegionQueueFlushedCallable gets 
BucketRegionQueue.latestQueuedKey in constructor vs. setting when callable 
invoked.

- Added getter in BucketRegionQueue for latestQueuedKey
- WaitUntilBucketRegionQueueFlushedCallable constructor now gets/maintains 
the BucketRegionQueue.latestQueuedKey




> The AsyncEventQueueImpl waitUntilFlushed method waits longer than it should 
> for events to be flushed
> 
>
> Key: GEODE-2745
> URL: https://issues.apache.org/jira/browse/GEODE-2745
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Barry Oglesby
>
> With the changes to waitUntilFlushed to process 10 buckets at a time, if 
> events are happening while waitUntilFlushed is in progress, then all the 
> buckets after the first 10 will have processed more than it should before 
> returning.
> If the update rate is causing the queue to always contain 113000 events, and 
> the events are spread evenly across the buckets, each bucket will have 1000 
> events to wait for. The first 10 buckets will wait for their 1000 events. 
> When those have been processed, the next 10 buckets will wait for their 1000 
> events starting from that point, but they've already processed 1000 events. 
> So, these buckets will actually wait for 2000 events to be processed before 
> returning. This pattern continues until all the buckets are done.
> The WaitUntilBucketRegionQueueFlushedCallable needs to track not only the 
> BucketRegionQueue but also the latestQueuedKey.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #448: GEODE-2745: WaitUntilBucketRegionQueueFlushedCallab...

[ladyVader]

GitHub user ladyVader opened a pull request:

https://github.com/apache/geode/pull/448

GEODE-2745: WaitUntilBucketRegionQueueFlushedCallable gets BucketRegi…


GEODE-2745: waitUntilFlushed method waits longer than it should

- Added getter in BucketRegionQueue for latestQueuedKey
- WaitUntilBucketRegionQueueFlushedCallable constructor now gets/maintains 
the BucketRegionQueue.latestQueuedKey

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/geode feature/GEODE-2745

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/448.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #448


commit ba3b28adc48884bb5d697d307a28f4831f5d9301
Author: Lynn Hughes-Godfrey 
Date:   2017-04-07T18:57:16Z

GEODE-2745: WaitUntilBucketRegionQueueFlushedCallable gets 
BucketRegionQueue.latestQueuedKey in constructor vs. setting when callable 
invoked.

- Added getter in BucketRegionQueue for latestQueuedKey
- WaitUntilBucketRegionQueueFlushedCallable constructor now gets/maintains 
the BucketRegionQueue.latestQueuedKey




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: One class loader vs multiple class loaders for deployed jars

[Jacob Barrett]

I can support the idea of taking the small step of fixing the eager class
loading if it doesn't:
1) break the current expected behavior.
2) dig is deeper into a hole with class loading isolation in the future.

If it breaks the current expected behavior, that in itself is ok until you
consider that adding class loader isolation later will most definitely
break the expected behavior, can we afford do break it twice?

-Jake

On Tue, Apr 11, 2017 at 10:06 AM Jared Stewart  wrote:

> I would like to distinguish between the following two objectives:
>  1) Do not eagerly load every class contained in a deployed jar
>  2) Establish robust classloader isolation for deployed jars
>
> The aim of my current line of work is to fix 1) (GEODE-2290).  This is not
> to say that 2) is not a valuable pursuit, but I think getting 2) done
> correctly is a larger task than fixing 1) in isolation.
>
> To get into the specifics of the libraries you mentioned,
>
> JCL:
>  - JCL has no support for removing/undeploying jars.  In this respect, I
> don't see anything that JCL would add over simply using a URLClassLoader.
> We would have to rebuild the JCL class loader in exactly the same set of
> circumstances that we would need to rebuild a URLClassLoader.
>  - I have seen a fair number of warnings from people that JCL is buggy and
> incomplete, e.g. (
> http://stackoverflow.com/questions/60764/how-should-i-load-jars-dynamically-at-runtime#comment43066872_1450837)
> This would seem to be supported by a quick look at the github issues page
> for JCL, which includes things like a bug report of a deadlock from Jun
> 2016 to which the developers have never responded.
>
> JBoss Modules:
>  - JBoss Modules (or Java 9/Jigsaw Modules) seem like a good strategic
> direction towards which to strive.  Yet the fact that they require an
> external module descriptor (XML) would again seem to make this a much
> larger task than 1) alone.  (If the idea here is to have a user provide us
> with a JBoss Module rather than a plain jar file, this would be a large
> breaking change for existing users.  On the other hand, if the idea is for
> us to autogenerate the necessary metainformation to transform the user's
> jar file into a JBoss Module, this would seem to be a large task which is
> again independent from the goals of 1).
>
> - Jared
>
> > On Apr 10, 2017, at 9:41 PM, Jacob Barrett  wrote:
> >
> > There are certainly many projects in the OS community that have solved
> this
> > same problem. Perhaps we can find a class loader from a project that
> would
> > suite this need.
> >
> > Quick search of standalone frameworks comes up with a few popular hits:
> > https://github.com/kamranzafar/JCL
> > https://github.com/jboss-modules/jboss-modules
> >
> > -Jake
> >
> >
> >
> >
> > On Mon, Apr 10, 2017 at 1:40 PM Kirk Lund  wrote:
> >
> >> I think Jared started down this path because we had a custom classloader
> >> implementation that he was trying to get rid of -- that impl was pretty
> >> limited and forced loading of all classes up-front.
> >>
> >> Now the code uses fast classpath scanner and that old custom classloader
> >> can't be used. The old classloader is so simplistic and limited that
> trying
> >> to modify it looks like more work than writing a new one from scratch.
> >> Implementing a new custom classloader or switching our codebase to use a
> >> new classloader container (using an existing solution) are both possible
> >> directions. Until that's completed the "deploy jar" command will
> continue
> >> to force ALL classes to be loaded up-front.
> >>
> >> One major concern is that implementing a new custom classloader is
> >> non-trivial and could also introduce some new classloader bugs -- of
> >> particular interest to "deploy jar" is the fact that Java remembers TWO
> >> classloaders for each class [1] -- the CL that *loaded* the class AND
> the
> >> CL that *initiated* the request to load the class -- dropping the
> >> *initiating* CL at runtime can result in failures to load additional
> >> classes from the CL that directly loaded the class even though that CL
> is
> >> intact and available.
> >>
> >> [1] states: "When one class loader delegates to another class loader,
> the
> >> loader that initiates the loading is not necessarily the same loader
> that
> >> completes the loading and defines the class. If L creates C, either by
> >> defining it directly or by delegation, we say that L initiates loading
> of C
> >> or, equivalently, that L is an *initiating* loader of C."
> >>
> >> For better or worse, this is one of the reasons why that old custom CL
> was
> >> naively force loading all classes up-front -- ie, to avoid runtime
> >> classloading failures if the initiating CL was dropped or replaced and
> >> ultimately GC'ed. Java won't let you drop the *loading* CL but it will
> >> allow you to drop the *initiating* CL (or it did historically -- the
> >> reference seems to 

[GitHub] geode issue #447: Feature/geode 2217

[kirklund]

Github user kirklund commented on the issue:

https://github.com/apache/geode/pull/447
  
@dalyssakim Can you please do a git fetch and rebase your branch on 
develop? That should trigger the travis-ci again and pick up the fix that 
Darrel committed. Thanks!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #441: Fix a repetition in the README.

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/441


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode issue #447: Feature/geode 2217

[kirklund]

Github user kirklund commented on the issue:

https://github.com/apache/geode/pull/447
  
The Travis-CI failures are the NPEs that Darrel's change introduced. He 
reverted his change so that should resolve these failures.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Reopened] (GEODE-2485) CacheTransactionManager suspend/resume can leak memory for 30 minutes

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider reopened GEODE-2485:
-

The previous fix broke this unit test: PartitionedRegionQueryEvaluatorTest
So that fix has been reverted and a new one will be checked in.


> CacheTransactionManager suspend/resume can leak memory for 30 minutes
> -
>
> Key: GEODE-2485
> URL: https://issues.apache.org/jira/browse/GEODE-2485
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> Each time you suspend/resume a transaction it leaves about 80 bytes of heap 
> allocated for 30 minutes. If you are doing a high rate of suspend/resume 
> calls then this could cause you to run out of memory in that 30 minute window.
> As a workaround you can set -Dgemfire.suspendedTxTimeout to a value as small 
> as 1 (which would cause the memory to be freed up after 1 minute instead of 
> 30 minutes).
> One fix for this is to periodically call cache.getCCPTimer().timerPurge() 
> after a certain number of resume calls have been done (for example 1000). 
> Currently resume is calling cancel on the TimerTask but that leaves the task 
> in the SystemTimer queue until it expires. Calling timerPurge it addition to 
> cancel will fix this bug. Calling timerPurge for every cancel may cause the 
> resume method to take too long and keep in mind the getCCPTimer is used by 
> other things so the size of the SystemTimer queue that is being purged will 
> not only be the number of suspended txs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2485) CacheTransactionManager suspend/resume can leak memory for 30 minutes

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964717#comment-15964717
 ] 

ASF subversion and git services commented on GEODE-2485:


Commit 0aebf39bd1e8cc85ba80ad5ea8b2f2f7b441600d in geode's branch 
refs/heads/feature/GEODE-2485 from [~dschneider]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=0aebf39 ]

Revert "Revert "GEODE-2485: fix leak in tx suspend/resume""

This reverts commit 591391e0e9880d43eb57c39a7ab9c9b00d3e58df.


> CacheTransactionManager suspend/resume can leak memory for 30 minutes
> -
>
> Key: GEODE-2485
> URL: https://issues.apache.org/jira/browse/GEODE-2485
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> Each time you suspend/resume a transaction it leaves about 80 bytes of heap 
> allocated for 30 minutes. If you are doing a high rate of suspend/resume 
> calls then this could cause you to run out of memory in that 30 minute window.
> As a workaround you can set -Dgemfire.suspendedTxTimeout to a value as small 
> as 1 (which would cause the memory to be freed up after 1 minute instead of 
> 30 minutes).
> One fix for this is to periodically call cache.getCCPTimer().timerPurge() 
> after a certain number of resume calls have been done (for example 1000). 
> Currently resume is calling cancel on the TimerTask but that leaves the task 
> in the SystemTimer queue until it expires. Calling timerPurge it addition to 
> cancel will fix this bug. Calling timerPurge for every cancel may cause the 
> resume method to take too long and keep in mind the getCCPTimer is used by 
> other things so the size of the SystemTimer queue that is being purged will 
> not only be the number of suspended txs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2485) CacheTransactionManager suspend/resume can leak memory for 30 minutes

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964716#comment-15964716
 ] 

ASF subversion and git services commented on GEODE-2485:


Commit 591391e0e9880d43eb57c39a7ab9c9b00d3e58df in geode's branch 
refs/heads/feature/GEODE-2485 from [~dschneider]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=591391e ]

Revert "GEODE-2485: fix leak in tx suspend/resume"

This reverts commit 344f93dfd07e6ace79cedfb474bf524b97232281.
This commit broke PartitionedRegionQueryEvaluatorTest.


> CacheTransactionManager suspend/resume can leak memory for 30 minutes
> -
>
> Key: GEODE-2485
> URL: https://issues.apache.org/jira/browse/GEODE-2485
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> Each time you suspend/resume a transaction it leaves about 80 bytes of heap 
> allocated for 30 minutes. If you are doing a high rate of suspend/resume 
> calls then this could cause you to run out of memory in that 30 minute window.
> As a workaround you can set -Dgemfire.suspendedTxTimeout to a value as small 
> as 1 (which would cause the memory to be freed up after 1 minute instead of 
> 30 minutes).
> One fix for this is to periodically call cache.getCCPTimer().timerPurge() 
> after a certain number of resume calls have been done (for example 1000). 
> Currently resume is calling cancel on the TimerTask but that leaves the task 
> in the SystemTimer queue until it expires. Calling timerPurge it addition to 
> cancel will fix this bug. Calling timerPurge for every cancel may cause the 
> resume method to take too long and keep in mind the getCCPTimer is used by 
> other things so the size of the SystemTimer queue that is being purged will 
> not only be the number of suspended txs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2485) CacheTransactionManager suspend/resume can leak memory for 30 minutes

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964712#comment-15964712
 ] 

ASF subversion and git services commented on GEODE-2485:


Commit 344f93dfd07e6ace79cedfb474bf524b97232281 in geode's branch 
refs/heads/feature/GEODE-2485 from [~dschneider]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=344f93d ]

GEODE-2485: fix leak in tx suspend/resume

The CCPTimer is now purged for every 1000 cancels done.
So we will now no longer have more than 1000
cancelled tasks eating up memory.
Now uses internalSuspend in two places the previously used suspend.
Since internalSuspend does not schedule a timer task
these places will have no more issues with leaking memory
and these code paths will perform better.

renamed resume(TxStateProxy) to internalResume for clarity.

internalResume no longer checks for a TimerTask to cancel
since internalSuspend does not add one.
Instead the only code that checks for a TimerTask is "resume".


> CacheTransactionManager suspend/resume can leak memory for 30 minutes
> -
>
> Key: GEODE-2485
> URL: https://issues.apache.org/jira/browse/GEODE-2485
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> Each time you suspend/resume a transaction it leaves about 80 bytes of heap 
> allocated for 30 minutes. If you are doing a high rate of suspend/resume 
> calls then this could cause you to run out of memory in that 30 minute window.
> As a workaround you can set -Dgemfire.suspendedTxTimeout to a value as small 
> as 1 (which would cause the memory to be freed up after 1 minute instead of 
> 30 minutes).
> One fix for this is to periodically call cache.getCCPTimer().timerPurge() 
> after a certain number of resume calls have been done (for example 1000). 
> Currently resume is calling cancel on the TimerTask but that leaves the task 
> in the SystemTimer queue until it expires. Calling timerPurge it addition to 
> cancel will fix this bug. Calling timerPurge for every cancel may cause the 
> resume method to take too long and keep in mind the getCCPTimer is used by 
> other things so the size of the SystemTimer queue that is being purged will 
> not only be the number of suspended txs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2757) Netsearch may return a null object when there are other replicates available in the cluster

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964711#comment-15964711
 ] 

ASF subversion and git services commented on GEODE-2757:


Commit d497d63af422b3b98c480698a9470812539f8a83 in geode's branch 
refs/heads/feature/GEODE-2485 from [~eshu]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=d497d63 ]

GEODE-2757: Do not process netsearch reply from a departed node that membership 
listener already detected.


> Netsearch may return a null object when there are other replicates available 
> in the cluster
> ---
>
> Key: GEODE-2757
> URL: https://issues.apache.org/jira/browse/GEODE-2757
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Eric Shu
>Assignee: Eric Shu
> Fix For: 1.2.0
>
>
> There is a race that netsearch in SearchLoadAndWriteProcessor. Multiple 
> threads are processing netsearch replies if a member departed event woke up 
> the reply waiting thread.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-1274) Pulse logging does not appear in Geode log file.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964713#comment-15964713
 ] 

ASF subversion and git services commented on GEODE-1274:


Commit 31b650742d7552d12495bc10f7d7a8a88b78370d in geode's branch 
refs/heads/feature/GEODE-2485 from [~prhomberg]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=31b6507 ]

GEODE-1274: Migration from PulseLogWriter to Log4j standard and removal of 
associated classes.

* To avoid dependency on geode-core, the pulse loggers are instantiated 
directly from LogManager, rather than canonical LogService (which itself 
extends LogManager).
* Significant reduction of logging level state checks, relying on Log4j 
handling.
* Significant reduction of string concatenation, relying on Log4j2 string 
substitutions.
* Reduction of logging using an exception e.getMessage, favoring instead 
passing the exception itself for the stacktrace.
* Multiple identical exception blocks collapsed.
* this closes #446


> Pulse logging does not appear in Geode log file.
> 
>
> Key: GEODE-1274
> URL: https://issues.apache.org/jira/browse/GEODE-1274
> Project: Geode
>  Issue Type: Bug
>  Components: logging, pulse
>Affects Versions: 1.0.0-incubating, 1.1.0
>Reporter: Jens Deppe
>  Labels: Log4j2
>
> While trying to enable debug logging for Pulse, I found that no Pulse logging 
> appears in the Geode log. The Admin REST logging does appear though.
> I had tried to enable debug logging by starting a locator with the followiing 
> log4j config:
> {noformat}
> 
>  packages="com.gemstone.gemfire.internal.logging.log4j">
>   
> [%level{lowerCase=true} %date{/MM/dd 
> HH:mm:ss.SSS z} %thread tid=%tid] %message%n%throwable%n
>   
>   
> 
>   
> 
>   
>   
> 
> 
>onMismatch="NEUTRAL"/>
> 
> 
> 
> 
>   
> 
>   
> 
> {noformat}
> However, only the Admin REST app produced debug log output. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2767) Extend testing coverage of export logs

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964715#comment-15964715
 ] 

ASF subversion and git services commented on GEODE-2767:


Commit 42bc1093be2707c16838f477bcccb7933ba9bc53 in geode's branch 
refs/heads/feature/GEODE-2485 from [~prhomberg]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=42bc109 ]

GEODE-2767: Added DUnitTests to validate export log options --group and 
--member.

* this closes #445


> Extend testing coverage of export logs
> --
>
> Key: GEODE-2767
> URL: https://issues.apache.org/jira/browse/GEODE-2767
> Project: Geode
>  Issue Type: Test
>  Components: gfsh
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>
> Move the hydra functional tests of "export logs" to GEODE. Currently, export 
> logs tests do not cover --group and --member options.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2756) export logs integration with security

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964709#comment-15964709
 ] 

ASF subversion and git services commented on GEODE-2756:


Commit 19376d3069a7808481b2ed572ea49e3610dc9df1 in geode's branch 
refs/heads/feature/GEODE-2485 from [~jinmeiliao]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=19376d3 ]

GEODE-2756: Do not put security-* properties in the env.


> export logs integration with security
> -
>
> Key: GEODE-2756
> URL: https://issues.apache.org/jira/browse/GEODE-2756
> Project: Geode
>  Issue Type: Sub-task
>  Components: logging
>Reporter: Swapnil Bawaskar
>Assignee: Jinmei Liao
> Fix For: 1.2.0
>
>
> We need to make sure that a user is able to export logs when a 
> {{security-manager}} has been configured.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Fixed: apache/geode#2328 (develop - 591391e)

[Travis CI]

Build Update for apache/geode
-

Build: #2328
Status: Fixed

Duration: 8 minutes and 19 seconds
Commit: 591391e (develop)
Author: Darrel Schneider
Message: Revert "GEODE-2485: fix leak in tx suspend/resume"

This reverts commit 344f93dfd07e6ace79cedfb474bf524b97232281.
This commit broke PartitionedRegionQueryEvaluatorTest.

View the changeset: 
https://github.com/apache/geode/compare/42bc1093be27...591391e0e988

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/221049301

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

[jira] [Commented] (GEODE-2732) after auto-reconnect a server is restarted on the default port of 40404

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964710#comment-15964710
 ] 

ASF subversion and git services commented on GEODE-2732:


Commit 799548ee4e4d883309f83bf401d6af892b3abfc1 in geode's branch 
refs/heads/feature/GEODE-2485 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=799548e ]

GEODE-2732 after auto-reconnect a server is restarted on the default port

Now that gfsh cache server parameters are no longer held in a ThreadLocal
we need to clear the static variables holding the parameters in order
to avoid having one test affect another.


> after auto-reconnect a server is restarted on the default port of 40404
> ---
>
> Key: GEODE-2732
> URL: https://issues.apache.org/jira/browse/GEODE-2732
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
> Fix For: 1.2.0
>
>
> If you start a server using gfsh with the server defined in a cache.xml and 
> you specify the server's port Geode will ignore this setting in the event of 
> an auto-reconnect.  I observed this in a GemFire deployment and the code in 
> this area hasn't changed in Apache Geode.  By chance port 40404 was already 
> in use when the auto-reconnect occurred and an exception was thrown.
> {noformat}
> com.gemstone.gemfire.GemFireIOException: While starting bridge server  
> CacheServer on port=40404 client subscription config policy=none client 
> subscription config capacity=1 client subscription config overflow directory=.
>   at 
> com.gemstone.gemfire.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:611)
>   at 
> com.gemstone.gemfire.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:340)
>   at 
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4263)
>   at 
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1178)
>   at 
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.init(GemFireCacheImpl.java:1020)
>   at 
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:684)
>   at 
> com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2909)
>   at 
> com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2655)
>   at 
> com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1058)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionManager$MyListener.membershipFailure(DistributionManager.java:4822)
>   at 
> com.gemstone.gemfire.distributed.internal.membership.jgroup.JGroupMembershipManager.uncleanShutdown(JGroupMembershipManager.java:2733)
>   at 
> com.gemstone.gemfire.distributed.internal.membership.jgroup.JGroupMembershipManager$Puller.channelClosing(JGroupMembershipManager.java:1213)
>   at 
> com.gemstone.org.jgroups.JChannel$CloserThread.run(JChannel.java:1617)
> Caused by: java.net.BindException: Address already in use
>   at sun.nio.ch.Net.bind0(Native Method)
>   at sun.nio.ch.Net.bind(Net.java:463)
>   at sun.nio.ch.Net.bind(Net.java:455)
>   at 
> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
>   at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.AcceptorImpl.(AcceptorImpl.java:432)
>   at 
> com.gemstone.gemfire.internal.cache.BridgeServerImpl.start(BridgeServerImpl.java:342)
>   at 
> com.gemstone.gemfire.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:607)
>   ... 12 more
> {noformat}
> I think the fix is to get rid of the ThreadLocal storage of the port and bind 
> address in CacheServerLauncher.  These variables are used by the XML parser 
> to configure a server.  Gfsh sets them in its thread but they aren't 
> available in the auto-reconnect thread that rebuilds the cache.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2485) CacheTransactionManager suspend/resume can leak memory for 30 minutes

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964688#comment-15964688
 ] 

ASF subversion and git services commented on GEODE-2485:


Commit 591391e0e9880d43eb57c39a7ab9c9b00d3e58df in geode's branch 
refs/heads/develop from [~dschneider]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=591391e ]

Revert "GEODE-2485: fix leak in tx suspend/resume"

This reverts commit 344f93dfd07e6ace79cedfb474bf524b97232281.
This commit broke PartitionedRegionQueryEvaluatorTest.


> CacheTransactionManager suspend/resume can leak memory for 30 minutes
> -
>
> Key: GEODE-2485
> URL: https://issues.apache.org/jira/browse/GEODE-2485
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> Each time you suspend/resume a transaction it leaves about 80 bytes of heap 
> allocated for 30 minutes. If you are doing a high rate of suspend/resume 
> calls then this could cause you to run out of memory in that 30 minute window.
> As a workaround you can set -Dgemfire.suspendedTxTimeout to a value as small 
> as 1 (which would cause the memory to be freed up after 1 minute instead of 
> 30 minutes).
> One fix for this is to periodically call cache.getCCPTimer().timerPurge() 
> after a certain number of resume calls have been done (for example 1000). 
> Currently resume is calling cancel on the TimerTask but that leaves the task 
> in the SystemTimer queue until it expires. Calling timerPurge it addition to 
> cancel will fix this bug. Calling timerPurge for every cancel may cause the 
> resume method to take too long and keep in mind the getCCPTimer is used by 
> other things so the size of the SystemTimer queue that is being purged will 
> not only be the number of suspended txs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: One class loader vs multiple class loaders for deployed jars

[William Markito Oliveira]

Just adding another spin to this discussion...  Today the idea of
"application"  inside a Geode cluster is really hard to define, there is no
real concept of multitenancy and that also makes the problem of deployed
jar isolation harder.

How would you define the hierarchy of a deployed jar from App 1 vs App 2 ?
There is no concept of application, the main constructs are clients,
servers, regions, functions, callbacks.  In the current architecture I
believe such isolation could happen with "user space" - Where users are
considered for isolation (userA can't see jars deployed by userB unless
specified so) creating then some sense of hierarchy.   But I'm not really
sold on this idea as well because it mixes two different concepts, so just
thinking out loud.

But going back to my main observation, we could try to answer how
multinenancy could be implemented in Geode and use that to solve other
problems like classloader hierarchy.

+1 for options #1 for now as well.

On Tue, Apr 11, 2017 at 12:22 PM, Kirk Lund  wrote:

> I think this comes down to two current (realistic) options:
>
> 1) accept Jared's changes as are so we can avoid forced loading of all
> deployed jars up front (GEODE-2290 will be fixed in the next release)
> 2) reject the changes until someone has time to retrofit Geode with a new
> CL container (GEODE-2290 will not be fixed in the next release)
>
> My choice is #1 -- I'm for accepting and applying the current changes to
> develop (deploy jar will then replace one CL for all deployed jars every
> time you deploy any jars).
>
> What do others want to do?
>
> On Tue, Apr 11, 2017 at 10:06 AM, Jared Stewart 
> wrote:
>
> > I would like to distinguish between the following two objectives:
> >  1) Do not eagerly load every class contained in a deployed jar
> >  2) Establish robust classloader isolation for deployed jars
> >
> > The aim of my current line of work is to fix 1) (GEODE-2290).  This is
> not
> > to say that 2) is not a valuable pursuit, but I think getting 2) done
> > correctly is a larger task than fixing 1) in isolation.
> >
> > To get into the specifics of the libraries you mentioned,
> >
> > JCL:
> >  - JCL has no support for removing/undeploying jars.  In this respect, I
> > don't see anything that JCL would add over simply using a URLClassLoader.
> > We would have to rebuild the JCL class loader in exactly the same set of
> > circumstances that we would need to rebuild a URLClassLoader.
> >  - I have seen a fair number of warnings from people that JCL is buggy
> and
> > incomplete, e.g. (http://stackoverflow.com/ques
> > tions/60764/how-should-i-load-jars-dynamically-at-runtime#
> > comment43066872_1450837)  This would seem to be supported by a quick look
> > at the github issues page for JCL, which includes things like a bug
> report
> > of a deadlock from Jun 2016 to which the developers have never responded.
> >
> > JBoss Modules:
> >  - JBoss Modules (or Java 9/Jigsaw Modules) seem like a good strategic
> > direction towards which to strive.  Yet the fact that they require an
> > external module descriptor (XML) would again seem to make this a much
> > larger task than 1) alone.  (If the idea here is to have a user provide
> us
> > with a JBoss Module rather than a plain jar file, this would be a large
> > breaking change for existing users.  On the other hand, if the idea is
> for
> > us to autogenerate the necessary metainformation to transform the user's
> > jar file into a JBoss Module, this would seem to be a large task which is
> > again independent from the goals of 1).
> >
> > - Jared
> >
> > > On Apr 10, 2017, at 9:41 PM, Jacob Barrett 
> wrote:
> > >
> > > There are certainly many projects in the OS community that have solved
> > this
> > > same problem. Perhaps we can find a class loader from a project that
> > would
> > > suite this need.
> > >
> > > Quick search of standalone frameworks comes up with a few popular hits:
> > > https://github.com/kamranzafar/JCL
> > > https://github.com/jboss-modules/jboss-modules
> > >
> > > -Jake
> > >
> > >
> > >
> > >
> > > On Mon, Apr 10, 2017 at 1:40 PM Kirk Lund  wrote:
> > >
> > >> I think Jared started down this path because we had a custom
> classloader
> > >> implementation that he was trying to get rid of -- that impl was
> pretty
> > >> limited and forced loading of all classes up-front.
> > >>
> > >> Now the code uses fast classpath scanner and that old custom
> classloader
> > >> can't be used. The old classloader is so simplistic and limited that
> > trying
> > >> to modify it looks like more work than writing a new one from scratch.
> > >> Implementing a new custom classloader or switching our codebase to
> use a
> > >> new classloader container (using an existing solution) are both
> possible
> > >> directions. Until that's completed the "deploy jar" command will
> > continue
> > >> to force ALL classes to be loaded up-front.
> > >>
> > 

Re: One class loader vs multiple class loaders for deployed jars

[Anthony Baker]

I recall that initially there was some discussion around plexus-classworlds.  
Does that look promising?

Anthony

> On Apr 11, 2017, at 10:06 AM, Jared Stewart  wrote:
> 
> I would like to distinguish between the following two objectives: 
> 1) Do not eagerly load every class contained in a deployed jar
> 2) Establish robust classloader isolation for deployed jars
> 
> The aim of my current line of work is to fix 1) (GEODE-2290).  This is not to 
> say that 2) is not a valuable pursuit, but I think getting 2) done correctly 
> is a larger task than fixing 1) in isolation.  
> 
> To get into the specifics of the libraries you mentioned,
> 
> JCL:
> - JCL has no support for removing/undeploying jars.  In this respect, I don't 
> see anything that JCL would add over simply using a URLClassLoader.  We would 
> have to rebuild the JCL class loader in exactly the same set of circumstances 
> that we would need to rebuild a URLClassLoader.
> - I have seen a fair number of warnings from people that JCL is buggy and 
> incomplete, e.g. 
> (http://stackoverflow.com/questions/60764/how-should-i-load-jars-dynamically-at-runtime#comment43066872_1450837)
>   This would seem to be supported by a quick look at the github issues page 
> for JCL, which includes things like a bug report of a deadlock from Jun 2016 
> to which the developers have never responded.
> 
> JBoss Modules:
> - JBoss Modules (or Java 9/Jigsaw Modules) seem like a good strategic 
> direction towards which to strive.  Yet the fact that they require an 
> external module descriptor (XML) would again seem to make this a much larger 
> task than 1) alone.  (If the idea here is to have a user provide us with a 
> JBoss Module rather than a plain jar file, this would be a large breaking 
> change for existing users.  On the other hand, if the idea is for us to 
> autogenerate the necessary metainformation to transform the user's jar file 
> into a JBoss Module, this would seem to be a large task which is again 
> independent from the goals of 1).  
> 
> - Jared
> 
>> On Apr 10, 2017, at 9:41 PM, Jacob Barrett  wrote:
>> 
>> There are certainly many projects in the OS community that have solved this
>> same problem. Perhaps we can find a class loader from a project that would
>> suite this need.
>> 
>> Quick search of standalone frameworks comes up with a few popular hits:
>> https://github.com/kamranzafar/JCL
>> https://github.com/jboss-modules/jboss-modules
>> 
>> -Jake
>> 
>> 
>> 
>> 
>> On Mon, Apr 10, 2017 at 1:40 PM Kirk Lund  wrote:
>> 
>>> I think Jared started down this path because we had a custom classloader
>>> implementation that he was trying to get rid of -- that impl was pretty
>>> limited and forced loading of all classes up-front.
>>> 
>>> Now the code uses fast classpath scanner and that old custom classloader
>>> can't be used. The old classloader is so simplistic and limited that trying
>>> to modify it looks like more work than writing a new one from scratch.
>>> Implementing a new custom classloader or switching our codebase to use a
>>> new classloader container (using an existing solution) are both possible
>>> directions. Until that's completed the "deploy jar" command will continue
>>> to force ALL classes to be loaded up-front.
>>> 
>>> One major concern is that implementing a new custom classloader is
>>> non-trivial and could also introduce some new classloader bugs -- of
>>> particular interest to "deploy jar" is the fact that Java remembers TWO
>>> classloaders for each class [1] -- the CL that *loaded* the class AND the
>>> CL that *initiated* the request to load the class -- dropping the
>>> *initiating* CL at runtime can result in failures to load additional
>>> classes from the CL that directly loaded the class even though that CL is
>>> intact and available.
>>> 
>>> [1] states: "When one class loader delegates to another class loader, the
>>> loader that initiates the loading is not necessarily the same loader that
>>> completes the loading and defines the class. If L creates C, either by
>>> defining it directly or by delegation, we say that L initiates loading of C
>>> or, equivalently, that L is an *initiating* loader of C."
>>> 
>>> For better or worse, this is one of the reasons why that old custom CL was
>>> naively force loading all classes up-front -- ie, to avoid runtime
>>> classloading failures if the initiating CL was dropped or replaced and
>>> ultimately GC'ed. Java won't let you drop the *loading* CL but it will
>>> allow you to drop the *initiating* CL (or it did historically -- the
>>> reference seems to be down in native code, not in java.lang.Class). You'd
>>> have to find some way to force all initiating requests up to the parent
>>> application CL (or somehow prevent code in deployed jars from initiating
>>> requests from other CLs) and maybe that's what this old custom classloader
>>> was missing all along.
>>> 
>>> The tradeoff mentioned 

Re: One class loader vs multiple class loaders for deployed jars

[Kirk Lund]

I think this comes down to two current (realistic) options:

1) accept Jared's changes as are so we can avoid forced loading of all
deployed jars up front (GEODE-2290 will be fixed in the next release)
2) reject the changes until someone has time to retrofit Geode with a new
CL container (GEODE-2290 will not be fixed in the next release)

My choice is #1 -- I'm for accepting and applying the current changes to
develop (deploy jar will then replace one CL for all deployed jars every
time you deploy any jars).

What do others want to do?

On Tue, Apr 11, 2017 at 10:06 AM, Jared Stewart  wrote:

> I would like to distinguish between the following two objectives:
>  1) Do not eagerly load every class contained in a deployed jar
>  2) Establish robust classloader isolation for deployed jars
>
> The aim of my current line of work is to fix 1) (GEODE-2290).  This is not
> to say that 2) is not a valuable pursuit, but I think getting 2) done
> correctly is a larger task than fixing 1) in isolation.
>
> To get into the specifics of the libraries you mentioned,
>
> JCL:
>  - JCL has no support for removing/undeploying jars.  In this respect, I
> don't see anything that JCL would add over simply using a URLClassLoader.
> We would have to rebuild the JCL class loader in exactly the same set of
> circumstances that we would need to rebuild a URLClassLoader.
>  - I have seen a fair number of warnings from people that JCL is buggy and
> incomplete, e.g. (http://stackoverflow.com/ques
> tions/60764/how-should-i-load-jars-dynamically-at-runtime#
> comment43066872_1450837)  This would seem to be supported by a quick look
> at the github issues page for JCL, which includes things like a bug report
> of a deadlock from Jun 2016 to which the developers have never responded.
>
> JBoss Modules:
>  - JBoss Modules (or Java 9/Jigsaw Modules) seem like a good strategic
> direction towards which to strive.  Yet the fact that they require an
> external module descriptor (XML) would again seem to make this a much
> larger task than 1) alone.  (If the idea here is to have a user provide us
> with a JBoss Module rather than a plain jar file, this would be a large
> breaking change for existing users.  On the other hand, if the idea is for
> us to autogenerate the necessary metainformation to transform the user's
> jar file into a JBoss Module, this would seem to be a large task which is
> again independent from the goals of 1).
>
> - Jared
>
> > On Apr 10, 2017, at 9:41 PM, Jacob Barrett  wrote:
> >
> > There are certainly many projects in the OS community that have solved
> this
> > same problem. Perhaps we can find a class loader from a project that
> would
> > suite this need.
> >
> > Quick search of standalone frameworks comes up with a few popular hits:
> > https://github.com/kamranzafar/JCL
> > https://github.com/jboss-modules/jboss-modules
> >
> > -Jake
> >
> >
> >
> >
> > On Mon, Apr 10, 2017 at 1:40 PM Kirk Lund  wrote:
> >
> >> I think Jared started down this path because we had a custom classloader
> >> implementation that he was trying to get rid of -- that impl was pretty
> >> limited and forced loading of all classes up-front.
> >>
> >> Now the code uses fast classpath scanner and that old custom classloader
> >> can't be used. The old classloader is so simplistic and limited that
> trying
> >> to modify it looks like more work than writing a new one from scratch.
> >> Implementing a new custom classloader or switching our codebase to use a
> >> new classloader container (using an existing solution) are both possible
> >> directions. Until that's completed the "deploy jar" command will
> continue
> >> to force ALL classes to be loaded up-front.
> >>
> >> One major concern is that implementing a new custom classloader is
> >> non-trivial and could also introduce some new classloader bugs -- of
> >> particular interest to "deploy jar" is the fact that Java remembers TWO
> >> classloaders for each class [1] -- the CL that *loaded* the class AND
> the
> >> CL that *initiated* the request to load the class -- dropping the
> >> *initiating* CL at runtime can result in failures to load additional
> >> classes from the CL that directly loaded the class even though that CL
> is
> >> intact and available.
> >>
> >> [1] states: "When one class loader delegates to another class loader,
> the
> >> loader that initiates the loading is not necessarily the same loader
> that
> >> completes the loading and defines the class. If L creates C, either by
> >> defining it directly or by delegation, we say that L initiates loading
> of C
> >> or, equivalently, that L is an *initiating* loader of C."
> >>
> >> For better or worse, this is one of the reasons why that old custom CL
> was
> >> naively force loading all classes up-front -- ie, to avoid runtime
> >> classloading failures if the initiating CL was dropped or replaced and
> >> ultimately GC'ed. Java won't let you drop the 

Re: Review Request 58325: GEODE-2737: Change Pulse UI tests to use random port for JMX connections

[Ken Howe]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58325/
---

(Updated April 11, 2017, 5:18 p.m.)


Review request for geode, Jinmei Liao, Jared Stewart, Kirk Lund, and Patrick 
Rhomberg.


Changes
---

Inn reponse to Kirk's comment, I renamed parameter port to jmxPort in 
geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/Server.java to 
clarify it's usage.


Repository: geode


Description
---

GEODE-2737: Change Pulse UI tests to use random port for JMX connections


Diffs (updated)
-

  geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/Server.java 
ebf291b481c78533adab9006e32a9dcb5d1d8d39 
  
geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/rules/ServerRule.java
 af3d64bd5118ff870fadc16dcdeb3cde858611ce 


Diff: https://reviews.apache.org/r/58325/diff/2/

Changes: https://reviews.apache.org/r/58325/diff/1-2/


Testing (updated)
---

==> Concourse had a problem on the prechecking while running flaky tests
==> precheckin has been restarted

All Pulse UI tests run locally pass.

Precheckin is running


Thanks,

Ken Howe

[jira] [Commented] (GEODE-2725) export logs does not honor --dir

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964650#comment-15964650
 ] 

ASF GitHub Bot commented on GEODE-2725:
---

Github user PurelyApplied commented on the issue:

https://github.com/apache/geode/pull/438
  
precheckin failed with many errors, most of which seem unrelated.
- Three failures in `PartitionedRegionQueryEvaluatorTest`
- 94 failures in `GlobalRegionOffHeapDUnitTest`, and of those, 92 failed 
with `Operation either timed out, was stopped or Locator does not exist.`

Mismatch in golden file against these changes in help strings has been 
corrected.  An additional precheckin has been started.


> export logs does not honor --dir
> 
>
> Key: GEODE-2725
> URL: https://issues.apache.org/jira/browse/GEODE-2725
> Project: Geode
>  Issue Type: Sub-task
>  Components: gfsh, logging
>Reporter: Swapnil Bawaskar
>Assignee: Patrick Rhomberg
>
> When connected to locator via jmx, run the following command:
> {noformat}
> gfsh>export logs --dir=tmp
> {noformat}
> Observer that the dir option is ignored:
> {noformat}
> Logs exported to the connected member's file system: 
> /Users/sbawaskar/apache/geode/geode-assembly/build/install/apache-geode/loc1/exportedLogs_1490721273215.zip
> {noformat}
> The --tmp option is honored when connected via http.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #438: GEODE-2725: export logs now honors --dir when connected vi...

[PurelyApplied]

Github user PurelyApplied commented on the issue:

https://github.com/apache/geode/pull/438
  
precheckin failed with many errors, most of which seem unrelated.
- Three failures in `PartitionedRegionQueryEvaluatorTest`
- 94 failures in `GlobalRegionOffHeapDUnitTest`, and of those, 92 failed 
with `Operation either timed out, was stopped or Locator does not exist.`

Mismatch in golden file against these changes in help strings has been 
corrected.  An additional precheckin has been started.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: One class loader vs multiple class loaders for deployed jars

[Jared Stewart]

I would like to distinguish between the following two objectives: 
 1) Do not eagerly load every class contained in a deployed jar
 2) Establish robust classloader isolation for deployed jars

The aim of my current line of work is to fix 1) (GEODE-2290).  This is not to 
say that 2) is not a valuable pursuit, but I think getting 2) done correctly is 
a larger task than fixing 1) in isolation.  

To get into the specifics of the libraries you mentioned,

JCL:
 - JCL has no support for removing/undeploying jars.  In this respect, I don't 
see anything that JCL would add over simply using a URLClassLoader.  We would 
have to rebuild the JCL class loader in exactly the same set of circumstances 
that we would need to rebuild a URLClassLoader.
 - I have seen a fair number of warnings from people that JCL is buggy and 
incomplete, e.g. 
(http://stackoverflow.com/questions/60764/how-should-i-load-jars-dynamically-at-runtime#comment43066872_1450837)
  This would seem to be supported by a quick look at the github issues page for 
JCL, which includes things like a bug report of a deadlock from Jun 2016 to 
which the developers have never responded.
 
JBoss Modules:
 - JBoss Modules (or Java 9/Jigsaw Modules) seem like a good strategic 
direction towards which to strive.  Yet the fact that they require an external 
module descriptor (XML) would again seem to make this a much larger task than 
1) alone.  (If the idea here is to have a user provide us with a JBoss Module 
rather than a plain jar file, this would be a large breaking change for 
existing users.  On the other hand, if the idea is for us to autogenerate the 
necessary metainformation to transform the user's jar file into a JBoss Module, 
this would seem to be a large task which is again independent from the goals of 
1).  

- Jared

> On Apr 10, 2017, at 9:41 PM, Jacob Barrett  wrote:
> 
> There are certainly many projects in the OS community that have solved this
> same problem. Perhaps we can find a class loader from a project that would
> suite this need.
> 
> Quick search of standalone frameworks comes up with a few popular hits:
> https://github.com/kamranzafar/JCL
> https://github.com/jboss-modules/jboss-modules
> 
> -Jake
> 
> 
> 
> 
> On Mon, Apr 10, 2017 at 1:40 PM Kirk Lund  wrote:
> 
>> I think Jared started down this path because we had a custom classloader
>> implementation that he was trying to get rid of -- that impl was pretty
>> limited and forced loading of all classes up-front.
>> 
>> Now the code uses fast classpath scanner and that old custom classloader
>> can't be used. The old classloader is so simplistic and limited that trying
>> to modify it looks like more work than writing a new one from scratch.
>> Implementing a new custom classloader or switching our codebase to use a
>> new classloader container (using an existing solution) are both possible
>> directions. Until that's completed the "deploy jar" command will continue
>> to force ALL classes to be loaded up-front.
>> 
>> One major concern is that implementing a new custom classloader is
>> non-trivial and could also introduce some new classloader bugs -- of
>> particular interest to "deploy jar" is the fact that Java remembers TWO
>> classloaders for each class [1] -- the CL that *loaded* the class AND the
>> CL that *initiated* the request to load the class -- dropping the
>> *initiating* CL at runtime can result in failures to load additional
>> classes from the CL that directly loaded the class even though that CL is
>> intact and available.
>> 
>> [1] states: "When one class loader delegates to another class loader, the
>> loader that initiates the loading is not necessarily the same loader that
>> completes the loading and defines the class. If L creates C, either by
>> defining it directly or by delegation, we say that L initiates loading of C
>> or, equivalently, that L is an *initiating* loader of C."
>> 
>> For better or worse, this is one of the reasons why that old custom CL was
>> naively force loading all classes up-front -- ie, to avoid runtime
>> classloading failures if the initiating CL was dropped or replaced and
>> ultimately GC'ed. Java won't let you drop the *loading* CL but it will
>> allow you to drop the *initiating* CL (or it did historically -- the
>> reference seems to be down in native code, not in java.lang.Class). You'd
>> have to find some way to force all initiating requests up to the parent
>> application CL (or somehow prevent code in deployed jars from initiating
>> requests from other CLs) and maybe that's what this old custom classloader
>> was missing all along.
>> 
>> The tradeoff mentioned by Jared is only necessary if we want a release
>> (soon) that does NOT eagerly class load all deployed classes up-front.
>> Otherwise, this is a feature request that users might have to wait a little
>> longer for (and maybe that's ok!).
>> 
>> [1]
>> 

[GitHub] geode issue #404: Geode 2469

[galen-pivotal]

Github user galen-pivotal commented on the issue:

https://github.com/apache/geode/pull/404
  
@ggreen If you can clean up the history from where my PR was merged this 
will be much easier to review. In general, even though we've added the 
`@Experimental` tag, I would like the PR to be complete and release-ready once 
we merge it to develop.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2767) Extend testing coverage of export logs

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964624#comment-15964624
 ] 

ASF subversion and git services commented on GEODE-2767:


Commit 42bc1093be2707c16838f477bcccb7933ba9bc53 in geode's branch 
refs/heads/develop from [~prhomberg]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=42bc109 ]

GEODE-2767: Added DUnitTests to validate export log options --group and 
--member.

* this closes #445


> Extend testing coverage of export logs
> --
>
> Key: GEODE-2767
> URL: https://issues.apache.org/jira/browse/GEODE-2767
> Project: Geode
>  Issue Type: Test
>  Components: gfsh
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>
> Move the hydra functional tests of "export logs" to GEODE. Currently, export 
> logs tests do not cover --group and --member options.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2767) Extend testing coverage of export logs

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964625#comment-15964625
 ] 

ASF GitHub Bot commented on GEODE-2767:
---

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/445


> Extend testing coverage of export logs
> --
>
> Key: GEODE-2767
> URL: https://issues.apache.org/jira/browse/GEODE-2767
> Project: Geode
>  Issue Type: Test
>  Components: gfsh
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>
> Move the hydra functional tests of "export logs" to GEODE. Currently, export 
> logs tests do not cover --group and --member options.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #445: GEODE-2767: Added DUnitTests to validate export log...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/445


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2767) Extend testing coverage of export logs

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964621#comment-15964621
 ] 

ASF GitHub Bot commented on GEODE-2767:
---

Github user jinmeiliao commented on the issue:

https://github.com/apache/geode/pull/445
  
I'll pull this in.


> Extend testing coverage of export logs
> --
>
> Key: GEODE-2767
> URL: https://issues.apache.org/jira/browse/GEODE-2767
> Project: Geode
>  Issue Type: Test
>  Components: gfsh
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>
> Move the hydra functional tests of "export logs" to GEODE. Currently, export 
> logs tests do not cover --group and --member options.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #445: GEODE-2767: Added DUnitTests to validate export log option...

[jinmeiliao]

Github user jinmeiliao commented on the issue:

https://github.com/apache/geode/pull/445
  
I'll pull this in.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (GEODE-2772) gfsh "alter runtime" does not work on locators

[Swapnil Bawaskar (JIRA)]

Swapnil Bawaskar created GEODE-2772:
---

 Summary: gfsh "alter runtime" does not work on locators
 Key: GEODE-2772
 URL: https://issues.apache.org/jira/browse/GEODE-2772
 Project: Geode
  Issue Type: Bug
  Components: gfsh
Reporter: Swapnil Bawaskar


"alter runtime" explicitly leaves out locators so you can't specify a locator 
by name. Also, if you don't specify a memberId, then the command defaults to 
all members that are NOT locators.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2767) Extend testing coverage of export logs

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964606#comment-15964606
 ] 

ASF GitHub Bot commented on GEODE-2767:
---

Github user PurelyApplied commented on the issue:

https://github.com/apache/geode/pull/445
  
Precheckin comes back green across the board, excepting one flaky failure 
in `MemoryThresholdsOffHeapDUnitTest.testDRLoadRejection`


> Extend testing coverage of export logs
> --
>
> Key: GEODE-2767
> URL: https://issues.apache.org/jira/browse/GEODE-2767
> Project: Geode
>  Issue Type: Test
>  Components: gfsh
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>
> Move the hydra functional tests of "export logs" to GEODE. Currently, export 
> logs tests do not cover --group and --member options.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #445: GEODE-2767: Added DUnitTests to validate export log option...

[PurelyApplied]

Github user PurelyApplied commented on the issue:

https://github.com/apache/geode/pull/445
  
Precheckin comes back green across the board, excepting one flaky failure 
in `MemoryThresholdsOffHeapDUnitTest.testDRLoadRejection`


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-1274) Pulse logging does not appear in Geode log file.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964567#comment-15964567
 ] 

ASF subversion and git services commented on GEODE-1274:


Commit 31b650742d7552d12495bc10f7d7a8a88b78370d in geode's branch 
refs/heads/develop from [~prhomberg]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=31b6507 ]

GEODE-1274: Migration from PulseLogWriter to Log4j standard and removal of 
associated classes.

* To avoid dependency on geode-core, the pulse loggers are instantiated 
directly from LogManager, rather than canonical LogService (which itself 
extends LogManager).
* Significant reduction of logging level state checks, relying on Log4j 
handling.
* Significant reduction of string concatenation, relying on Log4j2 string 
substitutions.
* Reduction of logging using an exception e.getMessage, favoring instead 
passing the exception itself for the stacktrace.
* Multiple identical exception blocks collapsed.
* this closes #446


> Pulse logging does not appear in Geode log file.
> 
>
> Key: GEODE-1274
> URL: https://issues.apache.org/jira/browse/GEODE-1274
> Project: Geode
>  Issue Type: Bug
>  Components: logging, pulse
>Affects Versions: 1.0.0-incubating, 1.1.0
>Reporter: Jens Deppe
>  Labels: Log4j2
>
> While trying to enable debug logging for Pulse, I found that no Pulse logging 
> appears in the Geode log. The Admin REST logging does appear though.
> I had tried to enable debug logging by starting a locator with the followiing 
> log4j config:
> {noformat}
> 
>  packages="com.gemstone.gemfire.internal.logging.log4j">
>   
> [%level{lowerCase=true} %date{/MM/dd 
> HH:mm:ss.SSS z} %thread tid=%tid] %message%n%throwable%n
>   
>   
> 
>   
> 
>   
>   
> 
> 
>onMismatch="NEUTRAL"/>
> 
> 
> 
> 
>   
> 
>   
> 
> {noformat}
> However, only the Admin REST app produced debug log output. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-1274) Pulse logging does not appear in Geode log file.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964568#comment-15964568
 ] 

ASF GitHub Bot commented on GEODE-1274:
---

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/446


> Pulse logging does not appear in Geode log file.
> 
>
> Key: GEODE-1274
> URL: https://issues.apache.org/jira/browse/GEODE-1274
> Project: Geode
>  Issue Type: Bug
>  Components: logging, pulse
>Affects Versions: 1.0.0-incubating, 1.1.0
>Reporter: Jens Deppe
>  Labels: Log4j2
>
> While trying to enable debug logging for Pulse, I found that no Pulse logging 
> appears in the Geode log. The Admin REST logging does appear though.
> I had tried to enable debug logging by starting a locator with the followiing 
> log4j config:
> {noformat}
> 
>  packages="com.gemstone.gemfire.internal.logging.log4j">
>   
> [%level{lowerCase=true} %date{/MM/dd 
> HH:mm:ss.SSS z} %thread tid=%tid] %message%n%throwable%n
>   
>   
> 
>   
> 
>   
>   
> 
> 
>onMismatch="NEUTRAL"/>
> 
> 
> 
> 
>   
> 
>   
> 
> {noformat}
> However, only the Admin REST app produced debug log output. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #446: GEODE-1274: Migration from PulseLogWriter to Log4j ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/446


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2766) Only apply patches for dependencies on relevant architectures

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964518#comment-15964518
 ] 

ASF subversion and git services commented on GEODE-2766:


Commit ca44c0df82030c6f279991c56aebf96cfa75756e in geode-native's branch 
refs/heads/develop from [~jens.deppe]
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=ca44c0d ]

GEODE-2766: Dummy commit to close PR

- This closes #89


> Only apply patches for dependencies on relevant architectures
> -
>
> Key: GEODE-2766
> URL: https://issues.apache.org/jira/browse/GEODE-2766
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>
> Currently the patches for openssl and ACE are only required for Solaris but 
> are still applied on all platforms. This can break on Windows if the patching 
> tool cannot correctly convert Windows/Unix line-endings.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #89: GEODE-2766: Only apply patches on Solaris

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/geode-native/pull/89


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2766) Only apply patches for dependencies on relevant architectures

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964514#comment-15964514
 ] 

ASF subversion and git services commented on GEODE-2766:


Commit 876067051269375b2162a953d5dd572469eef1c3 in geode-native's branch 
refs/heads/develop from [~jens.deppe]
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=8760670 ]

GEODE-2766: Only apply patches on Solaris

- This avoids trying to apply patches on Windows which can break if the source
  wasn't actually checked out by a Windows git.


> Only apply patches for dependencies on relevant architectures
> -
>
> Key: GEODE-2766
> URL: https://issues.apache.org/jira/browse/GEODE-2766
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>
> Currently the patches for openssl and ACE are only required for Solaris but 
> are still applied on all platforms. This can break on Windows if the patching 
> tool cannot correctly convert Windows/Unix line-endings.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2766) Only apply patches for dependencies on relevant architectures

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964515#comment-15964515
 ] 

ASF GitHub Bot commented on GEODE-2766:
---

Github user asfgit closed the pull request at:

https://github.com/apache/geode-native/pull/89


> Only apply patches for dependencies on relevant architectures
> -
>
> Key: GEODE-2766
> URL: https://issues.apache.org/jira/browse/GEODE-2766
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>
> Currently the patches for openssl and ACE are only required for Solaris but 
> are still applied on all platforms. This can break on Windows if the patching 
> tool cannot correctly convert Windows/Unix line-endings.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-266) Remove deprecated ObjectSizerImpl

[Avinash Dongre (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avinash Dongre reassigned GEODE-266:


Assignee: Avinash Dongre

> Remove deprecated ObjectSizerImpl
> -
>
> Key: GEODE-266
> URL: https://issues.apache.org/jira/browse/GEODE-266
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> Remove the deprecated ObjectSizerImpl class. It can simply be replaced with 
> ObjectSizer.DEFAULT. It is used in some tests but should be easy to remove.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2771) Geode locators do not see each other after network connection interruption

[Vadim Lotarev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vadim Lotarev updated GEODE-2771:
-
Affects Version/s: 1.1.1

> Geode locators do not see each other after network connection interruption
> --
>
> Key: GEODE-2771
> URL: https://issues.apache.org/jira/browse/GEODE-2771
> Project: Geode
>  Issue Type: Bug
>  Components: locator
>Affects Versions: 1.1.1
>Reporter: Vadim Lotarev
> Attachments: LocatorsWorkingDirs.zip, screenshot.66.jpg
>
>
> How to reproduce:
> 1. Run two locators on different ports on the same machine
> 2. Execute gfsh, connect to each locator subsequently and execute {{list 
> members}}. You'll see both locators in spite of the fact that gfsh is connect 
> to one of them.
> 3. Disable/enable network adapter emulating network connection interruption.
> 4. Repeat step 2. You'll see only one locator in response to {{list members}} 
> (actually that one gfsh is connected to).
> Also there are some strange messages in the logs:
> {code}
> [info 2017/04/11 12:19:33.627 MSK locator_4  receiver,VLOTAREV-17591> tid=0x24] Ignoring the view 
> View[192.168.63.58(locator_41112:16908:locator):1025|12] members: 
> [192.168.63.58(locator_41112:16908:locator):1025]  crashed: 
> [192.168.63.58(locator_4:18396:locator):1024] from member 
> 192.168.63.58(:):1025, which is not in my current view 
> View[192.168.63.58(locator_4:18396:locator):1024|2] members: 
> [192.168.63.58(locator_4:18396:locator):1024]  crashed: 
> [192.168.63.58(locator_41112:16908:locator):1025] 
> {code}
> Please see attached the full content of locator's working directories and 
> screenshot of gfsh commands.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2771) Geode locators do not see each other after network connection interruption

[Vadim Lotarev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vadim Lotarev updated GEODE-2771:
-
Attachment: screenshot.66.jpg
LocatorsWorkingDirs.zip

> Geode locators do not see each other after network connection interruption
> --
>
> Key: GEODE-2771
> URL: https://issues.apache.org/jira/browse/GEODE-2771
> Project: Geode
>  Issue Type: Bug
>  Components: locator
>Reporter: Vadim Lotarev
> Attachments: LocatorsWorkingDirs.zip, screenshot.66.jpg
>
>
> How to reproduce:
> 1. Run two locators on different ports on the same machine
> 2. Execute gfsh, connect to each locator subsequently and execute {{list 
> members}}. You'll see both locators in spite of the fact that gfsh is connect 
> to one of them.
> 3. Disable/enable network adapter emulating network connection interruption.
> 4. Repeat step 2. You'll see only one locator in response to {{list members}} 
> (actually that one gfsh is connected to).
> Also there are some strange messages in the logs:
> {code}
> [info 2017/04/11 12:19:33.627 MSK locator_4  receiver,VLOTAREV-17591> tid=0x24] Ignoring the view 
> View[192.168.63.58(locator_41112:16908:locator):1025|12] members: 
> [192.168.63.58(locator_41112:16908:locator):1025]  crashed: 
> [192.168.63.58(locator_4:18396:locator):1024] from member 
> 192.168.63.58(:):1025, which is not in my current view 
> View[192.168.63.58(locator_4:18396:locator):1024|2] members: 
> [192.168.63.58(locator_4:18396:locator):1024]  crashed: 
> [192.168.63.58(locator_41112:16908:locator):1025] 
> {code}
> Please see attached the full content of locator's working directories and 
> screenshot of gfsh commands.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2771) Geode locators do not see each other after network connection interruption

[Vadim Lotarev (JIRA)]

Vadim Lotarev created GEODE-2771:


 Summary: Geode locators do not see each other after network 
connection interruption
 Key: GEODE-2771
 URL: https://issues.apache.org/jira/browse/GEODE-2771
 Project: Geode
  Issue Type: Bug
  Components: locator
Reporter: Vadim Lotarev


How to reproduce:

1. Run two locators on different ports on the same machine

2. Execute gfsh, connect to each locator subsequently and execute {{list 
members}}. You'll see both locators in spite of the fact that gfsh is connect 
to one of them.

3. Disable/enable network adapter emulating network connection interruption.

4. Repeat step 2. You'll see only one locator in response to {{list members}} 
(actually that one gfsh is connected to).

Also there are some strange messages in the logs:

{code}
[info 2017/04/11 12:19:33.627 MSK locator_4  tid=0x24] Ignoring the view 
View[192.168.63.58(locator_41112:16908:locator):1025|12] members: 
[192.168.63.58(locator_41112:16908:locator):1025]  crashed: 
[192.168.63.58(locator_4:18396:locator):1024] from member 
192.168.63.58(:):1025, which is not in my current view 
View[192.168.63.58(locator_4:18396:locator):1024|2] members: 
[192.168.63.58(locator_4:18396:locator):1024]  crashed: 
[192.168.63.58(locator_41112:16908:locator):1025] 
{code}

Please see attached the full content of locator's working directories and 
screenshot of gfsh commands.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2733) Crash during initialization using Xcode 8.3

[Jacob S. Barrett (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15963879#comment-15963879
 ] 

Jacob S. Barrett commented on GEODE-2733:
-

[~mmartell] Please include references to filed bug report.


> Crash during initialization using Xcode 8.3
> ---
>
> Key: GEODE-2733
> URL: https://issues.apache.org/jira/browse/GEODE-2733
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>
> Circa 27 March 2017, Apple released the macOS 10.12.4 and Xcode 8.3 updates. 
> After applying those updates, all native client executables (e.g., unit 
> tests, integration tests, quickstarts) crashes with a SIGSEGV/EXC_BAD_ACCESS 
> with pthread_mutex_lock() which is part of the initialization of the ACE 
> libraries. We don't know whether it's caused by an incompatibility between 
> ACE and the 10.12.4 runtimes (e.g., a struct has changed in size) or if it's 
> an actual bug in the runtimes. Mike Martell found a bug that has already been 
> filed with Apple about Emacs crashing with pthread-related problems after 
> this update, so our current theory is that there's a problem in the pthreads 
> library from Apple.
> UPDATE: Dave Barnes installed just macOS 10.12.4 and has had no problems. 
> Thus, it appears that Xcode 8.3 is the culprit. Anecdotal evidence suggests 
> that Xcode 8.3 has other problems, too, which may or may not be related to 
> the crashes.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)