[jira] [Commented] (GEODE-8292) CQs do not send back the right CREATE event but a UPDATE event once entry updated
[ https://issues.apache.org/jira/browse/GEODE-8292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173057#comment-17173057 ] ASF subversion and git services commented on GEODE-8292: Commit 2b86f66a6e2c741e9a825a4d8185d84d53c9fdee in geode's branch refs/heads/develop from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2b86f66 ] GEODE-8292: Added check if key is destroyed in CQResults (#5426) > CQs do not send back the right CREATE event but a UPDATE event once entry > updated > - > > Key: GEODE-8292 > URL: https://issues.apache.org/jira/browse/GEODE-8292 > Project: Geode > Issue Type: Bug > Components: cq >Reporter: Mario Kevo >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > When CQs are installed at Geode server, they dynamically analyzes incoming > updates/creates or deletion entries in the region. > If we have CQ something like "select * from /region i where i=1" and put some > values with i=0, and after that we change it to 1 and again to 0 several > times we got on listener some CREATE and some UPDATE when it fulfilling cq > condition. > The issue can be easily reproduced by geode-examples by modifying > geode-examples/cq/src/main/java/org/apache/geode_examples/cq/Example.java to > put some entries with transactions and then update it. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8292) CQs do not send back the right CREATE event but a UPDATE event once entry updated
[ https://issues.apache.org/jira/browse/GEODE-8292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173056#comment-17173056 ] ASF GitHub Bot commented on GEODE-8292: --- mivanac merged pull request #5426: URL: https://github.com/apache/geode/pull/5426 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > CQs do not send back the right CREATE event but a UPDATE event once entry > updated > - > > Key: GEODE-8292 > URL: https://issues.apache.org/jira/browse/GEODE-8292 > Project: Geode > Issue Type: Bug > Components: cq >Reporter: Mario Kevo >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > When CQs are installed at Geode server, they dynamically analyzes incoming > updates/creates or deletion entries in the region. > If we have CQ something like "select * from /region i where i=1" and put some > values with i=0, and after that we change it to 1 and again to 0 several > times we got on listener some CREATE and some UPDATE when it fulfilling cq > condition. > The issue can be easily reproduced by geode-examples by modifying > geode-examples/cq/src/main/java/org/apache/geode_examples/cq/Example.java to > put some entries with transactions and then update it. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8292) CQs do not send back the right CREATE event but a UPDATE event once entry updated
[ https://issues.apache.org/jira/browse/GEODE-8292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac resolved GEODE-8292. - Resolution: Fixed > CQs do not send back the right CREATE event but a UPDATE event once entry > updated > - > > Key: GEODE-8292 > URL: https://issues.apache.org/jira/browse/GEODE-8292 > Project: Geode > Issue Type: Bug > Components: cq >Reporter: Mario Kevo >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > When CQs are installed at Geode server, they dynamically analyzes incoming > updates/creates or deletion entries in the region. > If we have CQ something like "select * from /region i where i=1" and put some > values with i=0, and after that we change it to 1 and again to 0 several > times we got on listener some CREATE and some UPDATE when it fulfilling cq > condition. > The issue can be easily reproduced by geode-examples by modifying > geode-examples/cq/src/main/java/org/apache/geode_examples/cq/Example.java to > put some entries with transactions and then update it. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8191) MemberMXBeanDistributedTest.testBucketCount fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173092#comment-17173092
]
ASF GitHub Bot commented on GEODE-8191:
---
mivanac closed pull request #5227:
URL: https://github.com/apache/geode/pull/5227
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> MemberMXBeanDistributedTest.testBucketCount fails intermittently
>
>
> Key: GEODE-8191
> URL: https://issues.apache.org/jira/browse/GEODE-8191
> Project: Geode
> Issue Type: Bug
> Components: jmx, tests
>Reporter: Kirk Lund
>Assignee: Mario Ivanac
>Priority: Major
> Labels: flaky, pull-request-available
>
> This appears to be a flaky test related to GEODE-7963 which was resolved by
> Mario Ivanac so I've assigned the ticket to him.
> {noformat}
> org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount
> FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.MemberMXBeanDistributedTest Expected bucket count
> is 4000, and actual count is 3750 expected:<3750> but was:<4000> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:102)
> Caused by:
> java.lang.AssertionError: Expected bucket count is 4000, and actual
> count is 3750 expected:<3750> but was:<4000>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.lambda$testBucketCount$1(MemberMXBeanDistributedTest.java:107)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8191) MemberMXBeanDistributedTest.testBucketCount fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173110#comment-17173110
]
ASF GitHub Bot commented on GEODE-8191:
---
mivanac commented on pull request #5227:
URL: https://github.com/apache/geode/pull/5227#issuecomment-670492076
Since there is no reply on this PR, I will close it.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> MemberMXBeanDistributedTest.testBucketCount fails intermittently
>
>
> Key: GEODE-8191
> URL: https://issues.apache.org/jira/browse/GEODE-8191
> Project: Geode
> Issue Type: Bug
> Components: jmx, tests
>Reporter: Kirk Lund
>Assignee: Mario Ivanac
>Priority: Major
> Labels: flaky, pull-request-available
>
> This appears to be a flaky test related to GEODE-7963 which was resolved by
> Mario Ivanac so I've assigned the ticket to him.
> {noformat}
> org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount
> FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.MemberMXBeanDistributedTest Expected bucket count
> is 4000, and actual count is 3750 expected:<3750> but was:<4000> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:102)
> Caused by:
> java.lang.AssertionError: Expected bucket count is 4000, and actual
> count is 3750 expected:<3750> but was:<4000>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.lambda$testBucketCount$1(MemberMXBeanDistributedTest.java:107)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8191) MemberMXBeanDistributedTest.testBucketCount fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173125#comment-17173125
]
ASF GitHub Bot commented on GEODE-8191:
---
jujoramos commented on pull request #5227:
URL: https://github.com/apache/geode/pull/5227#issuecomment-670504376
Hello @mivanac ,
Just for the record, I've been actively reviewing this `PR` since it was
opened but I don't think the fix is sufficient to fix the flakiness, that's why
I requested changes on `15/06/2020`; there wasn't any response from your side
afterwards.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> MemberMXBeanDistributedTest.testBucketCount fails intermittently
>
>
> Key: GEODE-8191
> URL: https://issues.apache.org/jira/browse/GEODE-8191
> Project: Geode
> Issue Type: Bug
> Components: jmx, tests
>Reporter: Kirk Lund
>Assignee: Mario Ivanac
>Priority: Major
> Labels: flaky, pull-request-available
>
> This appears to be a flaky test related to GEODE-7963 which was resolved by
> Mario Ivanac so I've assigned the ticket to him.
> {noformat}
> org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount
> FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.MemberMXBeanDistributedTest Expected bucket count
> is 4000, and actual count is 3750 expected:<3750> but was:<4000> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:102)
> Caused by:
> java.lang.AssertionError: Expected bucket count is 4000, and actual
> count is 3750 expected:<3750> but was:<4000>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.lambda$testBucketCount$1(MemberMXBeanDistributedTest.java:107)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8191) MemberMXBeanDistributedTest.testBucketCount fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173129#comment-17173129
]
ASF GitHub Bot commented on GEODE-8191:
---
mivanac commented on pull request #5227:
URL: https://github.com/apache/geode/pull/5227#issuecomment-670507310
Just for record, If you look at last commit, you can see that your requst
(to force the bucket creation) is fullfilled.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> MemberMXBeanDistributedTest.testBucketCount fails intermittently
>
>
> Key: GEODE-8191
> URL: https://issues.apache.org/jira/browse/GEODE-8191
> Project: Geode
> Issue Type: Bug
> Components: jmx, tests
>Reporter: Kirk Lund
>Assignee: Mario Ivanac
>Priority: Major
> Labels: flaky, pull-request-available
>
> This appears to be a flaky test related to GEODE-7963 which was resolved by
> Mario Ivanac so I've assigned the ticket to him.
> {noformat}
> org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount
> FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.MemberMXBeanDistributedTest Expected bucket count
> is 4000, and actual count is 3750 expected:<3750> but was:<4000> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:102)
> Caused by:
> java.lang.AssertionError: Expected bucket count is 4000, and actual
> count is 3750 expected:<3750> but was:<4000>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.lambda$testBucketCount$1(MemberMXBeanDistributedTest.java:107)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8191) MemberMXBeanDistributedTest.testBucketCount fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173136#comment-17173136
]
ASF GitHub Bot commented on GEODE-8191:
---
jujoramos commented on pull request #5227:
URL: https://github.com/apache/geode/pull/5227#issuecomment-670514196
Dang!, somehow I totally missed that notification and there wasn't any new
comments on the `PR` (other than the one from Owen) so I didn't get any
specific email addressed to myself (hard to keep track of old `PRs` when there
are so many emails coming and going), sorry about that!.
I can have a look at the `PR` if you re-open it 👍
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> MemberMXBeanDistributedTest.testBucketCount fails intermittently
>
>
> Key: GEODE-8191
> URL: https://issues.apache.org/jira/browse/GEODE-8191
> Project: Geode
> Issue Type: Bug
> Components: jmx, tests
>Reporter: Kirk Lund
>Assignee: Mario Ivanac
>Priority: Major
> Labels: flaky, pull-request-available
>
> This appears to be a flaky test related to GEODE-7963 which was resolved by
> Mario Ivanac so I've assigned the ticket to him.
> {noformat}
> org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount
> FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.MemberMXBeanDistributedTest Expected bucket count
> is 4000, and actual count is 3750 expected:<3750> but was:<4000> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:102)
> Caused by:
> java.lang.AssertionError: Expected bucket count is 4000, and actual
> count is 3750 expected:<3750> but was:<4000>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.lambda$testBucketCount$1(MemberMXBeanDistributedTest.java:107)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8396) NullPointerException occurs in create jdbc-mapping command
[
https://issues.apache.org/jira/browse/GEODE-8396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173167#comment-17173167
]
ASF GitHub Bot commented on GEODE-8396:
---
masaki-yamakawa commented on pull request #5418:
URL: https://github.com/apache/geode/pull/5418#issuecomment-670544653
@DonalEvans Thanks for the review.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> NullPointerException occurs in create jdbc-mapping command
> --
>
> Key: GEODE-8396
> URL: https://issues.apache.org/jira/browse/GEODE-8396
> Project: Geode
> Issue Type: Bug
> Components: jdbc
>Reporter: Masaki Yamakawa
>Priority: Minor
> Labels: pull-request-available
>
> NullPointerException occurs in create jdbc-mapping command when partitioned
> region is specified by refid of cache.xml (cluster.xml).
> The cluster.xml and gfsh command are as follows:
> cluster.xml
> {code:java}
>
>
> {code}
> gfsh
> {code:java}
> gfsh start locator --name=ExampleLocator --enable-cluster-configuration=true
> gfsh start server --name=ExampleServer --locators=ExampleLocator[10334]
> --use-cluster-configuration=true
> create data-source --name=ExampleDataSource
> --url=jdbc:mysql://mariadb/geode_db --username=geode_user --if-not-exists=true
> create jdbc-mapping --data-source=ExampleDataSource --region=ExampleRegion
> --catalog=geode_db --table=ExampleRegion --pdx-name=com.example.Example
> --synchronous=false{code}
> The cause is that
> `org.apache.geode.connectors.jdbc.internal.cli.CreateMappingCommand#createAsyncQueue`
> refers to the DataPolicy, but when using cluster.xml is not set.
> * In case of create region command, both refid and data-policy are set.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8413) CI failure: MergeLogFilesIntegrationTest.testDircountZero failes on Windows
Bruce J Schuchardt created GEODE-8413:
-
Summary: CI failure: MergeLogFilesIntegrationTest.testDircountZero
failes on Windows
Key: GEODE-8413
URL: https://issues.apache.org/jira/browse/GEODE-8413
Project: Geode
Issue Type: Bug
Reporter: Bruce J Schuchardt
{noformat}
org.apache.geode.internal.logging.MergeLogFilesIntegrationTest >
testDircountZero FAILED
06:43:07java.io.FileNotFoundException:
C:\Users\geode\geode\geode-core\build\resources\integrationTest\org\apache\geode\internal\logging\dir1%5csystemlog.txt
(The system cannot find the file specified)
06:43:07at java.io.FileInputStream.open0(Native Method)
06:43:07at java.io.FileInputStream.open(FileInputStream.java:195)
06:43:07at java.io.FileInputStream.(FileInputStream.java:138)
06:43:07at
org.apache.geode.internal.logging.MergeLogFiles.getStringDisplayNameAndFileStreamMap(MergeLogFiles.java:349)
06:43:07at
org.apache.geode.internal.logging.MergeLogFilesIntegrationTest.testDircountZero(MergeLogFilesIntegrationTest.java:128)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8191) MemberMXBeanDistributedTest.testBucketCount fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173229#comment-17173229
]
ASF subversion and git services commented on GEODE-8191:
Commit ae64bbb883f0b3d5a4ffc1f76e9a1f34119b409a in geode's branch
refs/heads/develop from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ae64bbb ]
GEODE-8191_1: test updated, added bucket initialization after creation of each
child region (#5432)
> MemberMXBeanDistributedTest.testBucketCount fails intermittently
>
>
> Key: GEODE-8191
> URL: https://issues.apache.org/jira/browse/GEODE-8191
> Project: Geode
> Issue Type: Bug
> Components: jmx, tests
>Reporter: Kirk Lund
>Assignee: Mario Ivanac
>Priority: Major
> Labels: flaky, pull-request-available
>
> This appears to be a flaky test related to GEODE-7963 which was resolved by
> Mario Ivanac so I've assigned the ticket to him.
> {noformat}
> org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount
> FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.MemberMXBeanDistributedTest Expected bucket count
> is 4000, and actual count is 3750 expected:<3750> but was:<4000> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:102)
> Caused by:
> java.lang.AssertionError: Expected bucket count is 4000, and actual
> count is 3750 expected:<3750> but was:<4000>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.lambda$testBucketCount$1(MemberMXBeanDistributedTest.java:107)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8413) CI failure: MergeLogFilesIntegrationTest.testDircountZero failes on Windows
[
https://issues.apache.org/jira/browse/GEODE-8413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt reassigned GEODE-8413:
-
Assignee: Bruce J Schuchardt
> CI failure: MergeLogFilesIntegrationTest.testDircountZero failes on Windows
> ---
>
> Key: GEODE-8413
> URL: https://issues.apache.org/jira/browse/GEODE-8413
> Project: Geode
> Issue Type: Bug
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
>
>
>
> {noformat}
> org.apache.geode.internal.logging.MergeLogFilesIntegrationTest >
> testDircountZero FAILED
> 06:43:07java.io.FileNotFoundException:
> C:\Users\geode\geode\geode-core\build\resources\integrationTest\org\apache\geode\internal\logging\dir1%5csystemlog.txt
> (The system cannot find the file specified)
> 06:43:07at java.io.FileInputStream.open0(Native Method)
> 06:43:07at java.io.FileInputStream.open(FileInputStream.java:195)
> 06:43:07at java.io.FileInputStream.(FileInputStream.java:138)
> 06:43:07at
> org.apache.geode.internal.logging.MergeLogFiles.getStringDisplayNameAndFileStreamMap(MergeLogFiles.java:349)
> 06:43:07at
> org.apache.geode.internal.logging.MergeLogFilesIntegrationTest.testDircountZero(MergeLogFilesIntegrationTest.java:128)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8191) MemberMXBeanDistributedTest.testBucketCount fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Ramos resolved GEODE-8191.
---
Fix Version/s: 1.14.0
Resolution: Fixed
> MemberMXBeanDistributedTest.testBucketCount fails intermittently
>
>
> Key: GEODE-8191
> URL: https://issues.apache.org/jira/browse/GEODE-8191
> Project: Geode
> Issue Type: Bug
> Components: jmx, tests
>Reporter: Kirk Lund
>Assignee: Mario Ivanac
>Priority: Major
> Labels: flaky, pull-request-available
> Fix For: 1.14.0
>
>
> This appears to be a flaky test related to GEODE-7963 which was resolved by
> Mario Ivanac so I've assigned the ticket to him.
> {noformat}
> org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount
> FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.MemberMXBeanDistributedTest Expected bucket count
> is 4000, and actual count is 3750 expected:<3750> but was:<4000> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:102)
> Caused by:
> java.lang.AssertionError: Expected bucket count is 4000, and actual
> count is 3750 expected:<3750> but was:<4000>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.lambda$testBucketCount$1(MemberMXBeanDistributedTest.java:107)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8406) enable early-return for CI only changes in Geode Concourse
[ https://issues.apache.org/jira/browse/GEODE-8406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173253#comment-17173253 ] ASF GitHub Bot commented on GEODE-8406: --- rhoughton-pivot merged pull request #5427: URL: https://github.com/apache/geode/pull/5427 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > enable early-return for CI only changes in Geode Concourse > -- > > Key: GEODE-8406 > URL: https://issues.apache.org/jira/browse/GEODE-8406 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Robert Houghton >Priority: Major > Labels: pull-request-available > > The Geode Concourse PR pipeline pulls the _ci_ scripts from upstream, not the > code under test. Ergo, CI changes are untestable by the main CI itself, and > running the PR jobs is useless, and costly. > GitHub does not allow granular control of what directories require a _status_ > to allow merging, so our solution is to short circuit the work for CI-only > PRs, allowing the status to be set. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8406) enable early-return for CI only changes in Geode Concourse
[ https://issues.apache.org/jira/browse/GEODE-8406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173255#comment-17173255 ] ASF subversion and git services commented on GEODE-8406: Commit fbcf0c6670a41c9ca255970a504fe0a27bd9fe43 in geode's branch refs/heads/develop from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=fbcf0c6 ] GEODE-8406: Enable early-return in CI scripts for CI-only changes (#5427) Creates a function that tests the code changes to be: 1) From a pull request in Geode 2) Those changes are more than ci, geode-book, geode-docs ie: code changes, not non-testable changes * it is the caller's responsibility to ensure the cwd is the Geode repo > enable early-return for CI only changes in Geode Concourse > -- > > Key: GEODE-8406 > URL: https://issues.apache.org/jira/browse/GEODE-8406 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Robert Houghton >Priority: Major > Labels: pull-request-available > > The Geode Concourse PR pipeline pulls the _ci_ scripts from upstream, not the > code under test. Ergo, CI changes are untestable by the main CI itself, and > running the PR jobs is useless, and costly. > GitHub does not allow granular control of what directories require a _status_ > to allow merging, so our solution is to short circuit the work for CI-only > PRs, allowing the status to be set. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8406) enable early-return for CI only changes in Geode Concourse
[ https://issues.apache.org/jira/browse/GEODE-8406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Houghton resolved GEODE-8406. Fix Version/s: 1.14.0 Resolution: Fixed > enable early-return for CI only changes in Geode Concourse > -- > > Key: GEODE-8406 > URL: https://issues.apache.org/jira/browse/GEODE-8406 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Robert Houghton >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > The Geode Concourse PR pipeline pulls the _ci_ scripts from upstream, not the > code under test. Ergo, CI changes are untestable by the main CI itself, and > running the PR jobs is useless, and costly. > GitHub does not allow granular control of what directories require a _status_ > to allow merging, so our solution is to short circuit the work for CI-only > PRs, allowing the status to be set. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8407) MergeLogFiles fails to include files with the same name but in different directories
[
https://issues.apache.org/jira/browse/GEODE-8407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173331#comment-17173331
]
ASF GitHub Bot commented on GEODE-8407:
---
bschuchardt opened a new pull request #5433:
URL: https://github.com/apache/geode/pull/5433
…e name b… (#5428)"
This reverts commit d6c3b1f20a55c5d867f162a338910d5df7d47de5.
The new test fails consistently on Windows.
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
- [ ] Has your PR been rebased against the latest commit within the target
branch (typically `develop`)?
- [ ] Is your initial contribution a single, squashed commit?
- [ ] Does `gradlew build` run cleanly?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
### Note:
Please ensure that once the PR is submitted, check Concourse for build
issues and
submit an update to your PR as soon as possible. If you need help, please
send an
email to d...@geode.apache.org.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> MergeLogFiles fails to include files with the same name but in different
> directories
>
>
> Key: GEODE-8407
> URL: https://issues.apache.org/jira/browse/GEODE-8407
> Project: Geode
> Issue Type: Bug
> Components: membership, tools
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> The default setting for MergeLogFiles is dirCount=0, meaning each line of the
> merge has the name of the corresponding log file but not its parent directory.
> I tried merging a bunch of files named _system.log_ in different directories
> and found that, though all of the files were listed in the header only one of
> them was in the merged output.
> If I set a dirCount of 1 then it works okay.
> I think the flaw is in this line:
> {code:java}
> logFiles.put(logFileName, new FileInputStream(file));
> {code}
> This is after the dirCount has been applied. In my case each logFileName is
> going to be _system.log_ and each will overwrite whatever's already in the
> map, leaving only one file.
> The full path name of each file should be used as a key in this map and the
> display name with dirCount applied needs to be held in this map in some other
> way.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8394) Client sends partial data during retry
[ https://issues.apache.org/jira/browse/GEODE-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173330#comment-17173330 ] ASF GitHub Bot commented on GEODE-8394: --- agingade merged pull request #5424: URL: https://github.com/apache/geode/pull/5424 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Client sends partial data during retry > -- > > Key: GEODE-8394 > URL: https://issues.apache.org/jira/browse/GEODE-8394 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.14.0 >Reporter: Anilkumar Gingade >Assignee: Anilkumar Gingade >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > When executing the command, java client sends the command in the form of > message (Parts). If there is a failure during the send, it retries number of > times based on the retry-attempt setting. > If there is a failure in the first attempt due to Exception (IOException, > EOFException - read timeout); during the second attempt the client is sending > partial data, instead of the complete data. > This could be reproduced by setting a small read-timeout and large object > (Put). > Because of this, the put from client succeeds by creating partial data on the > server cache. Since the data is stored in serialized form, there is no > exception thrown during put() operation, giving an impression that put > operation is successful. > The workaround for now is to have large read-timeout setting; while trying to > send a large object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8394) Client sends partial data during retry
[ https://issues.apache.org/jira/browse/GEODE-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173332#comment-17173332 ] ASF subversion and git services commented on GEODE-8394: Commit 83d1e28a953b7d73e7f499f9013540bedd0bd472 in geode's branch refs/heads/develop from agingade [ https://gitbox.apache.org/repos/asf?p=geode.git;h=83d1e28 ] GEODE-8394: Rewind the message Part on command failure (#5424) GEODE-8394: Rewind the message Part on failure Co-authored-by: anilkumar gingade > Client sends partial data during retry > -- > > Key: GEODE-8394 > URL: https://issues.apache.org/jira/browse/GEODE-8394 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.14.0 >Reporter: Anilkumar Gingade >Assignee: Anilkumar Gingade >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > When executing the command, java client sends the command in the form of > message (Parts). If there is a failure during the send, it retries number of > times based on the retry-attempt setting. > If there is a failure in the first attempt due to Exception (IOException, > EOFException - read timeout); during the second attempt the client is sending > partial data, instead of the complete data. > This could be reproduced by setting a small read-timeout and large object > (Put). > Because of this, the put from client succeeds by creating partial data on the > server cache. Since the data is stored in serialized form, there is no > exception thrown during put() operation, giving an impression that put > operation is successful. > The workaround for now is to have large read-timeout setting; while trying to > send a large object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8394) Client sends partial data during retry
[ https://issues.apache.org/jira/browse/GEODE-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1717#comment-1717 ] ASF subversion and git services commented on GEODE-8394: Commit 83d1e28a953b7d73e7f499f9013540bedd0bd472 in geode's branch refs/heads/develop from agingade [ https://gitbox.apache.org/repos/asf?p=geode.git;h=83d1e28 ] GEODE-8394: Rewind the message Part on command failure (#5424) GEODE-8394: Rewind the message Part on failure Co-authored-by: anilkumar gingade > Client sends partial data during retry > -- > > Key: GEODE-8394 > URL: https://issues.apache.org/jira/browse/GEODE-8394 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.14.0 >Reporter: Anilkumar Gingade >Assignee: Anilkumar Gingade >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > When executing the command, java client sends the command in the form of > message (Parts). If there is a failure during the send, it retries number of > times based on the retry-attempt setting. > If there is a failure in the first attempt due to Exception (IOException, > EOFException - read timeout); during the second attempt the client is sending > partial data, instead of the complete data. > This could be reproduced by setting a small read-timeout and large object > (Put). > Because of this, the put from client succeeds by creating partial data on the > server cache. Since the data is stored in serialized form, there is no > exception thrown during put() operation, giving an impression that put > operation is successful. > The workaround for now is to have large read-timeout setting; while trying to > send a large object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8413) CI failure: MergeLogFilesIntegrationTest.testDircountZero fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-8413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt updated GEODE-8413:
--
Summary: CI failure: MergeLogFilesIntegrationTest.testDircountZero fails on
Windows (was: CI failure: MergeLogFilesIntegrationTest.testDircountZero failes
on Windows)
> CI failure: MergeLogFilesIntegrationTest.testDircountZero fails on Windows
> --
>
> Key: GEODE-8413
> URL: https://issues.apache.org/jira/browse/GEODE-8413
> Project: Geode
> Issue Type: Bug
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
>
>
>
> {noformat}
> org.apache.geode.internal.logging.MergeLogFilesIntegrationTest >
> testDircountZero FAILED
> 06:43:07java.io.FileNotFoundException:
> C:\Users\geode\geode\geode-core\build\resources\integrationTest\org\apache\geode\internal\logging\dir1%5csystemlog.txt
> (The system cannot find the file specified)
> 06:43:07at java.io.FileInputStream.open0(Native Method)
> 06:43:07at java.io.FileInputStream.open(FileInputStream.java:195)
> 06:43:07at java.io.FileInputStream.(FileInputStream.java:138)
> 06:43:07at
> org.apache.geode.internal.logging.MergeLogFiles.getStringDisplayNameAndFileStreamMap(MergeLogFiles.java:349)
> 06:43:07at
> org.apache.geode.internal.logging.MergeLogFilesIntegrationTest.testDircountZero(MergeLogFilesIntegrationTest.java:128)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8394) Client sends partial data during retry
[ https://issues.apache.org/jira/browse/GEODE-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173336#comment-17173336 ] ASF subversion and git services commented on GEODE-8394: Commit 83d1e28a953b7d73e7f499f9013540bedd0bd472 in geode's branch refs/heads/develop from agingade [ https://gitbox.apache.org/repos/asf?p=geode.git;h=83d1e28 ] GEODE-8394: Rewind the message Part on command failure (#5424) GEODE-8394: Rewind the message Part on failure Co-authored-by: anilkumar gingade > Client sends partial data during retry > -- > > Key: GEODE-8394 > URL: https://issues.apache.org/jira/browse/GEODE-8394 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.14.0 >Reporter: Anilkumar Gingade >Assignee: Anilkumar Gingade >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > When executing the command, java client sends the command in the form of > message (Parts). If there is a failure during the send, it retries number of > times based on the retry-attempt setting. > If there is a failure in the first attempt due to Exception (IOException, > EOFException - read timeout); during the second attempt the client is sending > partial data, instead of the complete data. > This could be reproduced by setting a small read-timeout and large object > (Put). > Because of this, the put from client succeeds by creating partial data on the > server cache. Since the data is stored in serialized form, there is no > exception thrown during put() operation, giving an impression that put > operation is successful. > The workaround for now is to have large read-timeout setting; while trying to > send a large object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8394) Client sends partial data during retry
[ https://issues.apache.org/jira/browse/GEODE-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173335#comment-17173335 ] ASF subversion and git services commented on GEODE-8394: Commit 83d1e28a953b7d73e7f499f9013540bedd0bd472 in geode's branch refs/heads/develop from agingade [ https://gitbox.apache.org/repos/asf?p=geode.git;h=83d1e28 ] GEODE-8394: Rewind the message Part on command failure (#5424) GEODE-8394: Rewind the message Part on failure Co-authored-by: anilkumar gingade > Client sends partial data during retry > -- > > Key: GEODE-8394 > URL: https://issues.apache.org/jira/browse/GEODE-8394 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.14.0 >Reporter: Anilkumar Gingade >Assignee: Anilkumar Gingade >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > When executing the command, java client sends the command in the form of > message (Parts). If there is a failure during the send, it retries number of > times based on the retry-attempt setting. > If there is a failure in the first attempt due to Exception (IOException, > EOFException - read timeout); during the second attempt the client is sending > partial data, instead of the complete data. > This could be reproduced by setting a small read-timeout and large object > (Put). > Because of this, the put from client succeeds by creating partial data on the > server cache. Since the data is stored in serialized form, there is no > exception thrown during put() operation, giving an impression that put > operation is successful. > The workaround for now is to have large read-timeout setting; while trying to > send a large object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8396) NullPointerException occurs in create jdbc-mapping command
[
https://issues.apache.org/jira/browse/GEODE-8396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173365#comment-17173365
]
ASF GitHub Bot commented on GEODE-8396:
---
DonalEvans merged pull request #5418:
URL: https://github.com/apache/geode/pull/5418
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> NullPointerException occurs in create jdbc-mapping command
> --
>
> Key: GEODE-8396
> URL: https://issues.apache.org/jira/browse/GEODE-8396
> Project: Geode
> Issue Type: Bug
> Components: jdbc
>Reporter: Masaki Yamakawa
>Priority: Minor
> Labels: pull-request-available
>
> NullPointerException occurs in create jdbc-mapping command when partitioned
> region is specified by refid of cache.xml (cluster.xml).
> The cluster.xml and gfsh command are as follows:
> cluster.xml
> {code:java}
>
>
> {code}
> gfsh
> {code:java}
> gfsh start locator --name=ExampleLocator --enable-cluster-configuration=true
> gfsh start server --name=ExampleServer --locators=ExampleLocator[10334]
> --use-cluster-configuration=true
> create data-source --name=ExampleDataSource
> --url=jdbc:mysql://mariadb/geode_db --username=geode_user --if-not-exists=true
> create jdbc-mapping --data-source=ExampleDataSource --region=ExampleRegion
> --catalog=geode_db --table=ExampleRegion --pdx-name=com.example.Example
> --synchronous=false{code}
> The cause is that
> `org.apache.geode.connectors.jdbc.internal.cli.CreateMappingCommand#createAsyncQueue`
> refers to the DataPolicy, but when using cluster.xml is not set.
> * In case of create region command, both refid and data-policy are set.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8396) NullPointerException occurs in create jdbc-mapping command
[
https://issues.apache.org/jira/browse/GEODE-8396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173367#comment-17173367
]
ASF subversion and git services commented on GEODE-8396:
Commit 47598401a0ac7b4692fc3fa8f19d33a2eece4dd3 in geode's branch
refs/heads/develop from Masaki Yamakawa
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=4759840 ]
GEODE-8396: Fixing NullPointerException in create jdbc-mapping command (#5418)
> NullPointerException occurs in create jdbc-mapping command
> --
>
> Key: GEODE-8396
> URL: https://issues.apache.org/jira/browse/GEODE-8396
> Project: Geode
> Issue Type: Bug
> Components: jdbc
>Reporter: Masaki Yamakawa
>Priority: Minor
> Labels: pull-request-available
>
> NullPointerException occurs in create jdbc-mapping command when partitioned
> region is specified by refid of cache.xml (cluster.xml).
> The cluster.xml and gfsh command are as follows:
> cluster.xml
> {code:java}
>
>
> {code}
> gfsh
> {code:java}
> gfsh start locator --name=ExampleLocator --enable-cluster-configuration=true
> gfsh start server --name=ExampleServer --locators=ExampleLocator[10334]
> --use-cluster-configuration=true
> create data-source --name=ExampleDataSource
> --url=jdbc:mysql://mariadb/geode_db --username=geode_user --if-not-exists=true
> create jdbc-mapping --data-source=ExampleDataSource --region=ExampleRegion
> --catalog=geode_db --table=ExampleRegion --pdx-name=com.example.Example
> --synchronous=false{code}
> The cause is that
> `org.apache.geode.connectors.jdbc.internal.cli.CreateMappingCommand#createAsyncQueue`
> refers to the DataPolicy, but when using cluster.xml is not set.
> * In case of create region command, both refid and data-policy are set.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8413) CI failure: MergeLogFilesIntegrationTest.testDircountZero fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-8413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8413:
--
Labels: pull-request-available (was: )
> CI failure: MergeLogFilesIntegrationTest.testDircountZero fails on Windows
> --
>
> Key: GEODE-8413
> URL: https://issues.apache.org/jira/browse/GEODE-8413
> Project: Geode
> Issue Type: Bug
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
>
>
>
> {noformat}
> org.apache.geode.internal.logging.MergeLogFilesIntegrationTest >
> testDircountZero FAILED
> 06:43:07java.io.FileNotFoundException:
> C:\Users\geode\geode\geode-core\build\resources\integrationTest\org\apache\geode\internal\logging\dir1%5csystemlog.txt
> (The system cannot find the file specified)
> 06:43:07at java.io.FileInputStream.open0(Native Method)
> 06:43:07at java.io.FileInputStream.open(FileInputStream.java:195)
> 06:43:07at java.io.FileInputStream.(FileInputStream.java:138)
> 06:43:07at
> org.apache.geode.internal.logging.MergeLogFiles.getStringDisplayNameAndFileStreamMap(MergeLogFiles.java:349)
> 06:43:07at
> org.apache.geode.internal.logging.MergeLogFilesIntegrationTest.testDircountZero(MergeLogFilesIntegrationTest.java:128)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8413) CI failure: MergeLogFilesIntegrationTest.testDircountZero fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-8413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173378#comment-17173378
]
ASF GitHub Bot commented on GEODE-8413:
---
bschuchardt opened a new pull request #5435:
URL: https://github.com/apache/geode/pull/5435
Fixing directory path formation problem for Windows. I've tested these
changes on a Mac and on a Windows machine.
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
- [ ] Has your PR been rebased against the latest commit within the target
branch (typically `develop`)?
- [ ] Is your initial contribution a single, squashed commit?
- [ ] Does `gradlew build` run cleanly?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
### Note:
Please ensure that once the PR is submitted, check Concourse for build
issues and
submit an update to your PR as soon as possible. If you need help, please
send an
email to d...@geode.apache.org.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> CI failure: MergeLogFilesIntegrationTest.testDircountZero fails on Windows
> --
>
> Key: GEODE-8413
> URL: https://issues.apache.org/jira/browse/GEODE-8413
> Project: Geode
> Issue Type: Bug
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
>
>
>
> {noformat}
> org.apache.geode.internal.logging.MergeLogFilesIntegrationTest >
> testDircountZero FAILED
> 06:43:07java.io.FileNotFoundException:
> C:\Users\geode\geode\geode-core\build\resources\integrationTest\org\apache\geode\internal\logging\dir1%5csystemlog.txt
> (The system cannot find the file specified)
> 06:43:07at java.io.FileInputStream.open0(Native Method)
> 06:43:07at java.io.FileInputStream.open(FileInputStream.java:195)
> 06:43:07at java.io.FileInputStream.(FileInputStream.java:138)
> 06:43:07at
> org.apache.geode.internal.logging.MergeLogFiles.getStringDisplayNameAndFileStreamMap(MergeLogFiles.java:349)
> 06:43:07at
> org.apache.geode.internal.logging.MergeLogFilesIntegrationTest.testDircountZero(MergeLogFilesIntegrationTest.java:128)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8413) CI failure: MergeLogFilesIntegrationTest.testDircountZero fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-8413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173392#comment-17173392
]
ASF GitHub Bot commented on GEODE-8413:
---
bschuchardt commented on pull request #5435:
URL: https://github.com/apache/geode/pull/5435#issuecomment-670643196
Since this is a test-only change and the checks that use that test have
passed I'm merging this PR before all of the non-required checks have finished.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> CI failure: MergeLogFilesIntegrationTest.testDircountZero fails on Windows
> --
>
> Key: GEODE-8413
> URL: https://issues.apache.org/jira/browse/GEODE-8413
> Project: Geode
> Issue Type: Bug
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
>
>
>
> {noformat}
> org.apache.geode.internal.logging.MergeLogFilesIntegrationTest >
> testDircountZero FAILED
> 06:43:07java.io.FileNotFoundException:
> C:\Users\geode\geode\geode-core\build\resources\integrationTest\org\apache\geode\internal\logging\dir1%5csystemlog.txt
> (The system cannot find the file specified)
> 06:43:07at java.io.FileInputStream.open0(Native Method)
> 06:43:07at java.io.FileInputStream.open(FileInputStream.java:195)
> 06:43:07at java.io.FileInputStream.(FileInputStream.java:138)
> 06:43:07at
> org.apache.geode.internal.logging.MergeLogFiles.getStringDisplayNameAndFileStreamMap(MergeLogFiles.java:349)
> 06:43:07at
> org.apache.geode.internal.logging.MergeLogFilesIntegrationTest.testDircountZero(MergeLogFilesIntegrationTest.java:128)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8413) CI failure: MergeLogFilesIntegrationTest.testDircountZero fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-8413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173391#comment-17173391
]
ASF GitHub Bot commented on GEODE-8413:
---
bschuchardt merged pull request #5435:
URL: https://github.com/apache/geode/pull/5435
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> CI failure: MergeLogFilesIntegrationTest.testDircountZero fails on Windows
> --
>
> Key: GEODE-8413
> URL: https://issues.apache.org/jira/browse/GEODE-8413
> Project: Geode
> Issue Type: Bug
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
>
>
>
> {noformat}
> org.apache.geode.internal.logging.MergeLogFilesIntegrationTest >
> testDircountZero FAILED
> 06:43:07java.io.FileNotFoundException:
> C:\Users\geode\geode\geode-core\build\resources\integrationTest\org\apache\geode\internal\logging\dir1%5csystemlog.txt
> (The system cannot find the file specified)
> 06:43:07at java.io.FileInputStream.open0(Native Method)
> 06:43:07at java.io.FileInputStream.open(FileInputStream.java:195)
> 06:43:07at java.io.FileInputStream.(FileInputStream.java:138)
> 06:43:07at
> org.apache.geode.internal.logging.MergeLogFiles.getStringDisplayNameAndFileStreamMap(MergeLogFiles.java:349)
> 06:43:07at
> org.apache.geode.internal.logging.MergeLogFilesIntegrationTest.testDircountZero(MergeLogFilesIntegrationTest.java:128)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8413) CI failure: MergeLogFilesIntegrationTest.testDircountZero fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-8413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173393#comment-17173393
]
ASF subversion and git services commented on GEODE-8413:
Commit 6a08bba48a92db682a3443b9ce47b44796cb4ab1 in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6a08bba ]
GEODE-8413: CI failure: MergeLogFilesIntegrationTest.testDircountZero failes on
Windows (#5435)
fixing directory path formation problem for Windows
> CI failure: MergeLogFilesIntegrationTest.testDircountZero fails on Windows
> --
>
> Key: GEODE-8413
> URL: https://issues.apache.org/jira/browse/GEODE-8413
> Project: Geode
> Issue Type: Bug
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
>
>
>
> {noformat}
> org.apache.geode.internal.logging.MergeLogFilesIntegrationTest >
> testDircountZero FAILED
> 06:43:07java.io.FileNotFoundException:
> C:\Users\geode\geode\geode-core\build\resources\integrationTest\org\apache\geode\internal\logging\dir1%5csystemlog.txt
> (The system cannot find the file specified)
> 06:43:07at java.io.FileInputStream.open0(Native Method)
> 06:43:07at java.io.FileInputStream.open(FileInputStream.java:195)
> 06:43:07at java.io.FileInputStream.(FileInputStream.java:138)
> 06:43:07at
> org.apache.geode.internal.logging.MergeLogFiles.getStringDisplayNameAndFileStreamMap(MergeLogFiles.java:349)
> 06:43:07at
> org.apache.geode.internal.logging.MergeLogFilesIntegrationTest.testDircountZero(MergeLogFilesIntegrationTest.java:128)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8407) MergeLogFiles fails to include files with the same name but in different directories
[
https://issues.apache.org/jira/browse/GEODE-8407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173395#comment-17173395
]
ASF GitHub Bot commented on GEODE-8407:
---
bschuchardt closed pull request #5433:
URL: https://github.com/apache/geode/pull/5433
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> MergeLogFiles fails to include files with the same name but in different
> directories
>
>
> Key: GEODE-8407
> URL: https://issues.apache.org/jira/browse/GEODE-8407
> Project: Geode
> Issue Type: Bug
> Components: membership, tools
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> The default setting for MergeLogFiles is dirCount=0, meaning each line of the
> merge has the name of the corresponding log file but not its parent directory.
> I tried merging a bunch of files named _system.log_ in different directories
> and found that, though all of the files were listed in the header only one of
> them was in the merged output.
> If I set a dirCount of 1 then it works okay.
> I think the flaw is in this line:
> {code:java}
> logFiles.put(logFileName, new FileInputStream(file));
> {code}
> This is after the dirCount has been applied. In my case each logFileName is
> going to be _system.log_ and each will overwrite whatever's already in the
> map, leaving only one file.
> The full path name of each file should be used as a key in this map and the
> display name with dirCount applied needs to be held in this map in some other
> way.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8119) Threads are not properly closed when offline disk-store commands are invoked
[ https://issues.apache.org/jira/browse/GEODE-8119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8119: -- Labels: pull-request-available (was: ) > Threads are not properly closed when offline disk-store commands are invoked > > > Key: GEODE-8119 > URL: https://issues.apache.org/jira/browse/GEODE-8119 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Labels: pull-request-available > > Threads can be opened when you are online and offline, but close only when > you are online. Once some offline command started thread it cannot be closed > and after some time if there is a bigger number of this threads it can lead > to OOM exception. > Also the problem is that its validating only disk-dirs but not diskStore > name. So thread can be created but there is no diskStore with that name and > it will also hang. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8119) Threads are not properly closed when offline disk-store commands are invoked
[ https://issues.apache.org/jira/browse/GEODE-8119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173410#comment-17173410 ] ASF GitHub Bot commented on GEODE-8119: --- jujoramos commented on pull request #5175: URL: https://github.com/apache/geode/pull/5175#issuecomment-670655764 @mkevo Thanks for adding the extra tests. I'm not fully convinced about the implemented fix, however, did you consider my comments [here](https://github.com/apache/geode/pull/5175#issuecomment-638793177)?. Can't you just simply invoke the `DiskStoreImpl.close()` method instead of modifying the `DiskStoreCommandsUtils` class, as it involves way less modifications and we're sure it won't affect other areas of the `disk` management stuff?. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Threads are not properly closed when offline disk-store commands are invoked > > > Key: GEODE-8119 > URL: https://issues.apache.org/jira/browse/GEODE-8119 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > > Threads can be opened when you are online and offline, but close only when > you are online. Once some offline command started thread it cannot be closed > and after some time if there is a bigger number of this threads it can lead > to OOM exception. > Also the problem is that its validating only disk-dirs but not diskStore > name. So thread can be created but there is no diskStore with that name and > it will also hang. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8340) Enforce Switch compiler warnings as errors
[
https://issues.apache.org/jira/browse/GEODE-8340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173416#comment-17173416
]
ASF GitHub Bot commented on GEODE-8340:
---
moleske commented on a change in pull request #625:
URL: https://github.com/apache/geode-native/pull/625#discussion_r467223869
##
File path: cppcache/src/ExceptionTypes.cpp
##
@@ -297,7 +297,25 @@ const std::string& getThreadLocalExceptionMessage();
PutAllPartialResultException ex(message);
throw ex;
}
-default: {
+case GF_NOERR:
Review comment:
(I mostly just wanted to post that gif, no particular rush 😃)
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Enforce Switch compiler warnings as errors
> --
>
> Key: GEODE-8340
> URL: https://issues.apache.org/jira/browse/GEODE-8340
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Michael Oleske
>Priority: Major
> Labels: pull-request-available
>
> Given I compile the code without exempting no-switch-enum and
> no-implicit-fallthrough and no-covered-switch-default
> Then it should compile
> Note - was marked as a todo, seems reasonable to tackle all these at once
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8344) Deserialization error in multisite conf using CQs and C++ client
[
https://issues.apache.org/jira/browse/GEODE-8344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173423#comment-17173423
]
ASF GitHub Bot commented on GEODE-8344:
---
moleske commented on a change in pull request #628:
URL: https://github.com/apache/geode-native/pull/628#discussion_r467228776
##
File path: cppcache/integration/test/Order.cpp
##
@@ -0,0 +1,60 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include "Order.hpp"
+
+#include
+#include
+
+namespace testGeode8344 {
Review comment:
I would consider picking a namespace name that is more descriptive. I
think a few months from now (or for me, a few weeks) it will not be obvious
what Geode 8344 means without having to go look up it up in jira
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Deserialization error in multisite conf using CQs and C++ client
>
>
> Key: GEODE-8344
> URL: https://issues.apache.org/jira/browse/GEODE-8344
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> Im creating this ticket after this conversation in the dev list, so there is
> more information here: http://markmail.org/thread/u65gmb7zoxlpcqss
> h3. Setup:
> - Two sites
> - CQs configured
> - Using C++ client
> h3. Problem:
> It is observed that while CQ events from local site (the one that the client
> is connected to) are received, the one originated in remote servers are
> missing.
> After debugging it was observed there is an error in the logs, trying to
> deserialize fixedID = -135.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8414) Calls to WANRollingUpgradeDUnitTest.startLocator() fail with java.net.BindException: Address already in use (Bind failed)
Donal Evans created GEODE-8414: -- Summary: Calls to WANRollingUpgradeDUnitTest.startLocator() fail with java.net.BindException: Address already in use (Bind failed) Key: GEODE-8414 URL: https://issues.apache.org/jira/browse/GEODE-8414 Project: Geode Issue Type: Bug Components: tests, wan Reporter: Donal Evans Several tickets already exist (and are linked to this ticket) which describe individual failures in various WANRollingUpgrade tests, but all of those tickets have stack traces showing calls to WANRollingUpgradeDUnitTest.startLocator() as being the cause of the exception. This ticket is created to consolidate the other tickets and hopefully prevent other duplicate tickets being opened. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8414) Calls to WANRollingUpgradeDUnitTest.startLocator() fail with java.net.BindException: Address already in use (Bind failed)
[ https://issues.apache.org/jira/browse/GEODE-8414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-8414: --- Affects Version/s: 1.14.0 > Calls to WANRollingUpgradeDUnitTest.startLocator() fail with > java.net.BindException: Address already in use (Bind failed) > - > > Key: GEODE-8414 > URL: https://issues.apache.org/jira/browse/GEODE-8414 > Project: Geode > Issue Type: Bug > Components: tests, wan >Affects Versions: 1.14.0 >Reporter: Donal Evans >Priority: Major > > Several tickets already exist (and are linked to this ticket) which describe > individual failures in various WANRollingUpgrade tests, but all of those > tickets have stack traces showing calls to > WANRollingUpgradeDUnitTest.startLocator() as being the cause of the > exception. This ticket is created to consolidate the other tickets and > hopefully prevent other duplicate tickets being opened. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8414) Calls to WANRollingUpgradeDUnitTest.startLocator() fail with java.net.BindException: Address already in use (Bind failed)
[ https://issues.apache.org/jira/browse/GEODE-8414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-8414: --- Labels: flaky-test (was: ) > Calls to WANRollingUpgradeDUnitTest.startLocator() fail with > java.net.BindException: Address already in use (Bind failed) > - > > Key: GEODE-8414 > URL: https://issues.apache.org/jira/browse/GEODE-8414 > Project: Geode > Issue Type: Bug > Components: tests, wan >Affects Versions: 1.14.0 >Reporter: Donal Evans >Priority: Major > Labels: flaky-test > > Several tickets already exist (and are linked to this ticket) which describe > individual failures in various WANRollingUpgrade tests, but all of those > tickets have stack traces showing calls to > WANRollingUpgradeDUnitTest.startLocator() as being the cause of the > exception. This ticket is created to consolidate the other tickets and > hopefully prevent other duplicate tickets being opened. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8414) Calls to WANRollingUpgradeDUnitTest.startLocator() fail with java.net.BindException: Address already in use (Bind failed)
[
https://issues.apache.org/jira/browse/GEODE-8414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-8414:
---
Description:
Several tickets already exist (and are linked to this ticket) which describe
individual failures in various WANRollingUpgrade tests, but all of those
tickets have stack traces showing calls to
WANRollingUpgradeDUnitTest.startLocator() as being the cause of the exception.
This ticket is created to consolidate the other tickets and hopefully prevent
other duplicate tickets being opened.
{noformat}
org.apache.geode.cache.wan.WANRollingUpgradeCreateGatewaySenderMixedSiteOneCurrentSiteTwo
> CreateGatewaySenderMixedSiteOneCurrentSiteTwo[from_v1.8.0] FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.cache.wan.WANRollingUpgradeCreateGatewaySenderMixedSiteOneCurrentSiteTwo$$Lambda$201/0x000840855040.run
in VM 4 running on Host 8be55f9b8a8e with 7 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:620)
at org.apache.geode.test.dunit.VM.invoke(VM.java:447)
at
org.apache.geode.cache.wan.WANRollingUpgradeCreateGatewaySenderMixedSiteOneCurrentSiteTwo.CreateGatewaySenderMixedSiteOneCurrentSiteTwo(WANRollingUpgradeCreateGatewaySenderMixedSiteOneCurrentSiteTwo.java:78)
Caused by:
java.net.BindException: Failed to create server socket on
172.17.0.44[28673]
at
org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:75)
at
org.apache.geode.internal.net.SCClusterSocketCreator.createServerSocket(SCClusterSocketCreator.java:56)
at
org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:48)
at
org.apache.geode.distributed.internal.tcpserver.TcpServer.initializeServerSocket(TcpServer.java:204)
at
org.apache.geode.distributed.internal.tcpserver.TcpServer.startServerThread(TcpServer.java:194)
at
org.apache.geode.distributed.internal.tcpserver.TcpServer.start(TcpServer.java:189)
at
org.apache.geode.distributed.internal.membership.gms.locator.MembershipLocatorImpl.start(MembershipLocatorImpl.java:110)
at
org.apache.geode.distributed.internal.InternalLocator.startPeerLocation(InternalLocator.java:638)
at
org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:383)
at
org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:338)
at
org.apache.geode.distributed.Locator.startLocator(Locator.java:252)
at
org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:139)
at
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest.startLocator(WANRollingUpgradeDUnitTest.java:105)
at
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest.startLocator(WANRollingUpgradeDUnitTest.java:97)
at
org.apache.geode.cache.wan.WANRollingUpgradeCreateGatewaySenderMixedSiteOneCurrentSiteTwo.lambda$null$1(WANRollingUpgradeCreateGatewaySenderMixedSiteOneCurrentSiteTwo.java:79)
Caused by:
java.net.BindException: Address already in use (Bind failed)
at java.net.PlainSocketImpl.socketBind(Native Method)
at
java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:436)
at java.net.ServerSocket.bind(ServerSocket.java:395)
at
org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:72)
... 14 more
{noformat}
was:Several tickets already exist (and are linked to this ticket) which
describe individual failures in various WANRollingUpgrade tests, but all of
those tickets have stack traces showing calls to
WANRollingUpgradeDUnitTest.startLocator() as being the cause of the exception.
This ticket is created to consolidate the other tickets and hopefully prevent
other duplicate tickets being opened.
> Calls to WANRollingUpgradeDUnitTest.startLocator() fail with
> java.net.BindException: Address already in use (Bind failed)
> -
>
> Key: GEODE-8414
> URL: https://issues.apache.org/jira/browse/GEODE-8414
> Project: Geode
> Issue Type: Bug
> Components: tests, wan
>Affects Versions: 1.14.0
>Reporter: Donal Evans
>Priority: Major
> Labels: flaky-test
>
> Several tickets already exist (and are linked to this ticket) which describe
> individual failures in various WANRollingUpgrade tests, but all of those
> tickets have stack traces showing calls to
> WANRollingUpgrade
[jira] [Resolved] (GEODE-8413) CI failure: MergeLogFilesIntegrationTest.testDircountZero fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-8413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt resolved GEODE-8413.
---
Fix Version/s: 1.14.0
Resolution: Fixed
> CI failure: MergeLogFilesIntegrationTest.testDircountZero fails on Windows
> --
>
> Key: GEODE-8413
> URL: https://issues.apache.org/jira/browse/GEODE-8413
> Project: Geode
> Issue Type: Bug
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
>
>
> {noformat}
> org.apache.geode.internal.logging.MergeLogFilesIntegrationTest >
> testDircountZero FAILED
> 06:43:07java.io.FileNotFoundException:
> C:\Users\geode\geode\geode-core\build\resources\integrationTest\org\apache\geode\internal\logging\dir1%5csystemlog.txt
> (The system cannot find the file specified)
> 06:43:07at java.io.FileInputStream.open0(Native Method)
> 06:43:07at java.io.FileInputStream.open(FileInputStream.java:195)
> 06:43:07at java.io.FileInputStream.(FileInputStream.java:138)
> 06:43:07at
> org.apache.geode.internal.logging.MergeLogFiles.getStringDisplayNameAndFileStreamMap(MergeLogFiles.java:349)
> 06:43:07at
> org.apache.geode.internal.logging.MergeLogFilesIntegrationTest.testDircountZero(MergeLogFilesIntegrationTest.java:128)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-8413) CI failure: MergeLogFilesIntegrationTest.testDircountZero fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-8413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt closed GEODE-8413.
-
no release note needed
> CI failure: MergeLogFilesIntegrationTest.testDircountZero fails on Windows
> --
>
> Key: GEODE-8413
> URL: https://issues.apache.org/jira/browse/GEODE-8413
> Project: Geode
> Issue Type: Bug
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
>
>
> {noformat}
> org.apache.geode.internal.logging.MergeLogFilesIntegrationTest >
> testDircountZero FAILED
> 06:43:07java.io.FileNotFoundException:
> C:\Users\geode\geode\geode-core\build\resources\integrationTest\org\apache\geode\internal\logging\dir1%5csystemlog.txt
> (The system cannot find the file specified)
> 06:43:07at java.io.FileInputStream.open0(Native Method)
> 06:43:07at java.io.FileInputStream.open(FileInputStream.java:195)
> 06:43:07at java.io.FileInputStream.(FileInputStream.java:138)
> 06:43:07at
> org.apache.geode.internal.logging.MergeLogFiles.getStringDisplayNameAndFileStreamMap(MergeLogFiles.java:349)
> 06:43:07at
> org.apache.geode.internal.logging.MergeLogFilesIntegrationTest.testDircountZero(MergeLogFilesIntegrationTest.java:128)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8413) CI failure: MergeLogFilesIntegrationTest.testDircountZero fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-8413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt updated GEODE-8413:
--
Labels: no-release-note pull-request-available (was:
pull-request-available)
> CI failure: MergeLogFilesIntegrationTest.testDircountZero fails on Windows
> --
>
> Key: GEODE-8413
> URL: https://issues.apache.org/jira/browse/GEODE-8413
> Project: Geode
> Issue Type: Bug
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: no-release-note, pull-request-available
> Fix For: 1.14.0
>
>
>
>
> {noformat}
> org.apache.geode.internal.logging.MergeLogFilesIntegrationTest >
> testDircountZero FAILED
> 06:43:07java.io.FileNotFoundException:
> C:\Users\geode\geode\geode-core\build\resources\integrationTest\org\apache\geode\internal\logging\dir1%5csystemlog.txt
> (The system cannot find the file specified)
> 06:43:07at java.io.FileInputStream.open0(Native Method)
> 06:43:07at java.io.FileInputStream.open(FileInputStream.java:195)
> 06:43:07at java.io.FileInputStream.(FileInputStream.java:138)
> 06:43:07at
> org.apache.geode.internal.logging.MergeLogFiles.getStringDisplayNameAndFileStreamMap(MergeLogFiles.java:349)
> 06:43:07at
> org.apache.geode.internal.logging.MergeLogFilesIntegrationTest.testDircountZero(MergeLogFilesIntegrationTest.java:128)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7672) Partitioned Region clear will successfully update the OQL indexes
[ https://issues.apache.org/jira/browse/GEODE-7672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-7672: -- Labels: GeodeCommons pull-request-available (was: GeodeCommons) > Partitioned Region clear will successfully update the OQL indexes > - > > Key: GEODE-7672 > URL: https://issues.apache.org/jira/browse/GEODE-7672 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Jianxia Chen >Priority: Major > Labels: GeodeCommons, pull-request-available > > Clear operations are successfully updates the OQL indexes > > Acceptance : > * Passing Dunit tests where OQL queries using indexes return correct results > after the region is cleared > * clear operation and index updates are successful when clear operation is > executed when the puts are occurring which are trying to update the OQL index. > * Unit tests to ensure that index sizes are zero after the region is cleaned > * Test coverage to when a member departs in this scenario > * Test coverage to when a member restarts in this scenario > * Unit tests with complete code coverage for the newly written code. > > analyze if these tests are needed for offheap? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7672) Partitioned Region clear will successfully update the OQL indexes
[ https://issues.apache.org/jira/browse/GEODE-7672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173442#comment-17173442 ] ASF GitHub Bot commented on GEODE-7672: --- jinmeiliao opened a new pull request #5436: URL: https://github.com/apache/geode/pull/5436 * allow ClusterStartupRule to launch dunit default locator This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Partitioned Region clear will successfully update the OQL indexes > - > > Key: GEODE-7672 > URL: https://issues.apache.org/jira/browse/GEODE-7672 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Jianxia Chen >Priority: Major > Labels: GeodeCommons > > Clear operations are successfully updates the OQL indexes > > Acceptance : > * Passing Dunit tests where OQL queries using indexes return correct results > after the region is cleared > * clear operation and index updates are successful when clear operation is > executed when the puts are occurring which are trying to update the OQL index. > * Unit tests to ensure that index sizes are zero after the region is cleaned > * Test coverage to when a member departs in this scenario > * Test coverage to when a member restarts in this scenario > * Unit tests with complete code coverage for the newly written code. > > analyze if these tests are needed for offheap? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8394) Client sends partial data during retry
[ https://issues.apache.org/jira/browse/GEODE-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173519#comment-17173519 ] ASF subversion and git services commented on GEODE-8394: Commit 0fe6518851d7bdd85d544b8f3c0647ab9053c891 in geode's branch refs/heads/support/1.13 from agingade [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0fe6518 ] GEODE-8394: Rewind the message Part on command failure (#5424) GEODE-8394: Rewind the message Part on failure Co-authored-by: anilkumar gingade (cherry picked from commit 83d1e28a953b7d73e7f499f9013540bedd0bd472) > Client sends partial data during retry > -- > > Key: GEODE-8394 > URL: https://issues.apache.org/jira/browse/GEODE-8394 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.14.0 >Reporter: Anilkumar Gingade >Assignee: Anilkumar Gingade >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > When executing the command, java client sends the command in the form of > message (Parts). If there is a failure during the send, it retries number of > times based on the retry-attempt setting. > If there is a failure in the first attempt due to Exception (IOException, > EOFException - read timeout); during the second attempt the client is sending > partial data, instead of the complete data. > This could be reproduced by setting a small read-timeout and large object > (Put). > Because of this, the put from client succeeds by creating partial data on the > server cache. Since the data is stored in serialized form, there is no > exception thrown during put() operation, giving an impression that put > operation is successful. > The workaround for now is to have large read-timeout setting; while trying to > send a large object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8394) Client sends partial data during retry
[ https://issues.apache.org/jira/browse/GEODE-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173518#comment-17173518 ] ASF subversion and git services commented on GEODE-8394: Commit 0fe6518851d7bdd85d544b8f3c0647ab9053c891 in geode's branch refs/heads/support/1.13 from agingade [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0fe6518 ] GEODE-8394: Rewind the message Part on command failure (#5424) GEODE-8394: Rewind the message Part on failure Co-authored-by: anilkumar gingade (cherry picked from commit 83d1e28a953b7d73e7f499f9013540bedd0bd472) > Client sends partial data during retry > -- > > Key: GEODE-8394 > URL: https://issues.apache.org/jira/browse/GEODE-8394 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.14.0 >Reporter: Anilkumar Gingade >Assignee: Anilkumar Gingade >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > When executing the command, java client sends the command in the form of > message (Parts). If there is a failure during the send, it retries number of > times based on the retry-attempt setting. > If there is a failure in the first attempt due to Exception (IOException, > EOFException - read timeout); during the second attempt the client is sending > partial data, instead of the complete data. > This could be reproduced by setting a small read-timeout and large object > (Put). > Because of this, the put from client succeeds by creating partial data on the > server cache. Since the data is stored in serialized form, there is no > exception thrown during put() operation, giving an impression that put > operation is successful. > The workaround for now is to have large read-timeout setting; while trying to > send a large object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8394) Client sends partial data during retry
[ https://issues.apache.org/jira/browse/GEODE-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173521#comment-17173521 ] ASF subversion and git services commented on GEODE-8394: Commit a6332c4576e82b5620d53ed78b768b2c47570d55 in geode's branch refs/heads/support/1.12 from agingade [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a6332c4 ] GEODE-8394: Rewind the message Part on command failure (#5424) GEODE-8394: Rewind the message Part on failure Co-authored-by: anilkumar gingade (cherry picked from commit 83d1e28a953b7d73e7f499f9013540bedd0bd472) > Client sends partial data during retry > -- > > Key: GEODE-8394 > URL: https://issues.apache.org/jira/browse/GEODE-8394 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.14.0 >Reporter: Anilkumar Gingade >Assignee: Anilkumar Gingade >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > When executing the command, java client sends the command in the form of > message (Parts). If there is a failure during the send, it retries number of > times based on the retry-attempt setting. > If there is a failure in the first attempt due to Exception (IOException, > EOFException - read timeout); during the second attempt the client is sending > partial data, instead of the complete data. > This could be reproduced by setting a small read-timeout and large object > (Put). > Because of this, the put from client succeeds by creating partial data on the > server cache. Since the data is stored in serialized form, there is no > exception thrown during put() operation, giving an impression that put > operation is successful. > The workaround for now is to have large read-timeout setting; while trying to > send a large object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8394) Client sends partial data during retry
[ https://issues.apache.org/jira/browse/GEODE-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173522#comment-17173522 ] ASF subversion and git services commented on GEODE-8394: Commit a6332c4576e82b5620d53ed78b768b2c47570d55 in geode's branch refs/heads/support/1.12 from agingade [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a6332c4 ] GEODE-8394: Rewind the message Part on command failure (#5424) GEODE-8394: Rewind the message Part on failure Co-authored-by: anilkumar gingade (cherry picked from commit 83d1e28a953b7d73e7f499f9013540bedd0bd472) > Client sends partial data during retry > -- > > Key: GEODE-8394 > URL: https://issues.apache.org/jira/browse/GEODE-8394 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.14.0 >Reporter: Anilkumar Gingade >Assignee: Anilkumar Gingade >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > When executing the command, java client sends the command in the form of > message (Parts). If there is a failure during the send, it retries number of > times based on the retry-attempt setting. > If there is a failure in the first attempt due to Exception (IOException, > EOFException - read timeout); during the second attempt the client is sending > partial data, instead of the complete data. > This could be reproduced by setting a small read-timeout and large object > (Put). > Because of this, the put from client succeeds by creating partial data on the > server cache. Since the data is stored in serialized form, there is no > exception thrown during put() operation, giving an impression that put > operation is successful. > The workaround for now is to have large read-timeout setting; while trying to > send a large object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8394) Client sends partial data during retry
[ https://issues.apache.org/jira/browse/GEODE-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade resolved GEODE-8394. -- Fix Version/s: 1.13.0 1.12.1 Resolution: Fixed > Client sends partial data during retry > -- > > Key: GEODE-8394 > URL: https://issues.apache.org/jira/browse/GEODE-8394 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.14.0 >Reporter: Anilkumar Gingade >Assignee: Anilkumar Gingade >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.12.1, 1.13.0 > > > When executing the command, java client sends the command in the form of > message (Parts). If there is a failure during the send, it retries number of > times based on the retry-attempt setting. > If there is a failure in the first attempt due to Exception (IOException, > EOFException - read timeout); during the second attempt the client is sending > partial data, instead of the complete data. > This could be reproduced by setting a small read-timeout and large object > (Put). > Because of this, the put from client succeeds by creating partial data on the > server cache. Since the data is stored in serialized form, there is no > exception thrown during put() operation, giving an impression that put > operation is successful. > The workaround for now is to have large read-timeout setting; while trying to > send a large object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8415) CI Failure: TestExamples fails in geode-ci/ci/scripts/delete_instance.sh
Donal Evans created GEODE-8415: -- Summary: CI Failure: TestExamples fails in geode-ci/ci/scripts/delete_instance.sh Key: GEODE-8415 URL: https://issues.apache.org/jira/browse/GEODE-8415 Project: Geode Issue Type: Bug Components: ci Reporter: Donal Evans After changes introduced in [https://github.com/apache/geode/pull/5427,|https://github.com/apache/geode/pull/5427] the delete_instance task fails as below: geode-ci/ci/scripts/delete_instance.sh: line 33: pushd: geode: No such file or directory -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8394) Client sends partial data during retry
[ https://issues.apache.org/jira/browse/GEODE-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173525#comment-17173525 ] ASF subversion and git services commented on GEODE-8394: Commit 5998900a396ebaf02422fb0fe7d394ba0d12d3d7 in geode's branch refs/heads/support/1.12 from anilkumar gingade [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5998900 ] Revert "GEODE-8394: Rewind the message Part on command failure (#5424)" This reverts commit a6332c4576e82b5620d53ed78b768b2c47570d55. > Client sends partial data during retry > -- > > Key: GEODE-8394 > URL: https://issues.apache.org/jira/browse/GEODE-8394 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.14.0 >Reporter: Anilkumar Gingade >Assignee: Anilkumar Gingade >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.12.1, 1.13.0 > > > When executing the command, java client sends the command in the form of > message (Parts). If there is a failure during the send, it retries number of > times based on the retry-attempt setting. > If there is a failure in the first attempt due to Exception (IOException, > EOFException - read timeout); during the second attempt the client is sending > partial data, instead of the complete data. > This could be reproduced by setting a small read-timeout and large object > (Put). > Because of this, the put from client succeeds by creating partial data on the > server cache. Since the data is stored in serialized form, there is no > exception thrown during put() operation, giving an impression that put > operation is successful. > The workaround for now is to have large read-timeout setting; while trying to > send a large object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8415) CI Failure: TestExamples fails in geode-ci/ci/scripts/delete_instance.sh
[
https://issues.apache.org/jira/browse/GEODE-8415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-8415:
---
Description:
After changes introduced in
[https://github.com/apache/geode/pull/5427,|https://github.com/apache/geode/pull/5427]
the delete_instance task fails as below:
{code:java}
geode-ci/ci/scripts/delete_instance.sh: line 33: pushd: geode: No such file or
directory{code}
was:
After changes introduced in
[https://github.com/apache/geode/pull/5427,|https://github.com/apache/geode/pull/5427]
the delete_instance task fails as below:
geode-ci/ci/scripts/delete_instance.sh: line 33: pushd: geode: No such file or
directory
> CI Failure: TestExamples fails in geode-ci/ci/scripts/delete_instance.sh
>
>
> Key: GEODE-8415
> URL: https://issues.apache.org/jira/browse/GEODE-8415
> Project: Geode
> Issue Type: Bug
> Components: ci
>Affects Versions: 1.14.0
>Reporter: Donal Evans
>Priority: Major
>
> After changes introduced in
> [https://github.com/apache/geode/pull/5427,|https://github.com/apache/geode/pull/5427]
> the delete_instance task fails as below:
> {code:java}
> geode-ci/ci/scripts/delete_instance.sh: line 33: pushd: geode: No such file
> or directory{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8415) CI Failure: TestExamples fails in geode-ci/ci/scripts/delete_instance.sh
[ https://issues.apache.org/jira/browse/GEODE-8415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-8415: --- Affects Version/s: 1.14.0 > CI Failure: TestExamples fails in geode-ci/ci/scripts/delete_instance.sh > > > Key: GEODE-8415 > URL: https://issues.apache.org/jira/browse/GEODE-8415 > Project: Geode > Issue Type: Bug > Components: ci >Affects Versions: 1.14.0 >Reporter: Donal Evans >Priority: Major > > After changes introduced in > [https://github.com/apache/geode/pull/5427,|https://github.com/apache/geode/pull/5427] > the delete_instance task fails as below: > geode-ci/ci/scripts/delete_instance.sh: line 33: pushd: geode: No such file > or directory -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7860) Indexed query benchmarks fail with EOFException
[
https://issues.apache.org/jira/browse/GEODE-7860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173526#comment-17173526
]
Donal Evans commented on GEODE-7860:
This reoccurred in [run
266|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/266],
leading to the benchmark job timing out.
> Indexed query benchmarks fail with EOFException
> ---
>
> Key: GEODE-7860
> URL: https://issues.apache.org/jira/browse/GEODE-7860
> Project: Geode
> Issue Type: Bug
> Components: benchmarks, querying
>Reporter: Donal Evans
>Priority: Major
>
> {noformat}
> org.apache.geode.benchmark.tests.ReplicatedIndexedQueryBenchmark > run()
> FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> Caused by:
> java.io.EOFException
> 16 tests completed, 1 failed
> org.apache.geode.benchmark.tests.PartitionedIndexedQueryBenchmark > run()
> FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> Caused by:
> java.io.EOFException
> 16 tests completed, 1 failed
> {noformat}
> Failure seen in this run:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/146
> but was passing in the following run.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8394) Client sends partial data during retry
[ https://issues.apache.org/jira/browse/GEODE-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173527#comment-17173527 ] ASF subversion and git services commented on GEODE-8394: Commit b94e793768b681c7ca2ea3df002ff7ae77e54122 in geode's branch refs/heads/support/1.12 from agingade [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b94e793 ] GEODE-8394: Rewind the message Part on command failure (#5424) GEODE-8394: Rewind the message Part on failure Co-authored-by: anilkumar gingade (cherry picked from commit 83d1e28a953b7d73e7f499f9013540bedd0bd472) > Client sends partial data during retry > -- > > Key: GEODE-8394 > URL: https://issues.apache.org/jira/browse/GEODE-8394 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.14.0 >Reporter: Anilkumar Gingade >Assignee: Anilkumar Gingade >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.12.1, 1.13.0 > > > When executing the command, java client sends the command in the form of > message (Parts). If there is a failure during the send, it retries number of > times based on the retry-attempt setting. > If there is a failure in the first attempt due to Exception (IOException, > EOFException - read timeout); during the second attempt the client is sending > partial data, instead of the complete data. > This could be reproduced by setting a small read-timeout and large object > (Put). > Because of this, the put from client succeeds by creating partial data on the > server cache. Since the data is stored in serialized form, there is no > exception thrown during put() operation, giving an impression that put > operation is successful. > The workaround for now is to have large read-timeout setting; while trying to > send a large object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8394) Client sends partial data during retry
[ https://issues.apache.org/jira/browse/GEODE-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173528#comment-17173528 ] ASF subversion and git services commented on GEODE-8394: Commit b94e793768b681c7ca2ea3df002ff7ae77e54122 in geode's branch refs/heads/support/1.12 from agingade [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b94e793 ] GEODE-8394: Rewind the message Part on command failure (#5424) GEODE-8394: Rewind the message Part on failure Co-authored-by: anilkumar gingade (cherry picked from commit 83d1e28a953b7d73e7f499f9013540bedd0bd472) > Client sends partial data during retry > -- > > Key: GEODE-8394 > URL: https://issues.apache.org/jira/browse/GEODE-8394 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.14.0 >Reporter: Anilkumar Gingade >Assignee: Anilkumar Gingade >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.12.1, 1.13.0 > > > When executing the command, java client sends the command in the form of > message (Parts). If there is a failure during the send, it retries number of > times based on the retry-attempt setting. > If there is a failure in the first attempt due to Exception (IOException, > EOFException - read timeout); during the second attempt the client is sending > partial data, instead of the complete data. > This could be reproduced by setting a small read-timeout and large object > (Put). > Because of this, the put from client succeeds by creating partial data on the > server cache. Since the data is stored in serialized form, there is no > exception thrown during put() operation, giving an impression that put > operation is successful. > The workaround for now is to have large read-timeout setting; while trying to > send a large object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
