[jira] [Commented] (GEODE-8442) Exception in server not identified correctly in client
[
https://issues.apache.org/jira/browse/GEODE-8442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17247168#comment-17247168
]
ASF GitHub Bot commented on GEODE-8442:
---
mkevo opened a new pull request #710:
URL: https://github.com/apache/geode-native/pull/710
HandleReplay is already commented in other functions as replay is
unsupported, this change will not translate the real exception to
UnknownException.
User will got correct exception and will know how to handle 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
> Exception in server not identified correctly in client
> --
>
> Key: GEODE-8442
> URL: https://issues.apache.org/jira/browse/GEODE-8442
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Mario Kevo
>Priority: Major
> Labels: needs-review, pull-request-available
>
> Native client is not identifying correctly an exception returned by the
> server.
> This is a log from an exception properly identified (I have introduced ""
> where I think I have to hide sensitive information):
> {code}
> [error 2020/07/22 09:17:10.831337 UTC ]
> CacheTransactionManager::failover: An exception
> (org.apache.geode.cache.TransactionDataNodeHasDepartedException: Could not
> find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> at
> org.apache.geode.internal.cache.tier.sockets.command.TXFailoverCommand.cmdExecute(TXFailoverCommand.java:126)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> ) happened at remote server.
> data-access: write_element:[TransactionDataNodeHasDepartedException]
> .get()::apache::geode::client::TransactionDataNodeHasDepartedException:org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Could not find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> {code}
> But in this case, although the exception received is also a
> TransactionDataNodeHasDepartedException, it is "translated" to an Unknown
> exception:
> {code}
> [error 2020/07/22 09:17:10.979506 UTC ] Region::containsKeyOnServer:: An
> exception (org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Transaction data node 192.168.240.13(dms-server-1:1):41000 has departed.
> To proceed, rollback this transaction and begin a new one., caused by
> org.apache.geode.internal.cache.ForceReattemptException: PartitionResponse
> got remote CacheClosedException
> at
> org.apache.geode.internal.cache.tx.PartitionedTXRegionStub.containsKey(PartitionedTXRegionStub.java:247)
> at
> org.apache.geode.internal.cache.TXStateStub.containsKey(TXStateStub.java:431)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.containsKey(TXStateProxyImpl.java:530)
> at
> org.apache.geode.internal.cache.PartitionedRegion.containsKey(PartitionedRegion.java:6402)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ContainsKey66.cmdExecute(ContainsKey66.java:138)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.uti
[jira] [Commented] (GEODE-8442) Exception in server not identified correctly in client
[
https://issues.apache.org/jira/browse/GEODE-8442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17247171#comment-17247171
]
ASF GitHub Bot commented on GEODE-8442:
---
mkevo closed pull request #710:
URL: https://github.com/apache/geode-native/pull/710
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
> Exception in server not identified correctly in client
> --
>
> Key: GEODE-8442
> URL: https://issues.apache.org/jira/browse/GEODE-8442
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Mario Kevo
>Priority: Major
> Labels: needs-review, pull-request-available
>
> Native client is not identifying correctly an exception returned by the
> server.
> This is a log from an exception properly identified (I have introduced ""
> where I think I have to hide sensitive information):
> {code}
> [error 2020/07/22 09:17:10.831337 UTC ]
> CacheTransactionManager::failover: An exception
> (org.apache.geode.cache.TransactionDataNodeHasDepartedException: Could not
> find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> at
> org.apache.geode.internal.cache.tier.sockets.command.TXFailoverCommand.cmdExecute(TXFailoverCommand.java:126)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> ) happened at remote server.
> data-access: write_element:[TransactionDataNodeHasDepartedException]
> .get()::apache::geode::client::TransactionDataNodeHasDepartedException:org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Could not find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> {code}
> But in this case, although the exception received is also a
> TransactionDataNodeHasDepartedException, it is "translated" to an Unknown
> exception:
> {code}
> [error 2020/07/22 09:17:10.979506 UTC ] Region::containsKeyOnServer:: An
> exception (org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Transaction data node 192.168.240.13(dms-server-1:1):41000 has departed.
> To proceed, rollback this transaction and begin a new one., caused by
> org.apache.geode.internal.cache.ForceReattemptException: PartitionResponse
> got remote CacheClosedException
> at
> org.apache.geode.internal.cache.tx.PartitionedTXRegionStub.containsKey(PartitionedTXRegionStub.java:247)
> at
> org.apache.geode.internal.cache.TXStateStub.containsKey(TXStateStub.java:431)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.containsKey(TXStateProxyImpl.java:530)
> at
> org.apache.geode.internal.cache.PartitionedRegion.containsKey(PartitionedRegion.java:6402)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ContainsKey66.cmdExecute(ContainsKey66.java:138)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.internal.cache.ti
[jira] [Commented] (GEODE-8442) Exception in server not identified correctly in client
[
https://issues.apache.org/jira/browse/GEODE-8442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17247179#comment-17247179
]
ASF GitHub Bot commented on GEODE-8442:
---
mkevo opened a new pull request #711:
URL: https://github.com/apache/geode-native/pull/711
HandleReplay is already commented in other functions as replay is
unsupported, this change will not translate the real exception to
UnknownException.
User will got correct exception and will know how to handle 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
> Exception in server not identified correctly in client
> --
>
> Key: GEODE-8442
> URL: https://issues.apache.org/jira/browse/GEODE-8442
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Mario Kevo
>Priority: Major
> Labels: needs-review, pull-request-available
>
> Native client is not identifying correctly an exception returned by the
> server.
> This is a log from an exception properly identified (I have introduced ""
> where I think I have to hide sensitive information):
> {code}
> [error 2020/07/22 09:17:10.831337 UTC ]
> CacheTransactionManager::failover: An exception
> (org.apache.geode.cache.TransactionDataNodeHasDepartedException: Could not
> find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> at
> org.apache.geode.internal.cache.tier.sockets.command.TXFailoverCommand.cmdExecute(TXFailoverCommand.java:126)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> ) happened at remote server.
> data-access: write_element:[TransactionDataNodeHasDepartedException]
> .get()::apache::geode::client::TransactionDataNodeHasDepartedException:org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Could not find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> {code}
> But in this case, although the exception received is also a
> TransactionDataNodeHasDepartedException, it is "translated" to an Unknown
> exception:
> {code}
> [error 2020/07/22 09:17:10.979506 UTC ] Region::containsKeyOnServer:: An
> exception (org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Transaction data node 192.168.240.13(dms-server-1:1):41000 has departed.
> To proceed, rollback this transaction and begin a new one., caused by
> org.apache.geode.internal.cache.ForceReattemptException: PartitionResponse
> got remote CacheClosedException
> at
> org.apache.geode.internal.cache.tx.PartitionedTXRegionStub.containsKey(PartitionedTXRegionStub.java:247)
> at
> org.apache.geode.internal.cache.TXStateStub.containsKey(TXStateStub.java:431)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.containsKey(TXStateProxyImpl.java:530)
> at
> org.apache.geode.internal.cache.PartitionedRegion.containsKey(PartitionedRegion.java:6402)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ContainsKey66.cmdExecute(ContainsKey66.java:138)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.uti
[jira] [Commented] (GEODE-8442) Exception in server not identified correctly in client
[
https://issues.apache.org/jira/browse/GEODE-8442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17247180#comment-17247180
]
ASF GitHub Bot commented on GEODE-8442:
---
mkevo closed pull request #711:
URL: https://github.com/apache/geode-native/pull/711
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
> Exception in server not identified correctly in client
> --
>
> Key: GEODE-8442
> URL: https://issues.apache.org/jira/browse/GEODE-8442
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Mario Kevo
>Priority: Major
> Labels: needs-review, pull-request-available
>
> Native client is not identifying correctly an exception returned by the
> server.
> This is a log from an exception properly identified (I have introduced ""
> where I think I have to hide sensitive information):
> {code}
> [error 2020/07/22 09:17:10.831337 UTC ]
> CacheTransactionManager::failover: An exception
> (org.apache.geode.cache.TransactionDataNodeHasDepartedException: Could not
> find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> at
> org.apache.geode.internal.cache.tier.sockets.command.TXFailoverCommand.cmdExecute(TXFailoverCommand.java:126)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> ) happened at remote server.
> data-access: write_element:[TransactionDataNodeHasDepartedException]
> .get()::apache::geode::client::TransactionDataNodeHasDepartedException:org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Could not find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> {code}
> But in this case, although the exception received is also a
> TransactionDataNodeHasDepartedException, it is "translated" to an Unknown
> exception:
> {code}
> [error 2020/07/22 09:17:10.979506 UTC ] Region::containsKeyOnServer:: An
> exception (org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Transaction data node 192.168.240.13(dms-server-1:1):41000 has departed.
> To proceed, rollback this transaction and begin a new one., caused by
> org.apache.geode.internal.cache.ForceReattemptException: PartitionResponse
> got remote CacheClosedException
> at
> org.apache.geode.internal.cache.tx.PartitionedTXRegionStub.containsKey(PartitionedTXRegionStub.java:247)
> at
> org.apache.geode.internal.cache.TXStateStub.containsKey(TXStateStub.java:431)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.containsKey(TXStateProxyImpl.java:530)
> at
> org.apache.geode.internal.cache.PartitionedRegion.containsKey(PartitionedRegion.java:6402)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ContainsKey66.cmdExecute(ContainsKey66.java:138)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.internal.cache.ti
[jira] [Commented] (GEODE-8442) Exception in server not identified correctly in client
[
https://issues.apache.org/jira/browse/GEODE-8442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17247181#comment-17247181
]
ASF GitHub Bot commented on GEODE-8442:
---
mkevo commented on pull request #693:
URL: https://github.com/apache/geode-native/pull/693#issuecomment-742458577
Hi @echobravopapa,
I wrote a test, but now have a problem with LGTM check. I saw on other PR
that this also happened today. Do you maybe know how to fix 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
> Exception in server not identified correctly in client
> --
>
> Key: GEODE-8442
> URL: https://issues.apache.org/jira/browse/GEODE-8442
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Mario Kevo
>Priority: Major
> Labels: needs-review, pull-request-available
>
> Native client is not identifying correctly an exception returned by the
> server.
> This is a log from an exception properly identified (I have introduced ""
> where I think I have to hide sensitive information):
> {code}
> [error 2020/07/22 09:17:10.831337 UTC ]
> CacheTransactionManager::failover: An exception
> (org.apache.geode.cache.TransactionDataNodeHasDepartedException: Could not
> find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> at
> org.apache.geode.internal.cache.tier.sockets.command.TXFailoverCommand.cmdExecute(TXFailoverCommand.java:126)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> ) happened at remote server.
> data-access: write_element:[TransactionDataNodeHasDepartedException]
> .get()::apache::geode::client::TransactionDataNodeHasDepartedException:org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Could not find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> {code}
> But in this case, although the exception received is also a
> TransactionDataNodeHasDepartedException, it is "translated" to an Unknown
> exception:
> {code}
> [error 2020/07/22 09:17:10.979506 UTC ] Region::containsKeyOnServer:: An
> exception (org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Transaction data node 192.168.240.13(dms-server-1:1):41000 has departed.
> To proceed, rollback this transaction and begin a new one., caused by
> org.apache.geode.internal.cache.ForceReattemptException: PartitionResponse
> got remote CacheClosedException
> at
> org.apache.geode.internal.cache.tx.PartitionedTXRegionStub.containsKey(PartitionedTXRegionStub.java:247)
> at
> org.apache.geode.internal.cache.TXStateStub.containsKey(TXStateStub.java:431)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.containsKey(TXStateProxyImpl.java:530)
> at
> org.apache.geode.internal.cache.PartitionedRegion.containsKey(PartitionedRegion.java:6402)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ContainsKey66.cmdExecute(ContainsKey66.java:138)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor
[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=17247283#comment-17247283
]
Geode Integration commented on GEODE-8191:
--
Seen in [DistributedTestOpenJDK8
#691|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/691]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0549/test-results/distributedTest/1607565927/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0549/test-artifacts/1607565927/distributedtestfiles-OpenJDK8-1.14.0-build.0549.tgz].
> 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-6076) CI Failure: WANRollingUpgradeCreateGatewaySenderMixedSiteOneCurrentSiteTwo.CreateGatewaySenderMixedSiteOneCurrentSiteTwo
[
https://issues.apache.org/jira/browse/GEODE-6076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17247284#comment-17247284
]
Geode Integration commented on GEODE-6076:
--
Seen in [UpgradeTestOpenJDK11
#631|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK11/builds/631]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0549/test-results/upgradeTest/1607562049/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0549/test-artifacts/1607562049/upgradetestfiles-OpenJDK11-1.14.0-build.0549.tgz].
> CI Failure:
> WANRollingUpgradeCreateGatewaySenderMixedSiteOneCurrentSiteTwo.CreateGatewaySenderMixedSiteOneCurrentSiteTwo
>
>
> Key: GEODE-6076
> URL: https://issues.apache.org/jira/browse/GEODE-6076
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Jens Deppe
>Priority: Major
>
> {noformat}
> org.apache.geode.cache.wan.WANRollingUpgradeCreateGatewaySenderMixedSiteOneCurrentSiteTwo
> > CreateGatewaySenderMixedSiteOneCurrentSiteTwo[from_v110] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.wan.WANRollingUpgradeCreateGatewaySenderMixedSiteOneCurrentSiteTwo$$Lambda$53/1234278717.call
> in VM 0 running on Host 1d2a3ce05625 with 7 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:433)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:402)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:384)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeCreateGatewaySenderMixedSiteOneCurrentSiteTwo.CreateGatewaySenderMixedSiteOneCurrentSiteTwo(WANRollingUpgradeCreateGatewaySenderMixedSiteOneCurrentSiteTwo.java:92)
> Caused by:
> org.apache.geode.management.ManagementException:
> java.rmi.server.ExportException: Port already in use: 26239; nested exception
> is:
> java.net.BindException: Failed to create server socket on
> 1d2a3ce05625/172.17.0.33[26239]
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:162)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:429)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:173)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:115)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2201)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:606)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1211)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:797)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:783)
> at
> org.apache.geode.cache.CacheFactory.create(CacheFactory.java:176)
> at
> org.apache.geode.cache.CacheFactory.create(CacheFactory.java:223)
> at
> org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:652)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:639)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:326)
> 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.startLocatorWithJmxManager(WANRollingUpgradeDUnitTest.java:112)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeCreateGatewaySenderMixedSiteOneCurrentSiteTwo.lambda$CreateGatewaySenderMixedSiteOneCurrentSiteTwo$e0147a59$1(WANRollingUpgradeCreateGatewaySenderMixedSiteOneCurrentSiteTwo.java:92)
> Caused by:
> java.rmi.server.ExportException: Port already in use: 26239;
> nested exception is:
> java.net.BindException: Failed to create server socket on
> 1d2a3ce05625/172.17.0.33[26239]
> at
> sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:346)
> at
> sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:254)
> at
> sun.rmi.transport.tcp.TCPEndpo
[jira] [Created] (GEODE-8779) There is no need in session management to send events back to clients if local cache is not enabled
Eric Shu created GEODE-8779: --- Summary: There is no need in session management to send events back to clients if local cache is not enabled Key: GEODE-8779 URL: https://issues.apache.org/jira/browse/GEODE-8779 Project: Geode Issue Type: Bug Components: http session Reporter: Eric Shu The original case to send events back to empty proxy client is no longer needed. Hence it should be removed to avoid unnecessary message sending. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8779) There is no need in session management to send events back to clients if local cache is not enabled
[ https://issues.apache.org/jira/browse/GEODE-8779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reassigned GEODE-8779: --- Assignee: Eric Shu > There is no need in session management to send events back to clients if > local cache is not enabled > --- > > Key: GEODE-8779 > URL: https://issues.apache.org/jira/browse/GEODE-8779 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > > The original case to send events back to empty proxy client is no longer > needed. Hence it should be removed to avoid unnecessary message sending. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8779) There is no need in session management to send events back to clients if local cache is not enabled
[ https://issues.apache.org/jira/browse/GEODE-8779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17247411#comment-17247411 ] ASF GitHub Bot commented on GEODE-8779: --- pivotal-eshu opened a new pull request #5836: URL: https://github.com/apache/geode/pull/5836 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 > There is no need in session management to send events back to clients if > local cache is not enabled > --- > > Key: GEODE-8779 > URL: https://issues.apache.org/jira/browse/GEODE-8779 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > > The original case to send events back to empty proxy client is no longer > needed. Hence it should be removed to avoid unnecessary message sending. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8779) There is no need in session management to send events back to clients if local cache is not enabled
[ https://issues.apache.org/jira/browse/GEODE-8779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8779: -- Labels: pull-request-available (was: ) > There is no need in session management to send events back to clients if > local cache is not enabled > --- > > Key: GEODE-8779 > URL: https://issues.apache.org/jira/browse/GEODE-8779 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > > The original case to send events back to empty proxy client is no longer > needed. Hence it should be removed to avoid unnecessary message sending. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8664) JGroups exception is not propagated
[
https://issues.apache.org/jira/browse/GEODE-8664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17247412#comment-17247412
]
Owen Nichols commented on GEODE-8664:
-
Just asking since Affects Version was listed as 1.12 and 1.13
Anyone can propose a backport on the dev list, there is some guidance here:
https://cwiki.apache.org/confluence/display/GEODE/Shipping+patch+releases
> JGroups exception is not propagated
> ---
>
> Key: GEODE-8664
> URL: https://issues.apache.org/jira/browse/GEODE-8664
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.14.0
>
> Attachments: GEODE-8664.patch
>
>
> *AS A* geode contributor
> *I WANT* exceptions thrown in DistributionImpl.start to be propagated
> *SO THAT* more information is provided while tackling issues.
>
>
> *Additional information:*
> After looking at an issue while starting a locator having to do with
> JGroupMessenger I noticed that exceptions from Membership.start are not
> correctly propagated in DistributionImpl.start method.
> To ilustrate the problem I attach below the reported exception while starting
> the locator:
>
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.GemFireConfigException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:184)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3033)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:743)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:388)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:623)
> at
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:217){noformat}
>
> Thing is with that kind of information there's no way to know why the problem
> is happening, so the idea would be to propagate the exceptions, so it looks
> more like this:
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.SystemConnectException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:186)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3034)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:743)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:388)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:623)
> at org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:217)
> Caused by: java.lang.Excep
[jira] [Commented] (GEODE-8765) NullPointerException if group-transaction-events enabled and mix of puts with transactions and without transactions
[
https://issues.apache.org/jira/browse/GEODE-8765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17247444#comment-17247444
]
ASF GitHub Bot commented on GEODE-8765:
---
DonalEvans commented on a change in pull request #5829:
URL: https://github.com/apache/geode/pull/5829#discussion_r540364988
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/wan/parallel/ParallelGatewaySenderQueue.java
##
@@ -1389,6 +1383,21 @@ private void
peekEventsFromIncompleteTransactions(List b
}
}
+ private Map getIncompleteTransactionsInBatch(List
batch) {
Review comment:
The compiler warning here can be fixed if `List`
is used as the method argument. This also means that the for loop below can be
replaced with
```
for (GatewaySenderEventImpl event : batch) {
```
and the cast to `GatewaySenderEventImpl` can be removed.
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/wan/parallel/ParallelGatewaySenderQueue.java
##
@@ -1389,6 +1383,21 @@ private void
peekEventsFromIncompleteTransactions(List b
}
}
+ private Map getIncompleteTransactionsInBatch(List
batch) {
+Map incompleteTransactionsInBatch = new
HashMap<>();
+for (Object object : batch) {
+ GatewaySenderEventImpl event = (GatewaySenderEventImpl) object;
+ if (event.getTransactionId() != null) {
+if (event.isLastEventInTransaction()) {
+ incompleteTransactionsInBatch.remove(event.getTransactionId());
+} else {
+ incompleteTransactionsInBatch.put(event.getTransactionId(),
event.getBucketId());
+}
+ }
+}
+return incompleteTransactionsInBatch;
+ }
+
private boolean areAllTransactionsCompleteInBatch(Map
incompleteTransactions) {
Review comment:
While not part of the changes in this PR, this method could be inlined,
since it's used in only one place and is only one line.
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/wan/serial/SerialGatewaySenderQueue.java
##
@@ -534,6 +523,23 @@ private boolean areAllTransactionsCompleteInBatch(Set
incompleteTransactions) {
return (incompleteTransactions.size() == 0);
Review comment:
As with the similar method in `ParallelGatewaySenderQueue`, this method
could also be inlined.
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/wan/serial/SerialGatewaySenderQueue.java
##
@@ -487,12 +476,12 @@ public Object peek() throws CacheException {
// so no need to worry about off-heap refCount.
}
- private void peekEventsFromIncompleteTransactions(List batch,
- Set incompleteTransactionIdsInBatch, long lastKey) {
+ private void peekEventsFromIncompleteTransactions(List batch,
long lastKey) {
Review comment:
The compiler warning on this line and several others can be resolved by
making `batch` a `List>` here and the other places it's used.
The lines requiring this change are 416, 421, 431-432, 438, 479 and 526.
##
File path:
geode-core/src/test/java/org/apache/geode/internal/cache/BucketRegionQueueJUnitTest.java
##
@@ -148,6 +149,7 @@ public void
testGetElementsMatchingWithHasTransactionIdPredicateAndIsLastEventIn
TransactionId tx3 = new TXId(null, 3);
GatewaySenderEventImpl event1 = createMockGatewaySenderEvent(1, tx1,
false);
+GatewaySenderEventImpl eventNotInTransaction1 =
createMockGatewaySenderEvent(8, null, false);
Review comment:
To make the numbering a little more consistent, could this event's key
be 2, and the subsequent events have their key values increased by 1? That way
the calls to `bucketRegionQueue.addToQueue()` will have matching keys with the
keys here.
##
File path:
geode-core/src/test/java/org/apache/geode/internal/cache/BucketRegionQueueJUnitTest.java
##
@@ -159,17 +161,18 @@ public void
testGetElementsMatchingWithHasTransactionIdPredicateAndIsLastEventIn
.cleanUpDestroyedTokensAndMarkGIIComplete(InitialImageOperation.GIIStatus.NO_GII);
this.bucketRegionQueue.addToQueue(Long.valueOf(1), event1);
-this.bucketRegionQueue.addToQueue(Long.valueOf(2), event2);
-this.bucketRegionQueue.addToQueue(Long.valueOf(3), event3);
-this.bucketRegionQueue.addToQueue(Long.valueOf(4), event4);
-this.bucketRegionQueue.addToQueue(Long.valueOf(5), event5);
-this.bucketRegionQueue.addToQueue(Long.valueOf(6), event6);
-this.bucketRegionQueue.addToQueue(Long.valueOf(7), event7);
+this.bucketRegionQueue.addToQueue(Long.valueOf(2), eventNotInTransaction1);
+this.bucketRegionQueue.addToQueue(Long.valueOf(3), event2);
+this.bucketRegionQueue.addToQueue(Long.valueOf(4), event3);
+this.bucketRegionQueue.addToQueue(Long.valueOf(5), event4);
+this.bucketRegionQueue.addToQueue(Long.valueOf(6), event5);
+this.bucketRegionQueu
[jira] [Assigned] (GEODE-8780) Current default number of function execution threads setting is rather low and could be increased
[
https://issues.apache.org/jira/browse/GEODE-8780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu reassigned GEODE-8780:
---
Assignee: Eric Shu
> Current default number of function execution threads setting is rather low
> and could be increased
> -
>
> Key: GEODE-8780
> URL: https://issues.apache.org/jira/browse/GEODE-8780
> Project: Geode
> Issue Type: Bug
> Components: functions
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
>
> The default number of function execution threads setting is 16 or based on
> the number of processors.
> int MAX_FE_THREADS = Integer.getInteger("DistributionManager.MAX_FE_THREADS",
> Math.max(Runtime.getRuntime().availableProcessors() * 4, 16));
> If not enough function thread is available, a new function execution thread
> is created after 5 seconds wait to handle the function execution request. It
> is better to have this default to be increased.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8780) Current default number of function execution threads setting is rather low and could be increased
Eric Shu created GEODE-8780:
---
Summary: Current default number of function execution threads
setting is rather low and could be increased
Key: GEODE-8780
URL: https://issues.apache.org/jira/browse/GEODE-8780
Project: Geode
Issue Type: Bug
Components: functions
Reporter: Eric Shu
The default number of function execution threads setting is 16 or based on the
number of processors.
int MAX_FE_THREADS = Integer.getInteger("DistributionManager.MAX_FE_THREADS",
Math.max(Runtime.getRuntime().availableProcessors() * 4, 16));
If not enough function thread is available, a new function execution thread is
created after 5 seconds wait to handle the function execution request. It is
better to have this default to be increased.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8780) Current default number of function execution threads setting is rather low and could be increased
[
https://issues.apache.org/jira/browse/GEODE-8780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17247515#comment-17247515
]
ASF GitHub Bot commented on GEODE-8780:
---
pivotal-eshu opened a new pull request #5837:
URL: https://github.com/apache/geode/pull/5837
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
> Current default number of function execution threads setting is rather low
> and could be increased
> -
>
> Key: GEODE-8780
> URL: https://issues.apache.org/jira/browse/GEODE-8780
> Project: Geode
> Issue Type: Bug
> Components: functions
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
>
> The default number of function execution threads setting is 16 or based on
> the number of processors.
> int MAX_FE_THREADS = Integer.getInteger("DistributionManager.MAX_FE_THREADS",
> Math.max(Runtime.getRuntime().availableProcessors() * 4, 16));
> If not enough function thread is available, a new function execution thread
> is created after 5 seconds wait to handle the function execution request. It
> is better to have this default to be increased.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8780) Current default number of function execution threads setting is rather low and could be increased
[
https://issues.apache.org/jira/browse/GEODE-8780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8780:
--
Labels: pull-request-available (was: )
> Current default number of function execution threads setting is rather low
> and could be increased
> -
>
> Key: GEODE-8780
> URL: https://issues.apache.org/jira/browse/GEODE-8780
> Project: Geode
> Issue Type: Bug
> Components: functions
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: pull-request-available
>
> The default number of function execution threads setting is 16 or based on
> the number of processors.
> int MAX_FE_THREADS = Integer.getInteger("DistributionManager.MAX_FE_THREADS",
> Math.max(Runtime.getRuntime().availableProcessors() * 4, 16));
> If not enough function thread is available, a new function execution thread
> is created after 5 seconds wait to handle the function execution request. It
> is better to have this default to be increased.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8781) The Tomcat session state module in P2P mode doesn't re-establish the session region after a reconnect
Barrett Oglesby created GEODE-8781: -- Summary: The Tomcat session state module in P2P mode doesn't re-establish the session region after a reconnect Key: GEODE-8781 URL: https://issues.apache.org/jira/browse/GEODE-8781 Project: Geode Issue Type: Bug Components: http session Reporter: Barrett Oglesby In the PeerToPeerSessionCache, the createOrRetrieveRegion method creates the region when the Tomcat server is started. The PeerToPeerSessionCache stores this region in a field called sessionRegion. It also stores the cache in a field called cache, and the fronting region in a field called operatingRegion if local caching is enabled. When the DistributedSystem is disconnected, the cache and its regions are closed. When the DistributedSystem is reconnected, the cache is recreated but not the regions. This is because they were created using API rather than in XML or cluster configuration. This can be changed by setting use-cluster-configuration=false, but it won't really make a difference. Thats because the PeerToPeerSessionCache's references are to the closed cache and regions. Adding a ReconnectListener to the PeerToPeerSessionCache so that these references are re-established will address this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8781) The Tomcat session state module in P2P mode doesn't re-establish the session region after a reconnect
[ https://issues.apache.org/jira/browse/GEODE-8781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8781: -- Labels: pull-request-available (was: ) > The Tomcat session state module in P2P mode doesn't re-establish the session > region after a reconnect > - > > Key: GEODE-8781 > URL: https://issues.apache.org/jira/browse/GEODE-8781 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: Barrett Oglesby >Priority: Major > Labels: pull-request-available > > In the PeerToPeerSessionCache, the createOrRetrieveRegion method creates the > region when the Tomcat server is started. > The PeerToPeerSessionCache stores this region in a field called > sessionRegion. It also stores the cache in a field called cache, and the > fronting region in a field called operatingRegion if local caching is enabled. > When the DistributedSystem is disconnected, the cache and its regions are > closed. > When the DistributedSystem is reconnected, the cache is recreated but not the > regions. This is because they were created using API rather than in XML or > cluster configuration. This can be changed by setting > use-cluster-configuration=false, but it won't really make a difference. > Thats because the PeerToPeerSessionCache's references are to the closed cache > and regions. > Adding a ReconnectListener to the PeerToPeerSessionCache so that these > references are re-established will address this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8781) The Tomcat session state module in P2P mode doesn't re-establish the session region after a reconnect
[ https://issues.apache.org/jira/browse/GEODE-8781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17247536#comment-17247536 ] ASF GitHub Bot commented on GEODE-8781: --- boglesby opened a new pull request #5838: URL: https://github.com/apache/geode/pull/5838 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 > The Tomcat session state module in P2P mode doesn't re-establish the session > region after a reconnect > - > > Key: GEODE-8781 > URL: https://issues.apache.org/jira/browse/GEODE-8781 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: Barrett Oglesby >Priority: Major > > In the PeerToPeerSessionCache, the createOrRetrieveRegion method creates the > region when the Tomcat server is started. > The PeerToPeerSessionCache stores this region in a field called > sessionRegion. It also stores the cache in a field called cache, and the > fronting region in a field called operatingRegion if local caching is enabled. > When the DistributedSystem is disconnected, the cache and its regions are > closed. > When the DistributedSystem is reconnected, the cache is recreated but not the > regions. This is because they were created using API rather than in XML or > cluster configuration. This can be changed by setting > use-cluster-configuration=false, but it won't really make a difference. > Thats because the PeerToPeerSessionCache's references are to the closed cache > and regions. > Adding a ReconnectListener to the PeerToPeerSessionCache so that these > references are re-established will address this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8781) The Tomcat session state module in P2P mode doesn't re-establish the session region after a reconnect
[ https://issues.apache.org/jira/browse/GEODE-8781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17247538#comment-17247538 ] ASF subversion and git services commented on GEODE-8781: Commit f8b2cae2376c944064ff03bcc2260694d801ca85 in geode's branch refs/heads/feature/GEODE-8781 from Barry Oglesby [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f8b2cae ] GEODE-8781: Added ReconnectListener to PeerToPeerSessionCache > The Tomcat session state module in P2P mode doesn't re-establish the session > region after a reconnect > - > > Key: GEODE-8781 > URL: https://issues.apache.org/jira/browse/GEODE-8781 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: Barrett Oglesby >Priority: Major > Labels: pull-request-available > > In the PeerToPeerSessionCache, the createOrRetrieveRegion method creates the > region when the Tomcat server is started. > The PeerToPeerSessionCache stores this region in a field called > sessionRegion. It also stores the cache in a field called cache, and the > fronting region in a field called operatingRegion if local caching is enabled. > When the DistributedSystem is disconnected, the cache and its regions are > closed. > When the DistributedSystem is reconnected, the cache is recreated but not the > regions. This is because they were created using API rather than in XML or > cluster configuration. This can be changed by setting > use-cluster-configuration=false, but it won't really make a difference. > Thats because the PeerToPeerSessionCache's references are to the closed cache > and regions. > Adding a ReconnectListener to the PeerToPeerSessionCache so that these > references are re-established will address this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8713) Geode-Native .NET user guide: API reference links point to C++ API
[ https://issues.apache.org/jira/browse/GEODE-8713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17247552#comment-17247552 ] ASF subversion and git services commented on GEODE-8713: Commit 3ac51c83192645152d0632733f7a12f15d9365c6 in geode-native's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=3ac51c8 ] GEODE-8713: .NET user guide - API reference links - fix redirects when published on Geode website (#709) > Geode-Native .NET user guide: API reference links point to C++ API > -- > > Key: GEODE-8713 > URL: https://issues.apache.org/jira/browse/GEODE-8713 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.13.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > The "Client Cache XML Reference" section in the .NET user guide contains > links to "API Class Reference" that all point to the C++ API ref. These > should point to the .NET API ref. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8713) Geode-Native .NET user guide: API reference links point to C++ API
[ https://issues.apache.org/jira/browse/GEODE-8713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17247553#comment-17247553 ] ASF GitHub Bot commented on GEODE-8713: --- davebarnes97 merged pull request #709: URL: https://github.com/apache/geode-native/pull/709 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 > Geode-Native .NET user guide: API reference links point to C++ API > -- > > Key: GEODE-8713 > URL: https://issues.apache.org/jira/browse/GEODE-8713 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.13.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > The "Client Cache XML Reference" section in the .NET user guide contains > links to "API Class Reference" that all point to the C++ API ref. These > should point to the .NET API ref. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8713) Geode-Native .NET user guide: API reference links point to C++ API
[ https://issues.apache.org/jira/browse/GEODE-8713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes resolved GEODE-8713. Resolution: Fixed Second fix to address a problem encountered when posting to the Geode website. > Geode-Native .NET user guide: API reference links point to C++ API > -- > > Key: GEODE-8713 > URL: https://issues.apache.org/jira/browse/GEODE-8713 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.13.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > The "Client Cache XML Reference" section in the .NET user guide contains > links to "API Class Reference" that all point to the C++ API ref. These > should point to the .NET API ref. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8442) Exception in server not identified correctly in client
[
https://issues.apache.org/jira/browse/GEODE-8442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17247558#comment-17247558
]
ASF GitHub Bot commented on GEODE-8442:
---
moleske commented on pull request #693:
URL: https://github.com/apache/geode-native/pull/693#issuecomment-742862808
> I wrote a test, but now have a problem with LGTM check. I saw on other PR
that this also happened today. Do you maybe know how to fix it?
Looking a [the output of
LGTM](https://lgtm.com/projects/g/apache/geode-native/logs/rev/pr-d830587f41dd9f18339edc0e8866570fd9e44ab6/lang:cpp/stage:Build%20merge_d3f6b1592a01fd440ae19b9cb4772495d3f37649),
it seems like it failed to merge with develop. When I've hit this in the
past, a rebase usually solves the problem.
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
> Exception in server not identified correctly in client
> --
>
> Key: GEODE-8442
> URL: https://issues.apache.org/jira/browse/GEODE-8442
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Mario Kevo
>Priority: Major
> Labels: needs-review, pull-request-available
>
> Native client is not identifying correctly an exception returned by the
> server.
> This is a log from an exception properly identified (I have introduced ""
> where I think I have to hide sensitive information):
> {code}
> [error 2020/07/22 09:17:10.831337 UTC ]
> CacheTransactionManager::failover: An exception
> (org.apache.geode.cache.TransactionDataNodeHasDepartedException: Could not
> find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> at
> org.apache.geode.internal.cache.tier.sockets.command.TXFailoverCommand.cmdExecute(TXFailoverCommand.java:126)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> ) happened at remote server.
> data-access: write_element:[TransactionDataNodeHasDepartedException]
> .get()::apache::geode::client::TransactionDataNodeHasDepartedException:org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Could not find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> {code}
> But in this case, although the exception received is also a
> TransactionDataNodeHasDepartedException, it is "translated" to an Unknown
> exception:
> {code}
> [error 2020/07/22 09:17:10.979506 UTC ] Region::containsKeyOnServer:: An
> exception (org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Transaction data node 192.168.240.13(dms-server-1:1):41000 has departed.
> To proceed, rollback this transaction and begin a new one., caused by
> org.apache.geode.internal.cache.ForceReattemptException: PartitionResponse
> got remote CacheClosedException
> at
> org.apache.geode.internal.cache.tx.PartitionedTXRegionStub.containsKey(PartitionedTXRegionStub.java:247)
> at
> org.apache.geode.internal.cache.TXStateStub.containsKey(TXStateStub.java:431)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.containsKey(TXStateProxyImpl.java:530)
> at
> org.apache.geode.internal.cache.PartitionedRegion.containsKey(PartitionedRegion.java:6402)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ContainsKey66.cmdExecute(ContainsKey66.java:138)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.jav
[jira] [Commented] (GEODE-8780) Current default number of function execution threads setting is rather low and could be increased
[
https://issues.apache.org/jira/browse/GEODE-8780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17247559#comment-17247559
]
ASF GitHub Bot commented on GEODE-8780:
---
pivotal-eshu commented on pull request #5837:
URL: https://github.com/apache/geode/pull/5837#issuecomment-742864483
> Might it be worth adding a test case to confirm that when the
`DistributionManager.MAX_FE_THREADS` property is set, that value is used? Also,
it looks like that property is documented in `properties.html`, so that file
should probably be updated to reflect the new default value. Is there a reason
that there's no other documentation for this property?
Change the default value in the properties.html. I am not sure why there is
no other documentation for this property.
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
> Current default number of function execution threads setting is rather low
> and could be increased
> -
>
> Key: GEODE-8780
> URL: https://issues.apache.org/jira/browse/GEODE-8780
> Project: Geode
> Issue Type: Bug
> Components: functions
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: pull-request-available
>
> The default number of function execution threads setting is 16 or based on
> the number of processors.
> int MAX_FE_THREADS = Integer.getInteger("DistributionManager.MAX_FE_THREADS",
> Math.max(Runtime.getRuntime().availableProcessors() * 4, 16));
> If not enough function thread is available, a new function execution thread
> is created after 5 seconds wait to handle the function execution request. It
> is better to have this default to be increased.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8769) CI Failure: org.apache.geode.redis.internal.RedisStatsIntegrationTest > clientsStat_withConnectAndClose_isCorrect FAILED
[
https://issues.apache.org/jira/browse/GEODE-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17247562#comment-17247562
]
ASF GitHub Bot commented on GEODE-8769:
---
jdeppe-pivotal commented on a change in pull request #5818:
URL: https://github.com/apache/geode/pull/5818#discussion_r540579542
##
File path:
geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/RedisStatsIntegrationTest.java
##
@@ -468,33 +479,33 @@ public void
NetworkKiloBytesReadOverLastSecond_shouldReturnCorrectData() {
}
-
// # Clients Section
#
@Test
public void clientsStat_withConnectAndClose_isCorrect() {
-jedis = new Jedis("localhost", server.getPort(), TIMEOUT);
-jedis.ping();
+Jedis jedis2 = new Jedis("localhost", server.getPort(), TIMEOUT);
+jedis2.ping();
-assertThat(redisStats.getConnectedClients()).isEqualTo(1);
+
assertThat(redisStats.getConnectedClients()).isEqualTo(preTestConnectedClients
+ 1);
-jedis.close();
+jedis2.close();
GeodeAwaitility.await().atMost(Duration.ofSeconds(2))
-.untilAsserted(() ->
assertThat(redisStats.getConnectedClients()).isEqualTo(0));
+.untilAsserted(
+() ->
assertThat(redisStats.getConnectedClients()).isEqualTo(preTestConnectedClients));
}
@Test
public void
connectionsReceivedStat_shouldIncrement_WhenNewConnectionOccurs() {
-jedis = new Jedis("localhost", server.getPort(), TIMEOUT);
-jedis.ping();
+Jedis jedis2 = new Jedis("localhost", server.getPort(), TIMEOUT);
+jedis2.ping();
-assertThat(redisStats.getConnectionsReceived()).isEqualTo(1);
+
assertThat(redisStats.getConnectionsReceived()).isEqualTo(preTestConnectionsReceived
+ 1);
-jedis.close();
+jedis2.close();
-assertThat(redisStats.getConnectionsReceived()).isEqualTo(1);
+
assertThat(redisStats.getConnectionsReceived()).isEqualTo(preTestConnectionsReceived
+ 1);
Review comment:
I don't think this assertion is correct. It should be doing what the
previous test is doing:
```
GeodeAwaitility.await().atMost(Duration.ofSeconds(2))
.untilAsserted(() ->
assertThat(redisStats.getConnectedClients()).isEqualTo(preTestConnectedClients));
```
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: org.apache.geode.redis.internal.RedisStatsIntegrationTest >
> clientsStat_withConnectAndClose_isCorrect FAILED
>
>
> Key: GEODE-8769
> URL: https://issues.apache.org/jira/browse/GEODE-8769
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0
>Reporter: Raymond Ingles
>Assignee: Raymond Ingles
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK8/builds/592
> org.apache.geode.redis.internal.RedisStatsIntegrationTest >
> clientsStat_withConnectAndClose_isCorrect FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.redis.internal.RedisStatsIntegrationTest expected:<[0]L> but
> was:<[-2]L> within 2 seconds.
> 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.redis.internal.RedisStatsIntegrationTest.clientsStat_withConnectAndClose_isCorrect(RedisStatsIntegrationTest.java:484)
> Caused by:
> org.junit.ComparisonFailure: expected:<[0]L> but was:<[-2]L>
> at sun.reflect.GeneratedConstructorAccessor31.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.redis.internal.RedisStatsIntegrationTest.lambda$clientsStat_withConnectAndClose_isCorrect$4(RedisStatsIntegrationTest.java:484)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7861) Improve error reporting when a member is unable to contact a locator
[
https://issues.apache.org/jira/browse/GEODE-7861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-7861:
--
Labels: pull-request-available (was: )
> Improve error reporting when a member is unable to contact a locator
>
>
> Key: GEODE-7861
> URL: https://issues.apache.org/jira/browse/GEODE-7861
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Dan Smith
>Priority: Major
> Labels: pull-request-available
>
> When a member is unable to contact a join the system due to a failure to
> contact a locator, we could be a lot more specific, which would help users
> debug issues in their environment. We currently print out
> {noformat}
> Unable to join the distributed system. Operation either timed out, was
> stopped or Locator does not exist.
> {noformat}
> We should include the underlying exception from the last locator we tried to
> contact as a cause, so that users can see why it failed (DNS error, ???).
> Perhaps also the list of locators we tried to contact.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7861) Improve error reporting when a member is unable to contact a locator
[
https://issues.apache.org/jira/browse/GEODE-7861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17247563#comment-17247563
]
ASF GitHub Bot commented on GEODE-7861:
---
kamilla1201 opened a new pull request #5839:
URL: https://github.com/apache/geode/pull/5839
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
> Improve error reporting when a member is unable to contact a locator
>
>
> Key: GEODE-7861
> URL: https://issues.apache.org/jira/browse/GEODE-7861
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Dan Smith
>Priority: Major
>
> When a member is unable to contact a join the system due to a failure to
> contact a locator, we could be a lot more specific, which would help users
> debug issues in their environment. We currently print out
> {noformat}
> Unable to join the distributed system. Operation either timed out, was
> stopped or Locator does not exist.
> {noformat}
> We should include the underlying exception from the last locator we tried to
> contact as a cause, so that users can see why it failed (DNS error, ???).
> Perhaps also the list of locators we tried to contact.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8442) Exception in server not identified correctly in client
[
https://issues.apache.org/jira/browse/GEODE-8442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17247719#comment-17247719
]
ASF GitHub Bot commented on GEODE-8442:
---
mkevo commented on pull request #693:
URL: https://github.com/apache/geode-native/pull/693#issuecomment-743028961
Hi @moleske ,
I tried with rebase, bit the same thing happened.
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
> Exception in server not identified correctly in client
> --
>
> Key: GEODE-8442
> URL: https://issues.apache.org/jira/browse/GEODE-8442
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Mario Kevo
>Priority: Major
> Labels: needs-review, pull-request-available
>
> Native client is not identifying correctly an exception returned by the
> server.
> This is a log from an exception properly identified (I have introduced ""
> where I think I have to hide sensitive information):
> {code}
> [error 2020/07/22 09:17:10.831337 UTC ]
> CacheTransactionManager::failover: An exception
> (org.apache.geode.cache.TransactionDataNodeHasDepartedException: Could not
> find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> at
> org.apache.geode.internal.cache.tier.sockets.command.TXFailoverCommand.cmdExecute(TXFailoverCommand.java:126)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> ) happened at remote server.
> data-access: write_element:[TransactionDataNodeHasDepartedException]
> .get()::apache::geode::client::TransactionDataNodeHasDepartedException:org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Could not find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> {code}
> But in this case, although the exception received is also a
> TransactionDataNodeHasDepartedException, it is "translated" to an Unknown
> exception:
> {code}
> [error 2020/07/22 09:17:10.979506 UTC ] Region::containsKeyOnServer:: An
> exception (org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Transaction data node 192.168.240.13(dms-server-1:1):41000 has departed.
> To proceed, rollback this transaction and begin a new one., caused by
> org.apache.geode.internal.cache.ForceReattemptException: PartitionResponse
> got remote CacheClosedException
> at
> org.apache.geode.internal.cache.tx.PartitionedTXRegionStub.containsKey(PartitionedTXRegionStub.java:247)
> at
> org.apache.geode.internal.cache.TXStateStub.containsKey(TXStateStub.java:431)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.containsKey(TXStateProxyImpl.java:530)
> at
> org.apache.geode.internal.cache.PartitionedRegion.containsKey(PartitionedRegion.java:6402)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ContainsKey66.cmdExecute(ContainsKey66.java:138)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolEx
