[jira] [Commented] (GEODE-8480) Add tx manager check in geode-native transaction example
[
https://issues.apache.org/jira/browse/GEODE-8480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17194116#comment-17194116
]
ASF GitHub Bot commented on GEODE-8480:
---
alb3rtobr commented on pull request #648:
URL: https://github.com/apache/geode-native/pull/648#issuecomment-690971310
I was running a test consisting on killing a Geode server while a C++ client
with several threads was executing transactions. I observed that most of the
times, the client died after killing the server with following error in logs:
```
[error 2020/09/01 10:31:05.977905 CEST alb3rtobr-XPS:7395 139697166743296]
Unexpected exception during completing transaction : illegal State
terminate called after throwing an instance of
'apache::geode::client::Exception'
terminate called recursively
what(): : illegal State
```
I was not sure about what was happening, but I had the feeling that I was
doing something wrong, because I would not expect that the client was dying in
this scenario. When I was taking a look at the transaction page in the Geode
documentation, I realized that in Java, the transaction example includes the
call to the `exists()` method ([link to the
doc](https://geode.apache.org/docs/guide/112/developing/transactions/directed_example.html))
before performing rollback.
```
if(txManager.exists()) {
txManager.rollback();
}
```
I added the call to the function to my C++ client and the problem was
solved. After that the client was showing some exceptions when one of the
server was killed, but the client was not dying. So I felt that calling to this
`exists()`method was something to be done in transactions and that it was
missing from the C++ documentation.
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
> Add tx manager check in geode-native transaction example
>
>
> Key: GEODE-8480
> URL: https://issues.apache.org/jira/browse/GEODE-8480
> Project: Geode
> Issue Type: Improvement
> Components: docs, native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Minor
> Labels: pull-request-available
>
> Transactions documentation & example in the geode C++ client is not checking
> if the transaction manager exists before calling to rollback, as it is done
> in the transactions documentation and example in geode.
> I have seen that depending on the exception, the rollback can generate an
> error so I think its something that should be added to the example.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-5601) AcceptanceTests are run in parallel without using containers, resulting in port conflicts
[
https://issues.apache.org/jira/browse/GEODE-5601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe reassigned GEODE-5601:
-
Assignee: Jens Deppe (was: Ken Howe)
> AcceptanceTests are run in parallel without using containers, resulting in
> port conflicts
> -
>
> Key: GEODE-5601
> URL: https://issues.apache.org/jira/browse/GEODE-5601
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Jacob Barrett
>Assignee: Jens Deppe
>Priority: Major
> Labels: flaky, pull-request-available, swat
> Fix For: 1.7.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {noformat}
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest >
> deployLargeSetOfJars FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:117)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:135)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:106)
> at
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.deployLargeSetOfJars(DeployWithLargeJarTest.java:41)
> {noformat}
> Passes:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/AcceptanceTest/builds/721
> Fails:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/AcceptanceTest/builds/728
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8482) Concurrent access to ArrayList should be synchronized
[
https://issues.apache.org/jira/browse/GEODE-8482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17194338#comment-17194338
]
ASF GitHub Bot commented on GEODE-8482:
---
agingade commented on a change in pull request #5503:
URL: https://github.com/apache/geode/pull/5503#discussion_r487130937
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/control/InternalResourceManager.java
##
@@ -637,7 +638,9 @@ private ThreadsMonitoring getThreadMonitorObj() {
*/
public void addStartupTask(CompletableFuture startupTask) {
Objects.requireNonNull(startupTask);
-startupTasks.add(startupTask);
+synchronized (startupTasks) {
Review comment:
Can this be achieved by changing startupTasks to CopyOnWriteArrayList.
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
> Concurrent access to ArrayList should be synchronized
> -
>
> Key: GEODE-8482
> URL: https://issues.apache.org/jira/browse/GEODE-8482
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Jianxia Chen
>Assignee: Jianxia Chen
>Priority: Major
> Labels: pull-request-available
>
> We have seen ArrayIndexOutOfBoundsException when multiple threads access
> ArrayList.
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:598)
> at
> java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:677)
> at java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:735)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:160)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:583)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.createDiskStores(CacheCreation.java:647)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:531)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:339)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4200)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1621)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1447)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> at
> org.apache.geode.internal.cache.CacheFactoryStatics.create(CacheFactoryStatics.java:61)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:352)
>
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 15
> at java.util.ArrayList.add(ArrayList.java:465)
> at
> org.apache.geode.internal.cache.control.InternalResourceManager.addStartupTask(InternalResourceManager.java:640)
> at
> org.apache.geode.internal.cache.DiskStoreImpl.scheduleValueRecovery(DiskStoreImpl.java:2088)
> at
> org.apache.geode.internal.cache.PersistentOplogSet.recoverOplogs(PersistentOplogSet.java:520)
> at
> org.apache.geode.internal.cache.PersistentOplogSet.recoverRegionsThatAreReady(PersistentOplogSet.java:379)
> at
> org.apache.geode.internal.cache.DiskStoreImpl.recoverRegionsThatAreReady(DiskStoreImpl.java:2076)
> at
> org.apache.geode.internal.cache.DiskStoreImpl.initializeIfNeeded(DiskStoreImpl.java:2064)
> at
> org.apache.geode.internal.cache.DiskStoreImpl.doInitialRecovery(DiskStoreImpl.java:2069)
> at
> org.apache.geode.internal.cache.DiskStoreFactoryImpl.initializeDiskStore(DiskStoreFactoryImpl.java:192)
> at
> org.apache.geode.internal.cache.DiskStoreFactoryImpl.create(DiskStoreFactoryImpl.java:156)
> at
> org.apache.
[jira] [Commented] (GEODE-8293) activeCQCount has negative value
[
https://issues.apache.org/jira/browse/GEODE-8293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17194359#comment-17194359
]
ASF GitHub Bot commented on GEODE-8293:
---
agingade commented on a change in pull request #5397:
URL: https://github.com/apache/geode/pull/5397#discussion_r487137679
##
File path:
geode-cq/src/main/java/org/apache/geode/cache/query/cq/internal/ServerCQImpl.java
##
@@ -367,10 +367,12 @@ public void close(boolean sendRequestToServer) throws
CqClosedException, CqExcep
this.removeFromCqMap();
// Stat update.
- if (stateBeforeClosing == CqStateImpl.RUNNING) {
-cqService.stats().decCqsActive();
- } else if (stateBeforeClosing == CqStateImpl.STOPPED) {
-cqService.stats().decCqsStopped();
+ if (!cqName.equals(serverCqName)) {
Review comment:
Sorry for late response...
The CQs are registered based on the subscription-redundancy. Servers on
which they are registered should be treating them as activeCQCounts.
When the CQs are closed. They all will get closed, decrementing the active
CQCount.
Can you try this with java client test...And see it is the behavior.
>> one on which cq is register and others on which it will process
registerCq.
Are you seeing CQs that are only getting registered but not processed? that
seems to be wrong...Are I am missing something.
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
> activeCQCount has negative value
>
>
> Key: GEODE-8293
> URL: https://issues.apache.org/jira/browse/GEODE-8293
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> In case you have more than one server in the system and you close CQ there
> will be negative value of active cqs.
> The problem is when you started more than one server and execute cq on it. In
> that case we got incCqsActive on one server, but when it is closed we have
> decCqsActive on both servers.
> {code:java}
> gfsh>show metrics --categories=query
> Cluster-wide MetricsCategory | Metric | Value
> | | -
> query| activeCQCount| 1
> | queryRequestRate | 0.0
> {code}
> After cq is closed or stopped:
> {code:java}
> gfsh>show metrics --categories=query
> Cluster-wide Metrics
> Category | Metric | Value
> | | -
> query| activeCQCount| -1
> | queryRequestRate | 0.0
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8293) activeCQCount has negative value
[
https://issues.apache.org/jira/browse/GEODE-8293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17194360#comment-17194360
]
ASF GitHub Bot commented on GEODE-8293:
---
agingade commented on a change in pull request #5397:
URL: https://github.com/apache/geode/pull/5397#discussion_r487138399
##
File path:
geode-cq/src/main/java/org/apache/geode/cache/query/cq/internal/ServerCQImpl.java
##
@@ -367,10 +367,12 @@ public void close(boolean sendRequestToServer) throws
CqClosedException, CqExcep
this.removeFromCqMap();
// Stat update.
- if (stateBeforeClosing == CqStateImpl.RUNNING) {
-cqService.stats().decCqsActive();
- } else if (stateBeforeClosing == CqStateImpl.STOPPED) {
-cqService.stats().decCqsStopped();
+ if (!cqName.equals(serverCqName)) {
Review comment:
Again, sorry for delayed response. If needed you can always send a
direct email to me.
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
> activeCQCount has negative value
>
>
> Key: GEODE-8293
> URL: https://issues.apache.org/jira/browse/GEODE-8293
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> In case you have more than one server in the system and you close CQ there
> will be negative value of active cqs.
> The problem is when you started more than one server and execute cq on it. In
> that case we got incCqsActive on one server, but when it is closed we have
> decCqsActive on both servers.
> {code:java}
> gfsh>show metrics --categories=query
> Cluster-wide MetricsCategory | Metric | Value
> | | -
> query| activeCQCount| 1
> | queryRequestRate | 0.0
> {code}
> After cq is closed or stopped:
> {code:java}
> gfsh>show metrics --categories=query
> Cluster-wide Metrics
> Category | Metric | Value
> | | -
> query| activeCQCount| -1
> | queryRequestRate | 0.0
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8489) Pulse should keep the pre-1.8 behavior when doing a "Select *" query
[ https://issues.apache.org/jira/browse/GEODE-8489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-8489: --- Labels: GeodeOperationAPI (was: ) > Pulse should keep the pre-1.8 behavior when doing a "Select *" query > > > Key: GEODE-8489 > URL: https://issues.apache.org/jira/browse/GEODE-8489 > Project: Geode > Issue Type: Bug > Components: management >Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.13.0 >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI > > After the TypedJson refactor, we see those different behaviors when using > DistributedSysteemMBean to do a "select *" query: > 1. Jackson Json Annotations are taking into effect now. "Select *" won't show > those `@JsonIgnore` fields anymore. And "JsonProperty" annotation values are > showing up as headers > 2. null values fields are not showing up. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8489) Pulse should keep the pre-1.8 behavior when doing a "Select *" query
Jinmei Liao created GEODE-8489: -- Summary: Pulse should keep the pre-1.8 behavior when doing a "Select *" query Key: GEODE-8489 URL: https://issues.apache.org/jira/browse/GEODE-8489 Project: Geode Issue Type: Bug Components: management Affects Versions: 1.13.0, 1.11.0, 1.9.2, 1.10.0 Reporter: Jinmei Liao After the TypedJson refactor, we see those different behaviors when using DistributedSysteemMBean to do a "select *" query: 1. Jackson Json Annotations are taking into effect now. "Select *" won't show those `@JsonIgnore` fields anymore. And "JsonProperty" annotation values are showing up as headers 2. null values fields are not showing up. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8489) Pulse should keep the pre-1.8 behavior when doing a "Select *" query
[ https://issues.apache.org/jira/browse/GEODE-8489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8489: -- Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI) > Pulse should keep the pre-1.8 behavior when doing a "Select *" query > > > Key: GEODE-8489 > URL: https://issues.apache.org/jira/browse/GEODE-8489 > Project: Geode > Issue Type: Bug > Components: management >Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.13.0 >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > After the TypedJson refactor, we see those different behaviors when using > DistributedSysteemMBean to do a "select *" query: > 1. Jackson Json Annotations are taking into effect now. "Select *" won't show > those `@JsonIgnore` fields anymore. And "JsonProperty" annotation values are > showing up as headers > 2. null values fields are not showing up. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8489) Pulse should keep the pre-1.8 behavior when doing a "Select *" query
[ https://issues.apache.org/jira/browse/GEODE-8489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17194379#comment-17194379 ] ASF GitHub Bot commented on GEODE-8489: --- jinmeiliao opened a new pull request #5507: URL: https://github.com/apache/geode/pull/5507 …or jackson json annotations * null value fields are serialized as well * move QueryResultFormatterTest to core 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 > Pulse should keep the pre-1.8 behavior when doing a "Select *" query > > > Key: GEODE-8489 > URL: https://issues.apache.org/jira/browse/GEODE-8489 > Project: Geode > Issue Type: Bug > Components: management >Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.13.0 >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI > > After the TypedJson refactor, we see those different behaviors when using > DistributedSysteemMBean to do a "select *" query: > 1. Jackson Json Annotations are taking into effect now. "Select *" won't show > those `@JsonIgnore` fields anymore. And "JsonProperty" annotation values are > showing up as headers > 2. null values fields are not showing up. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8483) Geode JCALocalTransaction fails to begin a JTA last resource transaction if the TransactionManager is not bound into JNDI
[
https://issues.apache.org/jira/browse/GEODE-8483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17194385#comment-17194385
]
ASF subversion and git services commented on GEODE-8483:
Commit 3ede9e14b75ea53ad83677e7a40a406f8a7aca64 in geode's branch
refs/heads/support/1.13 from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3ede9e1 ]
GEODE-8483: Remove JNDI lookup and check
(cherry picked from commit 317a7061ae56d97a4d58d740c5af3b05b36a)
> Geode JCALocalTransaction fails to begin a JTA last resource transaction if
> the TransactionManager is not bound into JNDI
> -
>
> Key: GEODE-8483
> URL: https://issues.apache.org/jira/browse/GEODE-8483
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: pull-request-available
>
> The exception is:
> {noformat}
> [error 2020/08/18 22:57:03.997 UTC tid=0x20]
> Application run failed
> Caused by: org.springframework.transaction.TransactionSystemException:
> UOWManager transaction processing failed; nested exception is
> com.ibm.wsspi.uow.UOWException: javax.transaction.HeuristicMixedException
> at
> org.springframework.transaction.jta.WebSphereUowTransactionManager.execute(WebSphereUowTransactionManager.java:313)
> at example.jta.client.Client.iterateAndCreateTrades(Client.java:93)
> at example.jta.client.Client.loadEntries(Client.java:74)
> Caused by: com.ibm.wsspi.uow.UOWException:
> javax.transaction.HeuristicMixedException
> at
> com.ibm.ws.uow.embeddable.EmbeddableUOWManagerImpl.runUnderNewUOW(EmbeddableUOWManagerImpl.java:757)
> at
> com.ibm.ws.uow.embeddable.EmbeddableUOWManagerImpl.runUnderUOW(EmbeddableUOWManagerImpl.java:329)
> at
> org.springframework.transaction.jta.WebSphereUowTransactionManager.execute(WebSphereUowTransactionManager.java:306)
> Caused by: javax.transaction.HeuristicMixedException
> at com.ibm.tx.jta.impl.TransactionImpl.commit(TransactionImpl.java:715)
> at com.ibm.tx.jta.impl.TranManagerImpl.commit(TranManagerImpl.java:165)
> at com.ibm.tx.jta.impl.TranManagerSet.commit(TranManagerSet.java:113)
> at
> com.ibm.ws.uow.embeddable.EmbeddableUOWManagerImpl.uowCommit(EmbeddableUOWManagerImpl.java:834)
> at
> com.ibm.ws.uow.embeddable.EmbeddableUOWManagerImpl.uowEnd(EmbeddableUOWManagerImpl.java:812)
> at
> com.ibm.ws.uow.embeddable.EmbeddableUOWManagerImpl.runUnderNewUOW(EmbeddableUOWManagerImpl.java:754)
> Caused by: javax.transaction.xa.XAException
> at
> com.ibm.ejs.j2c.LocalTransactionWrapper.commit(LocalTransactionWrapper.java:157)
> at
> com.ibm.tx.jta.impl.OnePhaseResourceImpl.commit_one_phase(OnePhaseResourceImpl.java:113)
> at
> com.ibm.tx.jta.impl.RegisteredResources.flowCommitOnePhase(RegisteredResources.java:2045)
> at
> com.ibm.tx.jta.impl.TransactionImpl.commitXAResources(TransactionImpl.java:1478)
> at
> com.ibm.tx.jta.impl.TransactionImpl.stage1CommitProcessing(TransactionImpl.java:801)
> at
> com.ibm.tx.jta.impl.TransactionImpl.processCommit(TransactionImpl.java:768)
> at com.ibm.tx.jta.impl.TransactionImpl.commit(TransactionImpl.java:711)
> Caused by: javax.resource.spi.LocalTransactionException:
> java.lang.IllegalStateException: Thread does not have an active transaction
> at
> org.apache.geode.internal.ra.spi.JCALocalTransaction.commit(JCALocalTransaction.java:116)
> at
> com.ibm.ejs.j2c.LocalTransactionWrapper.commit(LocalTransactionWrapper.java:145)
> {noformat}
> Here is a truncated version of {{JCALocalTransaction.begin}}:
> {noformat}
> public void begin() throws ResourceException {
> TransactionManager tm = this.cache.getJTATransactionManager();
> if (tm != null && tm.getTransaction() != null) {
> this.gfTxMgr.begin();
> } else {
> if (logger.fineEnabled()) {
> logger.fine("JCAManagedConnection: JTA Transaction does not exist.");
> }
> }
> }
> {noformat}
> It attempts to get the {{TransactionManager}} (which in this case is a
> {{com.ibm.tx.jta.embeddable.impl.EmbeddableTranManagerSet}}). If it is null
> (not bound) or it doesn't have a {{Transaction}} in progress, it logs a
> message at fine level and returns.
> A stack trace in {{JCALocalTransaction.begin}} shows the call stack:
> {noformat}
> java.lang.Exception
> at
> org.apache.geode.internal.ra.spi.JCALocalTransaction.begin(JCALocalTransaction.java:54)
> at
> com.ibm.ejs.j2c.LocalTransactionWrapper.start(LocalTransactionWrapper.java:668)
> at
> com.ibm.ws.Transaction.JTA.JTAResourceBase.start(JTAResourceBase.java:121)
>
[jira] [Commented] (GEODE-8129) Write SNI test that drops proxy and restarts proxy
[
https://issues.apache.org/jira/browse/GEODE-8129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17194392#comment-17194392
]
ASF GitHub Bot commented on GEODE-8129:
---
echobravopapa commented on a change in pull request #650:
URL: https://github.com/apache/geode-native/pull/650#discussion_r487163729
##
File path: cppcache/acceptance-test/SNITest.cpp
##
@@ -174,4 +174,51 @@ TEST_F(SNITest, connectWithoutProxyFails) {
cache.close();
}
+#if defined(_WIN32)
+TEST_F(SNITest, DISABLED_dropSNIProxyTest) {
+#else
+TEST_F(SNITest, dropSNIProxyTest) {
+#endif
+ const auto clientTruststore =
+ (clientSslKeysDir / boost::filesystem::path("/truststore_sni.pem"));
+
+ auto cache = CacheFactory()
+ .set("log-level", "debug")
+ .set("log-file", "SNITest.log")
+ .set("ssl-enabled", "true")
+ .set("ssl-truststore", clientTruststore.string())
+ .create();
+
+ auto portString = runDockerCommand("docker port haproxy");
+ auto portNumber = parseProxyPort(portString);
+
+ cache.getPoolManager()
+ .createFactory()
+ .setSniProxy("localhost", portNumber)
+ .addLocator("locator-maeve", 10334)
+ .create("pool");
+
+ auto region = cache.createRegionFactory(RegionShortcut::PROXY)
+.setPoolName("pool")
+.create("jellyfish");
+
+ auto systemRVal = std::system("docker-compose pause");
+ if (systemRVal == -1) {
+BOOST_LOG_TRIVIAL(error) << "std::system returned: " << systemRVal;
+ }
+
+ region->put("1", "one");
Review comment:
you'll want to check/prove that the Put doesn't go through... i.e. its
an expected failure and I bet there is an exception thrown...
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
> Write SNI test that drops proxy and restarts proxy
> ---
>
> Key: GEODE-8129
> URL: https://issues.apache.org/jira/browse/GEODE-8129
> Project: Geode
> Issue Type: Test
> Components: native client
>Reporter: Ernest Burghardt
>Priority: Major
> Labels: pull-request-available
>
> This test is similar to GEODE-8128 - only capability to parse `docker ps` and
> store the hostPort in advance of dropping proxy, this allows the proxy to be
> restarted with the same port mapping
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8489) Pulse should keep the pre-1.9 behavior when doing a "Select *" query
[ https://issues.apache.org/jira/browse/GEODE-8489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-8489: --- Affects Version/s: (was: 1.9.2) > Pulse should keep the pre-1.9 behavior when doing a "Select *" query > > > Key: GEODE-8489 > URL: https://issues.apache.org/jira/browse/GEODE-8489 > Project: Geode > Issue Type: Bug > Components: management >Affects Versions: 1.10.0, 1.11.0, 1.13.0 >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > After the TypedJson refactor, we see those different behaviors when using > DistributedSysteemMBean to do a "select *" query: > 1. Jackson Json Annotations are taking into effect now. "Select *" won't show > those `@JsonIgnore` fields anymore. And "JsonProperty" annotation values are > showing up as headers > 2. null values fields are not showing up. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8489) Pulse should keep the pre-1.9 behavior when doing a "Select *" query
[ https://issues.apache.org/jira/browse/GEODE-8489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-8489: --- Summary: Pulse should keep the pre-1.9 behavior when doing a "Select *" query (was: Pulse should keep the pre-1.8 behavior when doing a "Select *" query) > Pulse should keep the pre-1.9 behavior when doing a "Select *" query > > > Key: GEODE-8489 > URL: https://issues.apache.org/jira/browse/GEODE-8489 > Project: Geode > Issue Type: Bug > Components: management >Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.13.0 >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > After the TypedJson refactor, we see those different behaviors when using > DistributedSysteemMBean to do a "select *" query: > 1. Jackson Json Annotations are taking into effect now. "Select *" won't show > those `@JsonIgnore` fields anymore. And "JsonProperty" annotation values are > showing up as headers > 2. null values fields are not showing up. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8482) Concurrent access to ArrayList should be synchronized
[
https://issues.apache.org/jira/browse/GEODE-8482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17194480#comment-17194480
]
ASF GitHub Bot commented on GEODE-8482:
---
jchen21 commented on a change in pull request #5503:
URL: https://github.com/apache/geode/pull/5503#discussion_r487218213
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/control/InternalResourceManager.java
##
@@ -637,7 +638,9 @@ private ThreadsMonitoring getThreadMonitorObj() {
*/
public void addStartupTask(CompletableFuture startupTask) {
Objects.requireNonNull(startupTask);
-startupTasks.add(startupTask);
+synchronized (startupTasks) {
Review comment:
`CopyOnWriteArrayList` makes a fresh copy of the underlying array for
every mutative operation such as `add`. This is too costly for this use case.
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
> Concurrent access to ArrayList should be synchronized
> -
>
> Key: GEODE-8482
> URL: https://issues.apache.org/jira/browse/GEODE-8482
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Jianxia Chen
>Assignee: Jianxia Chen
>Priority: Major
> Labels: pull-request-available
>
> We have seen ArrayIndexOutOfBoundsException when multiple threads access
> ArrayList.
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:598)
> at
> java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:677)
> at java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:735)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:160)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:583)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.createDiskStores(CacheCreation.java:647)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:531)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:339)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4200)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1621)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1447)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> at
> org.apache.geode.internal.cache.CacheFactoryStatics.create(CacheFactoryStatics.java:61)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:352)
>
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 15
> at java.util.ArrayList.add(ArrayList.java:465)
> at
> org.apache.geode.internal.cache.control.InternalResourceManager.addStartupTask(InternalResourceManager.java:640)
> at
> org.apache.geode.internal.cache.DiskStoreImpl.scheduleValueRecovery(DiskStoreImpl.java:2088)
> at
> org.apache.geode.internal.cache.PersistentOplogSet.recoverOplogs(PersistentOplogSet.java:520)
> at
> org.apache.geode.internal.cache.PersistentOplogSet.recoverRegionsThatAreReady(PersistentOplogSet.java:379)
> at
> org.apache.geode.internal.cache.DiskStoreImpl.recoverRegionsThatAreReady(DiskStoreImpl.java:2076)
> at
> org.apache.geode.internal.cache.DiskStoreImpl.initializeIfNeeded(DiskStoreImpl.java:2064)
> at
> org.apache.geode.internal.cache.DiskStoreImpl.doInitialRecovery(DiskStoreImpl.java:2069)
> at
> org.apache.geode.internal.cache.DiskStoreFactoryImpl.initializeDiskStore(DiskStoreFactoryImpl.java:192)
> at
> org.apache.geode.internal.cache.DiskStor
[jira] [Updated] (GEODE-8489) Pulse should keep the 1.8 behavior when doing a "Select *" query
[ https://issues.apache.org/jira/browse/GEODE-8489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-8489: --- Summary: Pulse should keep the 1.8 behavior when doing a "Select *" query (was: Pulse should keep the pre-1.8 behavior when doing a "Select *" query) > Pulse should keep the 1.8 behavior when doing a "Select *" query > > > Key: GEODE-8489 > URL: https://issues.apache.org/jira/browse/GEODE-8489 > Project: Geode > Issue Type: Bug > Components: management >Affects Versions: 1.10.0, 1.11.0, 1.13.0 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > After the TypedJson refactor, we see those different behaviors when using > DistributedSysteemMBean to do a "select *" query: > 1. Jackson Json Annotations are taking into effect now. "Select *" won't show > those `@JsonIgnore` fields anymore. And "JsonProperty" annotation values are > showing up as headers > 2. null values fields are not showing up. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8489) Pulse should keep the 1.8 behavior when doing a "Select *" query
[ https://issues.apache.org/jira/browse/GEODE-8489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-8489: --- Affects Version/s: 1.9.2 > Pulse should keep the 1.8 behavior when doing a "Select *" query > > > Key: GEODE-8489 > URL: https://issues.apache.org/jira/browse/GEODE-8489 > Project: Geode > Issue Type: Bug > Components: management >Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.13.0 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > After the TypedJson refactor, we see those different behaviors when using > DistributedSysteemMBean to do a "select *" query: > 1. Jackson Json Annotations are taking into effect now. "Select *" won't show > those `@JsonIgnore` fields anymore. And "JsonProperty" annotation values are > showing up as headers > 2. null values fields are not showing up. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8489) Pulse should keep the pre-1.9 behavior when doing a "Select *" query
[ https://issues.apache.org/jira/browse/GEODE-8489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-8489: -- Assignee: Jinmei Liao > Pulse should keep the pre-1.9 behavior when doing a "Select *" query > > > Key: GEODE-8489 > URL: https://issues.apache.org/jira/browse/GEODE-8489 > Project: Geode > Issue Type: Bug > Components: management >Affects Versions: 1.10.0, 1.11.0, 1.13.0 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > After the TypedJson refactor, we see those different behaviors when using > DistributedSysteemMBean to do a "select *" query: > 1. Jackson Json Annotations are taking into effect now. "Select *" won't show > those `@JsonIgnore` fields anymore. And "JsonProperty" annotation values are > showing up as headers > 2. null values fields are not showing up. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8489) Pulse should keep the pre-1.8 behavior when doing a "Select *" query
[ https://issues.apache.org/jira/browse/GEODE-8489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-8489: --- Summary: Pulse should keep the pre-1.8 behavior when doing a "Select *" query (was: Pulse should keep the pre-1.9 behavior when doing a "Select *" query) > Pulse should keep the pre-1.8 behavior when doing a "Select *" query > > > Key: GEODE-8489 > URL: https://issues.apache.org/jira/browse/GEODE-8489 > Project: Geode > Issue Type: Bug > Components: management >Affects Versions: 1.10.0, 1.11.0, 1.13.0 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > After the TypedJson refactor, we see those different behaviors when using > DistributedSysteemMBean to do a "select *" query: > 1. Jackson Json Annotations are taking into effect now. "Select *" won't show > those `@JsonIgnore` fields anymore. And "JsonProperty" annotation values are > showing up as headers > 2. null values fields are not showing up. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8490) Docker containers are not properly cleaned up after native Redis acceptance tests
Sarah Abbey created GEODE-8490:
--
Summary: Docker containers are not properly cleaned up after
native Redis acceptance tests
Key: GEODE-8490
URL: https://issues.apache.org/jira/browse/GEODE-8490
Project: Geode
Issue Type: Bug
Components: redis
Reporter: Sarah Abbey
This [CI
failure|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK8/builds/428]
was caused by Docker containers that were not cleaned up properly in some
native Redis acceptance tests that ran beforehand.
{code:java}
Caused by: java.net.BindException: Network is unreachable; port (40404) is
not available on localhost.
at
org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:794)
{code}
We created a test rule to properly close and clean up all Docker containers
created by the native Redis acceptance tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8490) Docker containers are not properly cleaned up after native Redis acceptance tests
[
https://issues.apache.org/jira/browse/GEODE-8490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sarah Abbey reassigned GEODE-8490:
--
Assignee: Sarah Abbey
> Docker containers are not properly cleaned up after native Redis acceptance
> tests
> -
>
> Key: GEODE-8490
> URL: https://issues.apache.org/jira/browse/GEODE-8490
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Sarah Abbey
>Assignee: Sarah Abbey
>Priority: Major
>
> This [CI
> failure|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK8/builds/428]
> was caused by Docker containers that were not cleaned up properly in some
> native Redis acceptance tests that ran beforehand.
> {code:java}
> Caused by: java.net.BindException: Network is unreachable; port (40404)
> is not available on localhost.
> at
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:794)
> {code}
> We created a test rule to properly close and clean up all Docker containers
> created by the native Redis acceptance tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8490) Docker containers are not properly cleaned up after native Redis acceptance tests
[
https://issues.apache.org/jira/browse/GEODE-8490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sarah Abbey updated GEODE-8490:
---
Description:
This [CI
failure|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK8/builds/428]
is due to port conflicts with Docker containers that were not cleaned up
properly in some native Redis acceptance tests that ran beforehand.
{code:java}
Caused by: java.net.BindException: Network is unreachable; port (40404) is
not available on localhost.
at
org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:794)
{code}
We created a test rule to properly close and clean up all Docker containers
created by the native Redis acceptance tests.
was:
This [CI
failure|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK8/builds/428]
was caused by Docker containers that were not cleaned up properly in some
native Redis acceptance tests that ran beforehand.
{code:java}
Caused by: java.net.BindException: Network is unreachable; port (40404) is
not available on localhost.
at
org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:794)
{code}
We created a test rule to properly close and clean up all Docker containers
created by the native Redis acceptance tests.
> Docker containers are not properly cleaned up after native Redis acceptance
> tests
> -
>
> Key: GEODE-8490
> URL: https://issues.apache.org/jira/browse/GEODE-8490
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Sarah Abbey
>Assignee: Sarah Abbey
>Priority: Major
>
> This [CI
> failure|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK8/builds/428]
> is due to port conflicts with Docker containers that were not cleaned up
> properly in some native Redis acceptance tests that ran beforehand.
> {code:java}
> Caused by: java.net.BindException: Network is unreachable; port (40404)
> is not available on localhost.
> at
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:794)
> {code}
> We created a test rule to properly close and clean up all Docker containers
> created by the native Redis acceptance tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8483) Geode JCALocalTransaction fails to begin a JTA last resource transaction if the TransactionManager is not bound into JNDI
[
https://issues.apache.org/jira/browse/GEODE-8483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17194517#comment-17194517
]
ASF subversion and git services commented on GEODE-8483:
Commit 8739e021f1213c74e231449050c52f59aac83d48 in geode's branch
refs/heads/support/1.12 from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8739e02 ]
GEODE-8483: Remove JNDI lookup and check
(cherry picked from commit 317a7061ae56d97a4d58d740c5af3b05b36a)
(cherry picked from commit 3ede9e14b75ea53ad83677e7a40a406f8a7aca64)
> Geode JCALocalTransaction fails to begin a JTA last resource transaction if
> the TransactionManager is not bound into JNDI
> -
>
> Key: GEODE-8483
> URL: https://issues.apache.org/jira/browse/GEODE-8483
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: pull-request-available
>
> The exception is:
> {noformat}
> [error 2020/08/18 22:57:03.997 UTC tid=0x20]
> Application run failed
> Caused by: org.springframework.transaction.TransactionSystemException:
> UOWManager transaction processing failed; nested exception is
> com.ibm.wsspi.uow.UOWException: javax.transaction.HeuristicMixedException
> at
> org.springframework.transaction.jta.WebSphereUowTransactionManager.execute(WebSphereUowTransactionManager.java:313)
> at example.jta.client.Client.iterateAndCreateTrades(Client.java:93)
> at example.jta.client.Client.loadEntries(Client.java:74)
> Caused by: com.ibm.wsspi.uow.UOWException:
> javax.transaction.HeuristicMixedException
> at
> com.ibm.ws.uow.embeddable.EmbeddableUOWManagerImpl.runUnderNewUOW(EmbeddableUOWManagerImpl.java:757)
> at
> com.ibm.ws.uow.embeddable.EmbeddableUOWManagerImpl.runUnderUOW(EmbeddableUOWManagerImpl.java:329)
> at
> org.springframework.transaction.jta.WebSphereUowTransactionManager.execute(WebSphereUowTransactionManager.java:306)
> Caused by: javax.transaction.HeuristicMixedException
> at com.ibm.tx.jta.impl.TransactionImpl.commit(TransactionImpl.java:715)
> at com.ibm.tx.jta.impl.TranManagerImpl.commit(TranManagerImpl.java:165)
> at com.ibm.tx.jta.impl.TranManagerSet.commit(TranManagerSet.java:113)
> at
> com.ibm.ws.uow.embeddable.EmbeddableUOWManagerImpl.uowCommit(EmbeddableUOWManagerImpl.java:834)
> at
> com.ibm.ws.uow.embeddable.EmbeddableUOWManagerImpl.uowEnd(EmbeddableUOWManagerImpl.java:812)
> at
> com.ibm.ws.uow.embeddable.EmbeddableUOWManagerImpl.runUnderNewUOW(EmbeddableUOWManagerImpl.java:754)
> Caused by: javax.transaction.xa.XAException
> at
> com.ibm.ejs.j2c.LocalTransactionWrapper.commit(LocalTransactionWrapper.java:157)
> at
> com.ibm.tx.jta.impl.OnePhaseResourceImpl.commit_one_phase(OnePhaseResourceImpl.java:113)
> at
> com.ibm.tx.jta.impl.RegisteredResources.flowCommitOnePhase(RegisteredResources.java:2045)
> at
> com.ibm.tx.jta.impl.TransactionImpl.commitXAResources(TransactionImpl.java:1478)
> at
> com.ibm.tx.jta.impl.TransactionImpl.stage1CommitProcessing(TransactionImpl.java:801)
> at
> com.ibm.tx.jta.impl.TransactionImpl.processCommit(TransactionImpl.java:768)
> at com.ibm.tx.jta.impl.TransactionImpl.commit(TransactionImpl.java:711)
> Caused by: javax.resource.spi.LocalTransactionException:
> java.lang.IllegalStateException: Thread does not have an active transaction
> at
> org.apache.geode.internal.ra.spi.JCALocalTransaction.commit(JCALocalTransaction.java:116)
> at
> com.ibm.ejs.j2c.LocalTransactionWrapper.commit(LocalTransactionWrapper.java:145)
> {noformat}
> Here is a truncated version of {{JCALocalTransaction.begin}}:
> {noformat}
> public void begin() throws ResourceException {
> TransactionManager tm = this.cache.getJTATransactionManager();
> if (tm != null && tm.getTransaction() != null) {
> this.gfTxMgr.begin();
> } else {
> if (logger.fineEnabled()) {
> logger.fine("JCAManagedConnection: JTA Transaction does not exist.");
> }
> }
> }
> {noformat}
> It attempts to get the {{TransactionManager}} (which in this case is a
> {{com.ibm.tx.jta.embeddable.impl.EmbeddableTranManagerSet}}). If it is null
> (not bound) or it doesn't have a {{Transaction}} in progress, it logs a
> message at fine level and returns.
> A stack trace in {{JCALocalTransaction.begin}} shows the call stack:
> {noformat}
> java.lang.Exception
> at
> org.apache.geode.internal.ra.spi.JCALocalTransaction.begin(JCALocalTransaction.java:54)
> at
> com.ibm.ejs.j2c.LocalTransactionWrapper.start(LocalTransactionWrapper.java:668)
> at
> com.ibm
[jira] [Updated] (GEODE-8490) Docker containers are not properly cleaned up after native Redis acceptance tests
[
https://issues.apache.org/jira/browse/GEODE-8490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8490:
--
Labels: pull-request-available (was: )
> Docker containers are not properly cleaned up after native Redis acceptance
> tests
> -
>
> Key: GEODE-8490
> URL: https://issues.apache.org/jira/browse/GEODE-8490
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Sarah Abbey
>Assignee: Sarah Abbey
>Priority: Major
> Labels: pull-request-available
>
> This [CI
> failure|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK8/builds/428]
> is due to port conflicts with Docker containers that were not cleaned up
> properly in some native Redis acceptance tests that ran beforehand.
> {code:java}
> Caused by: java.net.BindException: Network is unreachable; port (40404)
> is not available on localhost.
> at
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:794)
> {code}
> We created a test rule to properly close and clean up all Docker containers
> created by the native Redis acceptance tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8490) Docker containers are not properly cleaned up after native Redis acceptance tests
[
https://issues.apache.org/jira/browse/GEODE-8490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17194519#comment-17194519
]
ASF GitHub Bot commented on GEODE-8490:
---
sabbeyPivotal opened a new pull request #5508:
URL: https://github.com/apache/geode/pull/5508
- Created a test rule (NativeRedisTestRule) to properly close and clean up
all Docker containers created by the native Redis acceptance tests
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
> Docker containers are not properly cleaned up after native Redis acceptance
> tests
> -
>
> Key: GEODE-8490
> URL: https://issues.apache.org/jira/browse/GEODE-8490
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Sarah Abbey
>Assignee: Sarah Abbey
>Priority: Major
>
> This [CI
> failure|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK8/builds/428]
> is due to port conflicts with Docker containers that were not cleaned up
> properly in some native Redis acceptance tests that ran beforehand.
> {code:java}
> Caused by: java.net.BindException: Network is unreachable; port (40404)
> is not available on localhost.
> at
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:794)
> {code}
> We created a test rule to properly close and clean up all Docker containers
> created by the native Redis acceptance tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-5601) AcceptanceTests are run in parallel without using containers, resulting in port conflicts
[
https://issues.apache.org/jira/browse/GEODE-5601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sarah Abbey resolved GEODE-5601.
> AcceptanceTests are run in parallel without using containers, resulting in
> port conflicts
> -
>
> Key: GEODE-5601
> URL: https://issues.apache.org/jira/browse/GEODE-5601
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Jacob Barrett
>Assignee: Jens Deppe
>Priority: Major
> Labels: flaky, pull-request-available, swat
> Fix For: 1.7.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {noformat}
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest >
> deployLargeSetOfJars FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:117)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:135)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:106)
> at
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.deployLargeSetOfJars(DeployWithLargeJarTest.java:41)
> {noformat}
> Passes:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/AcceptanceTest/builds/721
> Fails:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/AcceptanceTest/builds/728
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-5601) AcceptanceTests are run in parallel without using containers, resulting in port conflicts
[
https://issues.apache.org/jira/browse/GEODE-5601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sarah Abbey closed GEODE-5601.
--
> AcceptanceTests are run in parallel without using containers, resulting in
> port conflicts
> -
>
> Key: GEODE-5601
> URL: https://issues.apache.org/jira/browse/GEODE-5601
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Jacob Barrett
>Assignee: Jens Deppe
>Priority: Major
> Labels: flaky, pull-request-available, swat
> Fix For: 1.7.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {noformat}
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest >
> deployLargeSetOfJars FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:117)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:135)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:106)
> at
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.deployLargeSetOfJars(DeployWithLargeJarTest.java:41)
> {noformat}
> Passes:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/AcceptanceTest/builds/721
> Fails:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/AcceptanceTest/builds/728
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8447) Pulse should localize “java.util.Date” in the displayed query result
[ https://issues.apache.org/jira/browse/GEODE-8447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17194521#comment-17194521 ] ASF subversion and git services commented on GEODE-8447: Commit b0eef55200ec56a42efeec5f283cddce862e812e in geode's branch refs/heads/support/1.13 from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b0eef55 ] GEODE-8447: QueryResultFormatter should show dates in localized strings (#5469) * support java.util.Date, java.sql.Date and java.time.* date objects in the formatter > Pulse should localize “java.util.Date” in the displayed query result > > > Key: GEODE-8447 > URL: https://issues.apache.org/jira/browse/GEODE-8447 > Project: Geode > Issue Type: Bug > Components: management >Affects Versions: 1.12.0 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available > Fix For: 1.12.1, 1.14.0 > > Attachments: CreatedOn-lastUpdated.JPG, Date-GF96.JPG > > > In previous versions of Geode, Pulse used to show Dates in localized string, > now it's not. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8482) Concurrent access to ArrayList should be synchronized
[
https://issues.apache.org/jira/browse/GEODE-8482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17194535#comment-17194535
]
ASF GitHub Bot commented on GEODE-8482:
---
jchen21 merged pull request #5503:
URL: https://github.com/apache/geode/pull/5503
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
> Concurrent access to ArrayList should be synchronized
> -
>
> Key: GEODE-8482
> URL: https://issues.apache.org/jira/browse/GEODE-8482
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Jianxia Chen
>Assignee: Jianxia Chen
>Priority: Major
> Labels: pull-request-available
>
> We have seen ArrayIndexOutOfBoundsException when multiple threads access
> ArrayList.
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:598)
> at
> java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:677)
> at java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:735)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:160)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:583)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.createDiskStores(CacheCreation.java:647)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:531)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:339)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4200)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1621)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1447)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> at
> org.apache.geode.internal.cache.CacheFactoryStatics.create(CacheFactoryStatics.java:61)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:352)
>
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 15
> at java.util.ArrayList.add(ArrayList.java:465)
> at
> org.apache.geode.internal.cache.control.InternalResourceManager.addStartupTask(InternalResourceManager.java:640)
> at
> org.apache.geode.internal.cache.DiskStoreImpl.scheduleValueRecovery(DiskStoreImpl.java:2088)
> at
> org.apache.geode.internal.cache.PersistentOplogSet.recoverOplogs(PersistentOplogSet.java:520)
> at
> org.apache.geode.internal.cache.PersistentOplogSet.recoverRegionsThatAreReady(PersistentOplogSet.java:379)
> at
> org.apache.geode.internal.cache.DiskStoreImpl.recoverRegionsThatAreReady(DiskStoreImpl.java:2076)
> at
> org.apache.geode.internal.cache.DiskStoreImpl.initializeIfNeeded(DiskStoreImpl.java:2064)
> at
> org.apache.geode.internal.cache.DiskStoreImpl.doInitialRecovery(DiskStoreImpl.java:2069)
> at
> org.apache.geode.internal.cache.DiskStoreFactoryImpl.initializeDiskStore(DiskStoreFactoryImpl.java:192)
> at
> org.apache.geode.internal.cache.DiskStoreFactoryImpl.create(DiskStoreFactoryImpl.java:156)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.createDiskStore(CacheCreation.java:834)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.lambda$createDiskStores$0(CacheCreation.java:650)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.ForEachO
[jira] [Resolved] (GEODE-8482) Concurrent access to ArrayList should be synchronized
[
https://issues.apache.org/jira/browse/GEODE-8482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jianxia Chen resolved GEODE-8482.
-
Resolution: Fixed
> Concurrent access to ArrayList should be synchronized
> -
>
> Key: GEODE-8482
> URL: https://issues.apache.org/jira/browse/GEODE-8482
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Jianxia Chen
>Assignee: Jianxia Chen
>Priority: Major
> Labels: pull-request-available
>
> We have seen ArrayIndexOutOfBoundsException when multiple threads access
> ArrayList.
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:598)
> at
> java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:677)
> at java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:735)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:160)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:583)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.createDiskStores(CacheCreation.java:647)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:531)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:339)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4200)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1621)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1447)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> at
> org.apache.geode.internal.cache.CacheFactoryStatics.create(CacheFactoryStatics.java:61)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:352)
>
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 15
> at java.util.ArrayList.add(ArrayList.java:465)
> at
> org.apache.geode.internal.cache.control.InternalResourceManager.addStartupTask(InternalResourceManager.java:640)
> at
> org.apache.geode.internal.cache.DiskStoreImpl.scheduleValueRecovery(DiskStoreImpl.java:2088)
> at
> org.apache.geode.internal.cache.PersistentOplogSet.recoverOplogs(PersistentOplogSet.java:520)
> at
> org.apache.geode.internal.cache.PersistentOplogSet.recoverRegionsThatAreReady(PersistentOplogSet.java:379)
> at
> org.apache.geode.internal.cache.DiskStoreImpl.recoverRegionsThatAreReady(DiskStoreImpl.java:2076)
> at
> org.apache.geode.internal.cache.DiskStoreImpl.initializeIfNeeded(DiskStoreImpl.java:2064)
> at
> org.apache.geode.internal.cache.DiskStoreImpl.doInitialRecovery(DiskStoreImpl.java:2069)
> at
> org.apache.geode.internal.cache.DiskStoreFactoryImpl.initializeDiskStore(DiskStoreFactoryImpl.java:192)
> at
> org.apache.geode.internal.cache.DiskStoreFactoryImpl.create(DiskStoreFactoryImpl.java:156)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.createDiskStore(CacheCreation.java:834)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.lambda$createDiskStores$0(CacheCreation.java:650)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:291)
> at
> java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:731)
> at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
> at
> java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
> at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
> at
> java.util.concurrent.ForkJoinWorkerThread.run(Fork
[jira] [Commented] (GEODE-8482) Concurrent access to ArrayList should be synchronized
[
https://issues.apache.org/jira/browse/GEODE-8482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17194538#comment-17194538
]
ASF subversion and git services commented on GEODE-8482:
Commit 3f4d97eb051a85af10d2b076051a2324bea4b28a in geode's branch
refs/heads/develop from Jianxia Chen
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3f4d97e ]
GEODE-8482: Concurrent access to ArrayList should be synchronized (#5503)
> Concurrent access to ArrayList should be synchronized
> -
>
> Key: GEODE-8482
> URL: https://issues.apache.org/jira/browse/GEODE-8482
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Jianxia Chen
>Assignee: Jianxia Chen
>Priority: Major
> Labels: pull-request-available
>
> We have seen ArrayIndexOutOfBoundsException when multiple threads access
> ArrayList.
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:598)
> at
> java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:677)
> at java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:735)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:160)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:583)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.createDiskStores(CacheCreation.java:647)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:531)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:339)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4200)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1621)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1447)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> at
> org.apache.geode.internal.cache.CacheFactoryStatics.create(CacheFactoryStatics.java:61)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:352)
>
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 15
> at java.util.ArrayList.add(ArrayList.java:465)
> at
> org.apache.geode.internal.cache.control.InternalResourceManager.addStartupTask(InternalResourceManager.java:640)
> at
> org.apache.geode.internal.cache.DiskStoreImpl.scheduleValueRecovery(DiskStoreImpl.java:2088)
> at
> org.apache.geode.internal.cache.PersistentOplogSet.recoverOplogs(PersistentOplogSet.java:520)
> at
> org.apache.geode.internal.cache.PersistentOplogSet.recoverRegionsThatAreReady(PersistentOplogSet.java:379)
> at
> org.apache.geode.internal.cache.DiskStoreImpl.recoverRegionsThatAreReady(DiskStoreImpl.java:2076)
> at
> org.apache.geode.internal.cache.DiskStoreImpl.initializeIfNeeded(DiskStoreImpl.java:2064)
> at
> org.apache.geode.internal.cache.DiskStoreImpl.doInitialRecovery(DiskStoreImpl.java:2069)
> at
> org.apache.geode.internal.cache.DiskStoreFactoryImpl.initializeDiskStore(DiskStoreFactoryImpl.java:192)
> at
> org.apache.geode.internal.cache.DiskStoreFactoryImpl.create(DiskStoreFactoryImpl.java:156)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.createDiskStore(CacheCreation.java:834)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.lambda$createDiskStores$0(CacheCreation.java:650)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:291)
> at
> java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:731)
>
[jira] [Commented] (GEODE-8482) Concurrent access to ArrayList should be synchronized
[
https://issues.apache.org/jira/browse/GEODE-8482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17194539#comment-17194539
]
ASF subversion and git services commented on GEODE-8482:
Commit 3f4d97eb051a85af10d2b076051a2324bea4b28a in geode's branch
refs/heads/develop from Jianxia Chen
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3f4d97e ]
GEODE-8482: Concurrent access to ArrayList should be synchronized (#5503)
> Concurrent access to ArrayList should be synchronized
> -
>
> Key: GEODE-8482
> URL: https://issues.apache.org/jira/browse/GEODE-8482
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Jianxia Chen
>Assignee: Jianxia Chen
>Priority: Major
> Labels: pull-request-available
>
> We have seen ArrayIndexOutOfBoundsException when multiple threads access
> ArrayList.
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:598)
> at
> java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:677)
> at java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:735)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:160)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:583)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.createDiskStores(CacheCreation.java:647)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:531)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:339)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4200)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1621)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1447)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> at
> org.apache.geode.internal.cache.CacheFactoryStatics.create(CacheFactoryStatics.java:61)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:352)
>
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 15
> at java.util.ArrayList.add(ArrayList.java:465)
> at
> org.apache.geode.internal.cache.control.InternalResourceManager.addStartupTask(InternalResourceManager.java:640)
> at
> org.apache.geode.internal.cache.DiskStoreImpl.scheduleValueRecovery(DiskStoreImpl.java:2088)
> at
> org.apache.geode.internal.cache.PersistentOplogSet.recoverOplogs(PersistentOplogSet.java:520)
> at
> org.apache.geode.internal.cache.PersistentOplogSet.recoverRegionsThatAreReady(PersistentOplogSet.java:379)
> at
> org.apache.geode.internal.cache.DiskStoreImpl.recoverRegionsThatAreReady(DiskStoreImpl.java:2076)
> at
> org.apache.geode.internal.cache.DiskStoreImpl.initializeIfNeeded(DiskStoreImpl.java:2064)
> at
> org.apache.geode.internal.cache.DiskStoreImpl.doInitialRecovery(DiskStoreImpl.java:2069)
> at
> org.apache.geode.internal.cache.DiskStoreFactoryImpl.initializeDiskStore(DiskStoreFactoryImpl.java:192)
> at
> org.apache.geode.internal.cache.DiskStoreFactoryImpl.create(DiskStoreFactoryImpl.java:156)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.createDiskStore(CacheCreation.java:834)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.lambda$createDiskStores$0(CacheCreation.java:650)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:291)
> at
> java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:731)
>
[jira] [Updated] (GEODE-8483) Geode JCALocalTransaction fails to begin a JTA last resource transaction if the TransactionManager is not bound into JNDI
[
https://issues.apache.org/jira/browse/GEODE-8483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-8483:
Fix Version/s: 1.13.1
1.14.0
1.12.1
> Geode JCALocalTransaction fails to begin a JTA last resource transaction if
> the TransactionManager is not bound into JNDI
> -
>
> Key: GEODE-8483
> URL: https://issues.apache.org/jira/browse/GEODE-8483
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.1, 1.14.0, 1.13.1
>
>
> The exception is:
> {noformat}
> [error 2020/08/18 22:57:03.997 UTC tid=0x20]
> Application run failed
> Caused by: org.springframework.transaction.TransactionSystemException:
> UOWManager transaction processing failed; nested exception is
> com.ibm.wsspi.uow.UOWException: javax.transaction.HeuristicMixedException
> at
> org.springframework.transaction.jta.WebSphereUowTransactionManager.execute(WebSphereUowTransactionManager.java:313)
> at example.jta.client.Client.iterateAndCreateTrades(Client.java:93)
> at example.jta.client.Client.loadEntries(Client.java:74)
> Caused by: com.ibm.wsspi.uow.UOWException:
> javax.transaction.HeuristicMixedException
> at
> com.ibm.ws.uow.embeddable.EmbeddableUOWManagerImpl.runUnderNewUOW(EmbeddableUOWManagerImpl.java:757)
> at
> com.ibm.ws.uow.embeddable.EmbeddableUOWManagerImpl.runUnderUOW(EmbeddableUOWManagerImpl.java:329)
> at
> org.springframework.transaction.jta.WebSphereUowTransactionManager.execute(WebSphereUowTransactionManager.java:306)
> Caused by: javax.transaction.HeuristicMixedException
> at com.ibm.tx.jta.impl.TransactionImpl.commit(TransactionImpl.java:715)
> at com.ibm.tx.jta.impl.TranManagerImpl.commit(TranManagerImpl.java:165)
> at com.ibm.tx.jta.impl.TranManagerSet.commit(TranManagerSet.java:113)
> at
> com.ibm.ws.uow.embeddable.EmbeddableUOWManagerImpl.uowCommit(EmbeddableUOWManagerImpl.java:834)
> at
> com.ibm.ws.uow.embeddable.EmbeddableUOWManagerImpl.uowEnd(EmbeddableUOWManagerImpl.java:812)
> at
> com.ibm.ws.uow.embeddable.EmbeddableUOWManagerImpl.runUnderNewUOW(EmbeddableUOWManagerImpl.java:754)
> Caused by: javax.transaction.xa.XAException
> at
> com.ibm.ejs.j2c.LocalTransactionWrapper.commit(LocalTransactionWrapper.java:157)
> at
> com.ibm.tx.jta.impl.OnePhaseResourceImpl.commit_one_phase(OnePhaseResourceImpl.java:113)
> at
> com.ibm.tx.jta.impl.RegisteredResources.flowCommitOnePhase(RegisteredResources.java:2045)
> at
> com.ibm.tx.jta.impl.TransactionImpl.commitXAResources(TransactionImpl.java:1478)
> at
> com.ibm.tx.jta.impl.TransactionImpl.stage1CommitProcessing(TransactionImpl.java:801)
> at
> com.ibm.tx.jta.impl.TransactionImpl.processCommit(TransactionImpl.java:768)
> at com.ibm.tx.jta.impl.TransactionImpl.commit(TransactionImpl.java:711)
> Caused by: javax.resource.spi.LocalTransactionException:
> java.lang.IllegalStateException: Thread does not have an active transaction
> at
> org.apache.geode.internal.ra.spi.JCALocalTransaction.commit(JCALocalTransaction.java:116)
> at
> com.ibm.ejs.j2c.LocalTransactionWrapper.commit(LocalTransactionWrapper.java:145)
> {noformat}
> Here is a truncated version of {{JCALocalTransaction.begin}}:
> {noformat}
> public void begin() throws ResourceException {
> TransactionManager tm = this.cache.getJTATransactionManager();
> if (tm != null && tm.getTransaction() != null) {
> this.gfTxMgr.begin();
> } else {
> if (logger.fineEnabled()) {
> logger.fine("JCAManagedConnection: JTA Transaction does not exist.");
> }
> }
> }
> {noformat}
> It attempts to get the {{TransactionManager}} (which in this case is a
> {{com.ibm.tx.jta.embeddable.impl.EmbeddableTranManagerSet}}). If it is null
> (not bound) or it doesn't have a {{Transaction}} in progress, it logs a
> message at fine level and returns.
> A stack trace in {{JCALocalTransaction.begin}} shows the call stack:
> {noformat}
> java.lang.Exception
> at
> org.apache.geode.internal.ra.spi.JCALocalTransaction.begin(JCALocalTransaction.java:54)
> at
> com.ibm.ejs.j2c.LocalTransactionWrapper.start(LocalTransactionWrapper.java:668)
> at
> com.ibm.ws.Transaction.JTA.JTAResourceBase.start(JTAResourceBase.java:121)
> at
> com.ibm.tx.jta.impl.RegisteredResources.startRes(RegisteredResources.java:835)
> at
> com.ibm.tx.jta.impl.RegisteredResources.enlistResource(RegisteredResources.java:289)
> at
> com.ibm.tx.jta.impl.TransactionImpl.enlistResource
[jira] [Updated] (GEODE-8447) Pulse should localize “java.util.Date” in the displayed query result
[ https://issues.apache.org/jira/browse/GEODE-8447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8447: Fix Version/s: 1.13.1 > Pulse should localize “java.util.Date” in the displayed query result > > > Key: GEODE-8447 > URL: https://issues.apache.org/jira/browse/GEODE-8447 > Project: Geode > Issue Type: Bug > Components: management >Affects Versions: 1.12.0 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available > Fix For: 1.12.1, 1.14.0, 1.13.1 > > Attachments: CreatedOn-lastUpdated.JPG, Date-GF96.JPG > > > In previous versions of Geode, Pulse used to show Dates in localized string, > now it's not. -- This message was sent by Atlassian Jira (v8.3.4#803005)
