[jira] [Resolved] (GEODE-6808) Backward compatibility broken in DistributedSystemMXBean.queryData
[
https://issues.apache.org/jira/browse/GEODE-6808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-6808.
-
Resolution: Fixed
Fix Version/s: 1.10.0
> Backward compatibility broken in DistributedSystemMXBean.queryData
> --
>
> Key: GEODE-6808
> URL: https://issues.apache.org/jira/browse/GEODE-6808
> Project: Geode
> Issue Type: Bug
> Components: jmx, pulse, querying
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.10.0
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> As part of thee efforts to remove {{TypedJson}} and move from {{org.json}} to
> {{Jackson}} between {{1.8.0}} and {{1.9.0}}, the {{JSON}} string returned by
> the {{QueryDataFunction}} doesn't include the object type anymore within the
> array (at least for primitive types). The old version used to return results
> in the form
> {{\{"result":[["java.lang.String","v"],["java.lang.String","b"]]}\}}, while
> the new one uses {{\{"result":["v", "b"]\}}}.
> This function is used through {{DistributedSystemMXBean.queryData}}, so any
> user executing queries through {{JMX}} and relying on the [documented
> representation|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/management/DistributedSystemMXBean.html#queryData-java.lang.String-java.lang.String-int-]
> to parse the results will fail as soon as they upgrade to {{1.9.0}}.
> Several parsing methods within {{DataBrowser.js}} *still use these deleted
> types* as well to create an internal representation that is later used to
> show the results in {{HTML}} so, starting with {{1.9.0}}, the query results
> are always shown as empty.
> {code:javascript}
> // This function creates complete result panel html
> function createHtmlForQueryResults(){
> var memberResults = responseResult.result;
> if(memberResults.length > 0){
> if(memberResults[0].member != undefined || memberResults[0].member !=
> null){
> //console.log("member wise results found..");
> for(var i=0; i //console.log(memberResults[i].member);
> $('#memberAccordion').append(createHtmlForMember(memberResults[i]));
> }
> }else{
> //console.log("cluster level results found..");
> var accordionContentHtml = "";
> accordionContentHtml = createClusterAccordionContentHtml(memberResults);
> var resultHtml = ""+
> accordionContentHtml +"";
> $('#memberAccordion').append(resultHtml);
> }
> }else{
> $('#memberAccordion').append(" No Results Found...");
> }
> }
> {code}
> We need to either re-factor the entire parsing logic to use the new format,
> or revert the changes to keep using the old format.
> Cheers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6808) Backward compatibility broken in DistributedSystemMXBean.queryData
[
https://issues.apache.org/jira/browse/GEODE-6808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863548#comment-16863548
]
ASF subversion and git services commented on GEODE-6808:
Commit 0e3e20831271d671f1aa6e8941dc450c760ffe6e in geode's branch
refs/heads/develop from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0e3e208 ]
GEODE-6808: Restore JSON backward compatibility (#3688)
* GEODE-6808: Revert test changes & add new checks
- Added new unit tests.
- Reverted changes made to tests during the replacement of TypedJson
to be sure backward compatibility is achieved after the implementation
of this ticket.
* GEODE-6808: Restore JSON backward compatibility
Reverted some of the changes made when deleting the in-house JSON
implementation (TypedJson) to the jackson library
('QueryResultFormatter') to restore the backward compatibility.
- Everything is serialized as JSON array with 2 elements: type & value.
- Internal class names are hidden in the JSON document, public
interfaces are included instead.
- Beans and primitive types only use the standard format when they are
not being serialized as part of an array, in which case the type is
ignored as it's already been serialized as ArrayElementType[].
> Backward compatibility broken in DistributedSystemMXBean.queryData
> --
>
> Key: GEODE-6808
> URL: https://issues.apache.org/jira/browse/GEODE-6808
> Project: Geode
> Issue Type: Bug
> Components: jmx, pulse, querying
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: GeodeCommons
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> As part of thee efforts to remove {{TypedJson}} and move from {{org.json}} to
> {{Jackson}} between {{1.8.0}} and {{1.9.0}}, the {{JSON}} string returned by
> the {{QueryDataFunction}} doesn't include the object type anymore within the
> array (at least for primitive types). The old version used to return results
> in the form
> {{\{"result":[["java.lang.String","v"],["java.lang.String","b"]]}\}}, while
> the new one uses {{\{"result":["v", "b"]\}}}.
> This function is used through {{DistributedSystemMXBean.queryData}}, so any
> user executing queries through {{JMX}} and relying on the [documented
> representation|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/management/DistributedSystemMXBean.html#queryData-java.lang.String-java.lang.String-int-]
> to parse the results will fail as soon as they upgrade to {{1.9.0}}.
> Several parsing methods within {{DataBrowser.js}} *still use these deleted
> types* as well to create an internal representation that is later used to
> show the results in {{HTML}} so, starting with {{1.9.0}}, the query results
> are always shown as empty.
> {code:javascript}
> // This function creates complete result panel html
> function createHtmlForQueryResults(){
> var memberResults = responseResult.result;
> if(memberResults.length > 0){
> if(memberResults[0].member != undefined || memberResults[0].member !=
> null){
> //console.log("member wise results found..");
> for(var i=0; i //console.log(memberResults[i].member);
> $('#memberAccordion').append(createHtmlForMember(memberResults[i]));
> }
> }else{
> //console.log("cluster level results found..");
> var accordionContentHtml = "";
> accordionContentHtml = createClusterAccordionContentHtml(memberResults);
> var resultHtml = ""+
> accordionContentHtml +"";
> $('#memberAccordion').append(resultHtml);
> }
> }else{
> $('#memberAccordion').append(" No Results Found...");
> }
> }
> {code}
> We need to either re-factor the entire parsing logic to use the new format,
> or revert the changes to keep using the old format.
> Cheers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6808) Backward compatibility broken in DistributedSystemMXBean.queryData
[
https://issues.apache.org/jira/browse/GEODE-6808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863549#comment-16863549
]
ASF subversion and git services commented on GEODE-6808:
Commit 0e3e20831271d671f1aa6e8941dc450c760ffe6e in geode's branch
refs/heads/develop from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0e3e208 ]
GEODE-6808: Restore JSON backward compatibility (#3688)
* GEODE-6808: Revert test changes & add new checks
- Added new unit tests.
- Reverted changes made to tests during the replacement of TypedJson
to be sure backward compatibility is achieved after the implementation
of this ticket.
* GEODE-6808: Restore JSON backward compatibility
Reverted some of the changes made when deleting the in-house JSON
implementation (TypedJson) to the jackson library
('QueryResultFormatter') to restore the backward compatibility.
- Everything is serialized as JSON array with 2 elements: type & value.
- Internal class names are hidden in the JSON document, public
interfaces are included instead.
- Beans and primitive types only use the standard format when they are
not being serialized as part of an array, in which case the type is
ignored as it's already been serialized as ArrayElementType[].
> Backward compatibility broken in DistributedSystemMXBean.queryData
> --
>
> Key: GEODE-6808
> URL: https://issues.apache.org/jira/browse/GEODE-6808
> Project: Geode
> Issue Type: Bug
> Components: jmx, pulse, querying
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: GeodeCommons
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> As part of thee efforts to remove {{TypedJson}} and move from {{org.json}} to
> {{Jackson}} between {{1.8.0}} and {{1.9.0}}, the {{JSON}} string returned by
> the {{QueryDataFunction}} doesn't include the object type anymore within the
> array (at least for primitive types). The old version used to return results
> in the form
> {{\{"result":[["java.lang.String","v"],["java.lang.String","b"]]}\}}, while
> the new one uses {{\{"result":["v", "b"]\}}}.
> This function is used through {{DistributedSystemMXBean.queryData}}, so any
> user executing queries through {{JMX}} and relying on the [documented
> representation|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/management/DistributedSystemMXBean.html#queryData-java.lang.String-java.lang.String-int-]
> to parse the results will fail as soon as they upgrade to {{1.9.0}}.
> Several parsing methods within {{DataBrowser.js}} *still use these deleted
> types* as well to create an internal representation that is later used to
> show the results in {{HTML}} so, starting with {{1.9.0}}, the query results
> are always shown as empty.
> {code:javascript}
> // This function creates complete result panel html
> function createHtmlForQueryResults(){
> var memberResults = responseResult.result;
> if(memberResults.length > 0){
> if(memberResults[0].member != undefined || memberResults[0].member !=
> null){
> //console.log("member wise results found..");
> for(var i=0; i //console.log(memberResults[i].member);
> $('#memberAccordion').append(createHtmlForMember(memberResults[i]));
> }
> }else{
> //console.log("cluster level results found..");
> var accordionContentHtml = "";
> accordionContentHtml = createClusterAccordionContentHtml(memberResults);
> var resultHtml = ""+
> accordionContentHtml +"";
> $('#memberAccordion').append(resultHtml);
> }
> }else{
> $('#memberAccordion').append(" No Results Found...");
> }
> }
> {code}
> We need to either re-factor the entire parsing logic to use the new format,
> or revert the changes to keep using the old format.
> Cheers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6808) Backward compatibility broken in DistributedSystemMXBean.queryData
[
https://issues.apache.org/jira/browse/GEODE-6808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863547#comment-16863547
]
ASF subversion and git services commented on GEODE-6808:
Commit 0e3e20831271d671f1aa6e8941dc450c760ffe6e in geode's branch
refs/heads/develop from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0e3e208 ]
GEODE-6808: Restore JSON backward compatibility (#3688)
* GEODE-6808: Revert test changes & add new checks
- Added new unit tests.
- Reverted changes made to tests during the replacement of TypedJson
to be sure backward compatibility is achieved after the implementation
of this ticket.
* GEODE-6808: Restore JSON backward compatibility
Reverted some of the changes made when deleting the in-house JSON
implementation (TypedJson) to the jackson library
('QueryResultFormatter') to restore the backward compatibility.
- Everything is serialized as JSON array with 2 elements: type & value.
- Internal class names are hidden in the JSON document, public
interfaces are included instead.
- Beans and primitive types only use the standard format when they are
not being serialized as part of an array, in which case the type is
ignored as it's already been serialized as ArrayElementType[].
> Backward compatibility broken in DistributedSystemMXBean.queryData
> --
>
> Key: GEODE-6808
> URL: https://issues.apache.org/jira/browse/GEODE-6808
> Project: Geode
> Issue Type: Bug
> Components: jmx, pulse, querying
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: GeodeCommons
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> As part of thee efforts to remove {{TypedJson}} and move from {{org.json}} to
> {{Jackson}} between {{1.8.0}} and {{1.9.0}}, the {{JSON}} string returned by
> the {{QueryDataFunction}} doesn't include the object type anymore within the
> array (at least for primitive types). The old version used to return results
> in the form
> {{\{"result":[["java.lang.String","v"],["java.lang.String","b"]]}\}}, while
> the new one uses {{\{"result":["v", "b"]\}}}.
> This function is used through {{DistributedSystemMXBean.queryData}}, so any
> user executing queries through {{JMX}} and relying on the [documented
> representation|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/management/DistributedSystemMXBean.html#queryData-java.lang.String-java.lang.String-int-]
> to parse the results will fail as soon as they upgrade to {{1.9.0}}.
> Several parsing methods within {{DataBrowser.js}} *still use these deleted
> types* as well to create an internal representation that is later used to
> show the results in {{HTML}} so, starting with {{1.9.0}}, the query results
> are always shown as empty.
> {code:javascript}
> // This function creates complete result panel html
> function createHtmlForQueryResults(){
> var memberResults = responseResult.result;
> if(memberResults.length > 0){
> if(memberResults[0].member != undefined || memberResults[0].member !=
> null){
> //console.log("member wise results found..");
> for(var i=0; i //console.log(memberResults[i].member);
> $('#memberAccordion').append(createHtmlForMember(memberResults[i]));
> }
> }else{
> //console.log("cluster level results found..");
> var accordionContentHtml = "";
> accordionContentHtml = createClusterAccordionContentHtml(memberResults);
> var resultHtml = ""+
> accordionContentHtml +"";
> $('#memberAccordion').append(resultHtml);
> }
> }else{
> $('#memberAccordion').append(" No Results Found...");
> }
> }
> {code}
> We need to either re-factor the entire parsing logic to use the new format,
> or revert the changes to keep using the old format.
> Cheers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6855) Improve signaling for Geode Concourse consumers
[ https://issues.apache.org/jira/browse/GEODE-6855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Houghton resolved GEODE-6855. Resolution: Fixed Fix Version/s: 1.10.0 > Improve signaling for Geode Concourse consumers > --- > > Key: GEODE-6855 > URL: https://issues.apache.org/jira/browse/GEODE-6855 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Robert Houghton >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1h > Remaining Estimate: 0h > > I would like a way to find the corresponding the `passing-ref` and > `passing-build` resources at the end of a Concourse pipeline. The parameters > for when a pipeline emits these resources is also confusing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6863) CI failure: A cache server's bind address is only available if it has been started
Darrel Schneider created GEODE-6863:
---
Summary: CI failure: A cache server's bind address is only
available if it has been started
Key: GEODE-6863
URL: https://issues.apache.org/jira/browse/GEODE-6863
Project: Geode
Issue Type: Bug
Components: core
Reporter: Darrel Schneider
This looks like an existing issue that has a very small window of time in which
it can fail.
It should not be hard to fix.
See: http://hydradb.gemfire.pivotal.io/hdb/testresult/5751289
I think the place to fix this is in
org.apache.geode.internal.cache.BucketAdvisor.instantiateProfile(InternalDistributedMember,
int)
It does a test if the server is running and then calls getExternalAddress
twice. If the server is stopped after the isRunning check but before
getExternalAddress is called then getExternalAddress will throw the
IllegalStateException. The following "if" block could be put in a try/catch
that catches IllegalStateException and ignores and skips that server if it is
no longer running.
Another possible fix would be to call getExternalAddress(false) which does not
throw IllegalStateException and then right before adding to serverLocations do
a check that the server is running. Here is the code that needs to be fixed:
{code:java}
for (CacheServer cacheServer : servers) {
CacheServerImpl server = (CacheServerImpl) cacheServer;
if (server.isRunning() && (server.getExternalAddress() != null)) {
BucketServerLocation66 location = new
BucketServerLocation66(getBucket().getId(),
server.getPort(), server.getExternalAddress(),
getBucket().isPrimary(),
Integer.valueOf(version).byteValue(), server.getCombinedGroups());
serverLocations.add(location);
}
}
{code}
{noformat}
Found suspect string in log4j at line 4995
[error 2019/06/13 18:35:08.681 GMT
tid=62] A cache server's bind address is only available if it has been started
java.lang.IllegalStateException: A cache server's bind address is only
available if it has been started
at
org.apache.geode.internal.cache.CacheServerImpl.getExternalAddress(CacheServerImpl.java:435)
at
org.apache.geode.internal.cache.CacheServerImpl.getExternalAddress(CacheServerImpl.java:427)
at
org.apache.geode.internal.cache.BucketAdvisor.instantiateProfile(BucketAdvisor.java:1611)
at
org.apache.geode.distributed.internal.DistributionAdvisor.createProfile(DistributionAdvisor.java:1008)
at
org.apache.geode.internal.cache.BucketAdvisor.sendProfileUpdate(BucketAdvisor.java:1576)
at
org.apache.geode.internal.cache.BucketAdvisor.acquiredPrimaryLock(BucketAdvisor.java:1160)
at
org.apache.geode.internal.cache.BucketAdvisor.access$300(BucketAdvisor.java:77)
at
org.apache.geode.internal.cache.BucketAdvisor$VolunteeringDelegate.doVolunteerForPrimary(BucketAdvisor.java:2471)
at
org.apache.geode.internal.cache.BucketAdvisor$VolunteeringDelegate.lambda$consumeQueue$0(BucketAdvisor.java:2680)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:959)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.doWaitingThread(ClusterDistributionManager.java:849)
at
org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5222) JMX metric exposed in an MBean
[ https://issues.apache.org/jira/browse/GEODE-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863424#comment-16863424 ] ASF subversion and git services commented on GEODE-5222: Commit a806801cd639294a2593673a10e0487965c9dd23 in geode's branch refs/heads/develop from Alberto Bustamante Reyes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a806801 ] GEODE-5222: DiskStore usage percentage in JMX (#3631) * Remove explicit dir size in tests when default has to be used * Calculate percentage with two decimals > JMX metric exposed in an MBean > -- > > Key: GEODE-5222 > URL: https://issues.apache.org/jira/browse/GEODE-5222 > Project: Geode > Issue Type: Improvement > Components: docs, persistence >Reporter: Nick Vallely >Assignee: Alberto Bustamante Reyes >Priority: Major > Time Spent: 3h 20m > Remaining Estimate: 0h > > Given I need to scale down or scale up my servers based on usage > When I setup my monitoring of JMX metrics through an MBean > Then I have the ability to see Disk Free Percentage > AND Disk Free in Bytes > AND Disk Used Percentage > AND Disk Used in Bytes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6859) Destroying a parallel gateway sender attached to a region causes other senders attached to that same region to no longer queue events
[
https://issues.apache.org/jira/browse/GEODE-6859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863350#comment-16863350
]
Barry Oglesby commented on GEODE-6859:
--
Here is some additional logging showing the behavior:
The shadow PR for GatewaySender mysender is created:
{noformat}
[warn 2019/06/13 10:24:36.546 PDT tid=0x3a] XXX
ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR
senderId=mysender; userPR=/test
[warn 2019/06/13 10:24:36.546 PDT tid=0x3a] XXX
ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR
senderId=mysender; prQName=mysender_PARALLEL_GATEWAY_SENDER_QUEUE; prQ=null
[warn 2019/06/13 10:24:36.597 PDT tid=0x3a] XXX
ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR created queue
senderId=mysender; prQName=mysender_PARALLEL_GATEWAY_SENDER_QUEUE;
prQ=Partitioned Region @7951061f
[path='/mysender_PARALLEL_GATEWAY_SENDER_QUEUE'; dataPolicy=PARTITION; prId=2;
isDestroyed=false; isClosed=false; retryTimeout=360; serialNumber=125;
partition
attributes=PartitionAttributes@639507262[redundantCopies=0;localMaxMemory=100;totalMaxMemory=2147483647;totalNumBuckets=113;partitionResolver=null;colocatedWith=/test;recoveryDelay=-1;startupRecoveryDelay=0;FixedPartitionAttributes=null;partitionListeners=null];
on VM 192.168.1.2(server:4637):41001]
{noformat}
The shadow PR for GatewaySender mysender2 is created:
{noformat}
[warn 2019/06/13 10:24:43.064 PDT tid=0x3a] XXX
ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR
senderId=mysender2; userPR=/test
[warn 2019/06/13 10:24:43.064 PDT tid=0x3a] XXX
ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR
senderId=mysender2; prQName=mysender2_PARALLEL_GATEWAY_SENDER_QUEUE; prQ=null
[warn 2019/06/13 10:24:43.069 PDT tid=0x3a] XXX
ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR created queue
senderId=mysender2; prQName=mysender2_PARALLEL_GATEWAY_SENDER_QUEUE;
prQ=Partitioned Region @1c5b3979
[path='/mysender2_PARALLEL_GATEWAY_SENDER_QUEUE'; dataPolicy=PARTITION; prId=3;
isDestroyed=false; isClosed=false; retryTimeout=360; serialNumber=466;
partition
attributes=PartitionAttributes@635010394[redundantCopies=0;localMaxMemory=100;totalMaxMemory=2147483647;totalNumBuckets=113;partitionResolver=null;colocatedWith=/test;recoveryDelay=-1;startupRecoveryDelay=0;FixedPartitionAttributes=null;partitionListeners=null];
on VM 192.168.1.2(server:4637):41001]
{noformat}
GatewaySender mysender is destroyed:
{noformat}
[warn 2019/06/13 10:24:43.889 PDT tid=0x3a] XXX
AbstractGatewaySender.destroy region=/mysender_PARALLEL_GATEWAY_SENDER_QUEUE
[warn 2019/06/13 10:24:43.889 PDT tid=0x3a] XXX
PartitionedRegion.destroyRegion region=/mysender_PARALLEL_GATEWAY_SENDER_QUEUE
{noformat}
That causes PartitionedRegionDataStore.cleanUp to set shadowBucketDestroyed to
true for all the buckets of the test region:
{noformat}
[warn 2019/06/13 10:24:43.890 PDT tid=0x3a] XXX
PartitionedRegionDataStore.cleanUp
region=/mysender_PARALLEL_GATEWAY_SENDER_QUEUE
[warn 2019/06/13 10:24:43.895 PDT tid=0x3a] XXX
BucketAdvisor.setShadowBucketDestroyed region=/test; bucket=0; destroyed=true
[warn 2019/06/13 10:24:43.896 PDT tid=0x3a] XXX
BucketAdvisor.setShadowBucketDestroyed region=/test; bucket=1; destroyed=true
[warn 2019/06/13 10:24:43.897 PDT tid=0x3a] XXX
BucketAdvisor.setShadowBucketDestroyed region=/test; bucket=2; destroyed=true
[warn 2019/06/13 10:24:43.898 PDT tid=0x3a] XXX
BucketAdvisor.setShadowBucketDestroyed region=/test; bucket=3; destroyed=true
[warn 2019/06/13 10:24:43.899 PDT tid=0x3a] XXX
BucketAdvisor.setShadowBucketDestroyed region=/test; bucket=4; destroyed=true
[warn 2019/06/13 10:24:43.899 PDT tid=0x3a] ...
[warn 2019/06/13 10:24:43.942 PDT tid=0x3a] XXX
BucketAdvisor.setShadowBucketDestroyed region=/test; bucket=51; destroyed=true
[warn 2019/06/13 10:24:43.942 PDT tid=0x3a] ...
[warn 2019/06/13 10:24:43.959 PDT tid=0x3a] XXX
PartitionedRegionDataStore.cleanUp complete
region=/mysender_PARALLEL_GATEWAY_SENDER_QUEUE
{noformat}
The put is delivered to the ParallelGatewaySenderQueue, but
shadowBucketDestroyed is true from the cleanUp above so the put is dropped:
{noformat}
[warn 2019/06/13 10:24:44.011 PDT tid=0x3a] XXX
ParallelGatewaySenderQueue.put
brq=/__PR/_B__mysender2__PARALLEL__GATEWAY__SENDER__QUEUE_51
[warn 2019/06/13 10:24:44.012 PDT tid=0x3a] XXX
ParallelGatewaySenderQueue.put
brq=/__PR/_B__mysender2__PARALLEL__GATEWAY__SENDER__QUEUE_51;
shadowBucketDestroyed=true
[warn 2019/06/13 10:24:44.012 PDT tid=0x3a] XXX
ParallelGatewaySenderQueue.put not putting entry into queue as shadowPR bucket
is destroyed: key=164; value=GatewaySenderEventImpl[id=EventID[id=24
bytes;threadID=0x1010033|1;sequenceID=122;bucketId=51];action=0;operation=CREATE;region=/test;key=3;value=3;valueIsObject=1;numberOfParts=9;callbackArgument=GatewaySenderEventCallbackArgument
[jira] [Assigned] (GEODE-6862) Fail dunit suspect string check if log output contains {}
[
https://issues.apache.org/jira/browse/GEODE-6862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reassigned GEODE-6862:
Assignee: Kirk Lund
> Fail dunit suspect string check if log output contains {}
> -
>
> Key: GEODE-6862
> URL: https://issues.apache.org/jira/browse/GEODE-6862
> Project: Geode
> Issue Type: Wish
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> I propose adding `{}` to the dunit suspect string check. The presence of `{}`
> probably indicates a malformed Log4J log statement is missing one or more
> parameters.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6862) Fail dunit suspect string check if log output contains {}
Kirk Lund created GEODE-6862:
Summary: Fail dunit suspect string check if log output contains {}
Key: GEODE-6862
URL: https://issues.apache.org/jira/browse/GEODE-6862
Project: Geode
Issue Type: Wish
Components: tests
Reporter: Kirk Lund
I propose adding `{}` to the dunit suspect string check. The presence of `{}`
probably indicates a malformed Log4J log statement is missing one or more
parameters.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6856) Remove deprecated CacheServerLauncher and its test
[ https://issues.apache.org/jira/browse/GEODE-6856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-6856: Assignee: Kirk Lund > Remove deprecated CacheServerLauncher and its test > -- > > Key: GEODE-6856 > URL: https://issues.apache.org/jira/browse/GEODE-6856 > Project: Geode > Issue Type: Wish > Components: core >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Since CacheServerLauncher is an internal class, we should remove it and its > test: > * org.apache.geode.internal.cache.CacheServerLauncher > * org.apache.geode.internal.cache.DeprecatedCacheServerLauncherIntegrationTest > CacheServerLauncher historical info: > * introduced in GemFire 2.0.2 > * was deprecated in GemFire 7.0.0 > * was used by an old `cacheserver` script that has never existed in Geode > There should be no users actually using this internal class so it should be > safe to delete. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6856) Remove deprecated CacheServerLauncher and its test
[ https://issues.apache.org/jira/browse/GEODE-6856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund resolved GEODE-6856. -- Resolution: Fixed Fix Version/s: 1.10.0 > Remove deprecated CacheServerLauncher and its test > -- > > Key: GEODE-6856 > URL: https://issues.apache.org/jira/browse/GEODE-6856 > Project: Geode > Issue Type: Wish > Components: core >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Since CacheServerLauncher is an internal class, we should remove it and its > test: > * org.apache.geode.internal.cache.CacheServerLauncher > * org.apache.geode.internal.cache.DeprecatedCacheServerLauncherIntegrationTest > CacheServerLauncher historical info: > * introduced in GemFire 2.0.2 > * was deprecated in GemFire 7.0.0 > * was used by an old `cacheserver` script that has never existed in Geode > There should be no users actually using this internal class so it should be > safe to delete. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6183) CI Failure: LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed with ConditionTimeoutException
[ https://issues.apache.org/jira/browse/GEODE-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863313#comment-16863313 ] ASF subversion and git services commented on GEODE-6183: Commit 87c83ee4e2e6214bf2dd65d279520c8d437c56ee in geode's branch refs/heads/develop from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=87c83ee ] GEODE-6183: Cleanup and rename LocatorIntegrationTest * Fixup IDE warnings * Reformat test code * Update to use AssertJ > CI Failure: > LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed > with ConditionTimeoutException > > > Key: GEODE-6183 > URL: https://issues.apache.org/jira/browse/GEODE-6183 > Project: Geode > Issue Type: Bug > Components: ci, gfsh >Reporter: Eric Shu >Assignee: Kirk Lund >Priority: Major > Time Spent: 5.5h > Remaining Estimate: 0h > > Test failed in > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/223 > org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest > > startDeletesStaleControlFiles FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase that > uses org.apache.geode.distributed.LocatorLauncher expected:<[online]> but > was:<[not responding]> within 300 seconds. > Caused by: > org.junit.ComparisonFailure: expected:<[online]> but was:<[not > responding]> -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6183) CI Failure: LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed with ConditionTimeoutException
[ https://issues.apache.org/jira/browse/GEODE-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863311#comment-16863311 ] ASF subversion and git services commented on GEODE-6183: Commit de19a41571476ecb179c2e561d1f5d6bc8b1c1b5 in geode's branch refs/heads/develop from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=de19a41 ] GEODE-6183: Cleanup Launcher integration tests * Fixup IDE warnings * Reformat test code * Use SocketCreator.getLocalHost > CI Failure: > LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed > with ConditionTimeoutException > > > Key: GEODE-6183 > URL: https://issues.apache.org/jira/browse/GEODE-6183 > Project: Geode > Issue Type: Bug > Components: ci, gfsh >Reporter: Eric Shu >Assignee: Kirk Lund >Priority: Major > Time Spent: 5.5h > Remaining Estimate: 0h > > Test failed in > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/223 > org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest > > startDeletesStaleControlFiles FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase that > uses org.apache.geode.distributed.LocatorLauncher expected:<[online]> but > was:<[not responding]> within 300 seconds. > Caused by: > org.junit.ComparisonFailure: expected:<[online]> but was:<[not > responding]> -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6183) CI Failure: LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed with ConditionTimeoutException
[ https://issues.apache.org/jira/browse/GEODE-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863309#comment-16863309 ] ASF subversion and git services commented on GEODE-6183: Commit f074ca72ae9a8e76066c3ccd7ba74499ceec1743 in geode's branch refs/heads/develop from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f074ca7 ] GEODE-6183: Make isAttachAPIFound load providers VirtualMachine class can be loaded even if AttachProvider service providers are not found. This change forces loading of providers for isAttachAPIFound. Co-authored-by: Michael Oleske > CI Failure: > LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed > with ConditionTimeoutException > > > Key: GEODE-6183 > URL: https://issues.apache.org/jira/browse/GEODE-6183 > Project: Geode > Issue Type: Bug > Components: ci, gfsh >Reporter: Eric Shu >Assignee: Kirk Lund >Priority: Major > Time Spent: 5.5h > Remaining Estimate: 0h > > Test failed in > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/223 > org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest > > startDeletesStaleControlFiles FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase that > uses org.apache.geode.distributed.LocatorLauncher expected:<[online]> but > was:<[not responding]> within 300 seconds. > Caused by: > org.junit.ComparisonFailure: expected:<[online]> but was:<[not > responding]> -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6183) CI Failure: LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed with ConditionTimeoutException
[ https://issues.apache.org/jira/browse/GEODE-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863310#comment-16863310 ] ASF subversion and git services commented on GEODE-6183: Commit 03f8395e17dd24606c79a88ede2b5ff430be0f1e in geode's branch refs/heads/develop from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=03f8395 ] GEODE-6183: Use SocketCreator.getLocalHost in LocatorLauncherRemoteIntegrationTest The tests that were using InetAddress.getLostHost for assertions may fail depending on /etc/hosts configuration. This change should prevent these failures. Co-authored-by: Michael Oleske Co-authored-by: Mark Hanson > CI Failure: > LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed > with ConditionTimeoutException > > > Key: GEODE-6183 > URL: https://issues.apache.org/jira/browse/GEODE-6183 > Project: Geode > Issue Type: Bug > Components: ci, gfsh >Reporter: Eric Shu >Assignee: Kirk Lund >Priority: Major > Time Spent: 5.5h > Remaining Estimate: 0h > > Test failed in > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/223 > org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest > > startDeletesStaleControlFiles FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase that > uses org.apache.geode.distributed.LocatorLauncher expected:<[online]> but > was:<[not responding]> within 300 seconds. > Caused by: > org.junit.ComparisonFailure: expected:<[online]> but was:<[not > responding]> -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6183) CI Failure: LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed with ConditionTimeoutException
[ https://issues.apache.org/jira/browse/GEODE-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863312#comment-16863312 ] ASF subversion and git services commented on GEODE-6183: Commit c6f0b1a5b563d54f3bfd5d9c6f2588be8409ceec in geode's branch refs/heads/develop from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c6f0b1a ] GEODE-6183: Cleanup and rename DistributedSystemIntegrationTest * Fixup IDE warnings * Reformat test code > CI Failure: > LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed > with ConditionTimeoutException > > > Key: GEODE-6183 > URL: https://issues.apache.org/jira/browse/GEODE-6183 > Project: Geode > Issue Type: Bug > Components: ci, gfsh >Reporter: Eric Shu >Assignee: Kirk Lund >Priority: Major > Time Spent: 5.5h > Remaining Estimate: 0h > > Test failed in > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/223 > org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest > > startDeletesStaleControlFiles FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase that > uses org.apache.geode.distributed.LocatorLauncher expected:<[online]> but > was:<[not responding]> within 300 seconds. > Caused by: > org.junit.ComparisonFailure: expected:<[online]> but was:<[not > responding]> -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6856) Remove deprecated CacheServerLauncher and its test
[ https://issues.apache.org/jira/browse/GEODE-6856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863297#comment-16863297 ] ASF subversion and git services commented on GEODE-6856: Commit a930ee4fe33f6f2f52090abea1a39fd8aa15841d in geode's branch refs/heads/develop from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a930ee4 ] GEODE-6856: Remove old CacheServerLauncher Removes these classes and tests: * CacheServerLauncher * CacheServerLauncherJUnitTest * DeprecatedCacheServerLauncherIntegrationTest > Remove deprecated CacheServerLauncher and its test > -- > > Key: GEODE-6856 > URL: https://issues.apache.org/jira/browse/GEODE-6856 > Project: Geode > Issue Type: Wish > Components: core >Reporter: Kirk Lund >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Since CacheServerLauncher is an internal class, we should remove it and its > test: > * org.apache.geode.internal.cache.CacheServerLauncher > * org.apache.geode.internal.cache.DeprecatedCacheServerLauncherIntegrationTest > CacheServerLauncher historical info: > * introduced in GemFire 2.0.2 > * was deprecated in GemFire 7.0.0 > * was used by an old `cacheserver` script that has never existed in Geode > There should be no users actually using this internal class so it should be > safe to delete. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6854) GatewaySender batch conflation can incorrectly conflate events causing out of order processing
[
https://issues.apache.org/jira/browse/GEODE-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863285#comment-16863285
]
ASF subversion and git services commented on GEODE-6854:
Commit 9ec425a0449379a3dfd8851ed2319bb044513ca2 in geode's branch
refs/heads/feature/GEODE-6854 from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9ec425a ]
GEODE-6854: Cleanup based on review comments
> GatewaySender batch conflation can incorrectly conflate events causing out of
> order processing
> --
>
> Key: GEODE-6854
> URL: https://issues.apache.org/jira/browse/GEODE-6854
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>Priority: Major
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> If a batch contains 2 equal update events,
> {{AbstractGatewaySenderEventProcessor conflate}} will remove the original
> event and add the later event at the end of the list. Depending on the other
> events in the list, this could cause the batch to contain events that are out
> of order.
> For example, in this batch containing 6 events before conflation, the last
> two events are duplicates of earlier events:
> {noformat}
> SenderEventImpl[id=EventID[threadID=0x10059|104;sequenceID=2;bucketId=89];action=1;operation=UPDATE;region=/dataStoreRegion;key=Object_6079;shadowKey=16587]
> SenderEventImpl[id=EventID[threadID=0x10059|104;sequenceID=3;bucketId=89];action=2;operation=DESTROY;region=/dataStoreRegion;key=Object_6079;shadowKey=16700]
> SenderEventImpl[id=EventID[threadID=0x10059|112;sequenceID=9;bucketId=89];action=1;operation=PUTALL_UPDATE;region=/dataStoreRegion;key=Object_7731;shadowKey=16813]
> SenderEventImpl[id=EventID[threadID=0x10059|112;sequenceID=12;bucketId=89];action=1;operation=PUTALL_UPDATE;region=/dataStoreRegion;key=Object_6591;shadowKey=16926]
> SenderEventImpl[id=EventID[threadID=0x10059|104;sequenceID=3;bucketId=89];action=2;operation=DESTROY;region=/dataStoreRegion;key=Object_6079;shadowKey=16700]
> SenderEventImpl[id=EventID[threadID=0x10059|112;sequenceID=9;bucketId=89];action=1;operation=PUTALL_UPDATE;region=/dataStoreRegion;key=Object_7731;shadowKey=16813]
> {noformat}
> Conflating this batch results in these 4 events:
> {noformat}
> SenderEventImpl[id=EventID[threadID=0x10059|104;sequenceID=2;bucketId=89];action=1;operation=UPDATE;region=/dataStoreRegion;key=Object_6079;shadowKey=16587]
> SenderEventImpl[id=EventID[threadID=0x10059|104;sequenceID=3;bucketId=89];action=2;operation=DESTROY;region=/dataStoreRegion;key=Object_6079;shadowKey=16700]
> SenderEventImpl[id=EventID[threadID=0x10059|112;sequenceID=12;bucketId=89];action=1;operation=PUTALL_UPDATE;region=/dataStoreRegion;key=Object_6591;shadowKey=16926]
> SenderEventImpl[id=EventID[threadID=0x10059|112;sequenceID=9;bucketId=89];action=1;operation=PUTALL_UPDATE;region=/dataStoreRegion;key=Object_7731;shadowKey=16813]
> {noformat}
> Notice the shadowKeys and sequenceIds are out of order after the conflation.
> Conflation should produce this batch:
> {noformat}
> SenderEventImpl[id=EventID[threadID=0x10059|104;sequenceID=2;bucketId=89];action=1;operation=UPDATE;region=/dataStoreRegion;key=Object_6079;shadowKey=16587]
> SenderEventImpl[id=EventID[threadID=0x10059|104;sequenceID=3;bucketId=89];action=2;operation=DESTROY;region=/dataStoreRegion;key=Object_6079;shadowKey=16700]
> SenderEventImpl[id=EventID[threadID=0x10059|112;sequenceID=9;bucketId=89];action=1;operation=PUTALL_UPDATE;region=/dataStoreRegion;key=Object_7731;shadowKey=16813]
> SenderEventImpl[id=EventID[threadID=0x10059|112;sequenceID=12;bucketId=89];action=1;operation=PUTALL_UPDATE;region=/dataStoreRegion;key=Object_6591;shadowKey=16926]
> {noformat}
> This is similar to GEODE-4704, but not exactly the same.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6306) Have the CreateRegionCommand call the internal Cluster Management service API to create the region with all the options
[ https://issues.apache.org/jira/browse/GEODE-6306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863276#comment-16863276 ] ASF subversion and git services commented on GEODE-6306: Commit 992790176950586341999d4a720239f57d070b72 in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9927901 ] GEODE-6306: add capability to check cache element compatibility (#3695) > Have the CreateRegionCommand call the internal Cluster Management service API > to create the region with all the options > --- > > Key: GEODE-6306 > URL: https://issues.apache.org/jira/browse/GEODE-6306 > Project: Geode > Issue Type: Improvement > Components: configuration, gfsh >Reporter: Jinmei Liao >Priority: Major > Labels: pull-request-available > Time Spent: 1h 50m > Remaining Estimate: 0h > > Currently the CreateRegionCommand handles all options supported by gfsh, but > cluster management api createRegion call only supports name and type. We > should add more option support to the internal api and then have the > createRegionCommand directly call the api to do all the work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6855) Improve signaling for Geode Concourse consumers
[ https://issues.apache.org/jira/browse/GEODE-6855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863257#comment-16863257 ] ASF subversion and git services commented on GEODE-6855: Commit ff49622a15d74398338b72c563fbb92c5d45ed92 in geode's branch refs/heads/develop from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ff49622 ] GEODE-6855: Publish JSON that contains corresponding SHA and build id * UpdatePassingRef and UpdatePassingBuild become UpdatePassingTokens. * Create additional coupled file stored in ///passing-build-tokens*.json Authored-by: Robert Houghton > Improve signaling for Geode Concourse consumers > --- > > Key: GEODE-6855 > URL: https://issues.apache.org/jira/browse/GEODE-6855 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Robert Houghton >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > I would like a way to find the corresponding the `passing-ref` and > `passing-build` resources at the end of a Concourse pipeline. The parameters > for when a pipeline emits these resources is also confusing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6652) Change in checks for next dir in disk store
[
https://issues.apache.org/jira/browse/GEODE-6652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Bustamante Reyes updated GEODE-6652:
Summary: Change in checks for next dir in disk store (was: Disk store not
detecting full directories)
> Change in checks for next dir in disk store
> ---
>
> Key: GEODE-6652
> URL: https://issues.apache.org/jira/browse/GEODE-6652
> Project: Geode
> Issue Type: Bug
> Components: core, persistence
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
>
> Hi,
> As a summary, the issue is that when using a disk store with directories of
> different sizes, when oplog files rotate, the available space of the next
> disk store directory to be used seems not to be checked correctly.
>
> I did a test where I have a persistent region, and a disk store composed by
> three directories with different sizes.
> {code:java}
> gfsh> start locator --name=locator --bind-address=127.0.0.1
> gfsh> start server --name=server1 --locators=127.0.0.1[10334] --server-port=0
> --J=-Dgemfire.statistic-sampling-enabled=true
> --statistic-archive-file=stats.gfs --enable-time-statistics=true
> gfsh> create disk-store
> --dir=./store1/dir1#20,./store1/dir2#10,./store1/dir3#5 --name=store1
> --max-oplog-size=1
> gfsh> create region --name=store1-region --type=REPLICATE_PERSISTENT
> --disk-store=store1
> {code}
> Then, I started populating the region. I could see how the files in the
> directories are rotating (BACKUPstore1_1 in dir1, BACKUPstore1_2 in dir2,
> BACKUPstore1_3 in dir3, BACKUPstore1_4 in dir1, etc...) , but there is a
> moment when the smallest directory is not able to fit more files. This
> situation is not detected when the files are created, and the server crashes.
> {code:java}
> org.apache.geode.cache.client.ServerOperationException: remote server on
> bovis-z1020-172-17-0-1(23072:loner):49804:c1233620: : While performing a
> remote put
> at
> org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processAck(PutOp.java:384)
> at
> org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processResponse(PutOp.java:308)
> at
> org.apache.geode.cache.client.internal.PutOp$PutOpImpl.attemptReadResponse(PutOp.java:449)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:386)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:274)
> at
> org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:325)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:892)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:171)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:128)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:758)
> at org.apache.geode.cache.client.internal.PutOp.execute(PutOp.java:89)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.put(ServerRegionProxy.java:152)
> at
> org.apache.geode.internal.cache.LocalRegion.serverPut(LocalRegion.java:3032)
> at
> org.apache.geode.internal.cache.LocalRegion.cacheWriteBeforePut(LocalRegion.java:3144)
> at
> org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:238)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5664)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:152)
> at
> org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5090)
> at
> org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1635)
> at
> org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1622)
> at
> org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:419)
> at
> org.apache.geode_examples.statistics.Example.insertValues(Example.java:81)
> at org.apache.geode_examples.statistics.Example.main(Example.java:49)
> Caused by: org.apache.geode.cache.DiskAccessException: For DiskStore: store1:
> Could not pre-allocate file
> /home/alb3rtobr/git/geode-examples/statistics/server1/./store1/dir3/BACKUPstore1_18.crf
> with size=943718, caused by java.io.IOException: not enough space left to
> pre-blow, available=523879, required=943718
> at org.apache.geode.internal.cache.Oplog.preblow(Oplog.java:1044)
> at org.apache.geode.internal.cache.Oplog.createCrf(Oplog.java:1072)
> at org.apache.geode.internal.cache.Oplog.(Oplog.java:645)
> at
[jira] [Created] (GEODE-6861) generify ClusterManagementService APIs
Owen Nichols created GEODE-6861: --- Summary: generify ClusterManagementService APIs Key: GEODE-6861 URL: https://issues.apache.org/jira/browse/GEODE-6861 Project: Geode Issue Type: Improvement Components: management Reporter: Owen Nichols currently CMS calls like `list(CacheElement)` return `` which then has to be cast to the appropriate actual type. if we create a link between the filter type and result type, then generics can be used to give the correct actual return type in all cases, and we can get rid of a ton of warnings and sketchy workarounds like passing `class` parameters to methods that shouldn't need them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
