[JBoss JIRA] (ISPN-12178) Query broadcast blocks on the non-blocking executor
by Gustavo Fernandes (Jira)
Gustavo Fernandes created ISPN-12178:
----------------------------------------
Summary: Query broadcast blocks on the non-blocking executor
Key: ISPN-12178
URL: https://issues.redhat.com/browse/ISPN-12178
Project: Infinispan
Issue Type: Bug
Components: Embedded Querying
Affects Versions: 12.0.0.Dev01
Reporter: Gustavo Fernandes
Assignee: Gustavo Fernandes
After the migration to HSearch 6, many tests started failing with error 500 during the setup phase to a Blockhoud check in:
{noformat}
java.lang.AssertionError: Blocking call! java.io.RandomAccessFile#readBytes on thread Thread[non-blocking-thread-CacheV2ResourceTest-NodeA-p13-t6,5,ISPN-non-blocking-thread-group]
at org.hibernate.search.backend.lucene.index.impl.LuceneIndexManagerImpl.openIndexReaders(LuceneIndexManagerImpl.java:153)
at org.hibernate.search.backend.lucene.lowlevel.reader.impl.HibernateSearchMultiReader.open(HibernateSearchMultiReader.java:50)
at org.hibernate.search.backend.lucene.orchestration.impl.LuceneSyncWorkOrchestratorImpl$WorkExecution.<init>(LuceneSyncWorkOrchestratorImpl.java:107)
at org.hibernate.search.backend.lucene.orchestration.impl.LuceneSyncWorkOrchestratorImpl.submit(LuceneSyncWorkOrchestratorImpl.java:47)
at org.hibernate.search.backend.lucene.search.query.impl.LuceneSearchQueryImpl.doSubmit(LuceneSearchQueryImpl.java:146)
at org.hibernate.search.backend.lucene.search.query.impl.LuceneSearchQueryImpl.fetch(LuceneSearchQueryImpl.java:93)
at org.hibernate.search.backend.lucene.search.query.impl.LuceneSearchQueryImpl.fetch(LuceneSearchQueryImpl.java:35)
at org.hibernate.search.engine.search.query.spi.AbstractSearchQuery.fetchAll(AbstractSearchQuery.java:35)
at org.infinispan.query.clustered.commandworkers.CQCreateEagerQuery.collectKeys(CQCreateEagerQuery.java:33)
at org.infinispan.query.clustered.commandworkers.CQCreateEagerQuery.perform(CQCreateEagerQuery.java:25)
at org.infinispan.query.clustered.commandworkers.CQCommandType.perform(CQCommandType.java:44)
at org.infinispan.query.clustered.ClusteredQueryOperation.perform(ClusteredQueryOperation.java:54)
at org.infinispan.query.clustered.SegmentsClusteredQueryCommand.perform(SegmentsClusteredQueryCommand.java:45)
{noformat}
The side effect are resources leaks in several tests
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months
[JBoss JIRA] (ISPN-7166) WriteSkewConsistencyTest.testValidationOnlyInPrimaryOwner[DIST_SYNC] random failures
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-7166?page=com.atlassian.jira.plugin... ]
Dan Berindei updated ISPN-7166:
-------------------------------
Fix Version/s: (was: 11.0.2.Final)
> WriteSkewConsistencyTest.testValidationOnlyInPrimaryOwner[DIST_SYNC] random failures
> ------------------------------------------------------------------------------------
>
> Key: ISPN-7166
> URL: https://issues.redhat.com/browse/ISPN-7166
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 9.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 12.0.0.Dev02
>
>
> The test requires a key to have a specific primary owner and backup owner, but because is uses the default {{SynchronizedConsistentHashFactory}}, sometimes there's no segment meeting that requirement.
> {noformat}
> 16:52:02,516 ERROR (testng-WriteSkewConsistencyTest[DIST_SYNC]:[]) [TestSuiteProgress] Test failed: org.infinispan.container.versioning.WriteSkewConsistencyTest.testValidationOnlyInPrimaryOwner[DIST_SYNC]
> java.lang.IllegalStateException: Could not find any segment owned by Cache '___defaultcache'@WriteSkewConsistencyTest[DIST_SYNC]-NodeB-47455, [Cache '___defaultcache'@WriteSkewConsistencyTest[DIST_SYNC]-NodeA-21455], primary segments: [33, 2, 3, 5, 37, 6, 41, 10, 45, 15, 48, 18, 50, 25, 59, 29], backup segments: {Cache '___defaultcache'@WriteSkewConsistencyTest[DIST_SYNC]-NodeA-21455=[35, 8, 40, 12, 14, 52, 21, 53, 22, 24, 57, 58, 27, 31]}
> at org.infinispan.distribution.MagicKey.<init>(MagicKey.java:85) ~[test-classes/:?]
> at org.infinispan.distribution.MagicKey.<init>(MagicKey.java:136) ~[test-classes/:?]
> at org.infinispan.container.versioning.WriteSkewConsistencyTest.testValidationOnlyInPrimaryOwner(WriteSkewConsistencyTest.java:58) ~[test-classes/:?]
> {noformat}
> The test should either use a fixed key and accept random owners, or use a {{ControlledConsistentHashFactory}} to pin the owners.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months
[JBoss JIRA] (ISPN-7166) WriteSkewConsistencyTest.testValidationOnlyInPrimaryOwner[DIST_SYNC] random failures
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-7166?page=com.atlassian.jira.plugin... ]
Gustavo Fernandes updated ISPN-7166:
------------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/4643, https://github.com/infinispan/infinispan/pull/8563, https://github.com/infinispan/infinispan/pull/8599 (was: https://github.com/infinispan/infinispan/pull/4643, https://github.com/infinispan/infinispan/pull/8563)
> WriteSkewConsistencyTest.testValidationOnlyInPrimaryOwner[DIST_SYNC] random failures
> ------------------------------------------------------------------------------------
>
> Key: ISPN-7166
> URL: https://issues.redhat.com/browse/ISPN-7166
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 9.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 11.0.2.Final, 12.0.0.Dev02
>
>
> The test requires a key to have a specific primary owner and backup owner, but because is uses the default {{SynchronizedConsistentHashFactory}}, sometimes there's no segment meeting that requirement.
> {noformat}
> 16:52:02,516 ERROR (testng-WriteSkewConsistencyTest[DIST_SYNC]:[]) [TestSuiteProgress] Test failed: org.infinispan.container.versioning.WriteSkewConsistencyTest.testValidationOnlyInPrimaryOwner[DIST_SYNC]
> java.lang.IllegalStateException: Could not find any segment owned by Cache '___defaultcache'@WriteSkewConsistencyTest[DIST_SYNC]-NodeB-47455, [Cache '___defaultcache'@WriteSkewConsistencyTest[DIST_SYNC]-NodeA-21455], primary segments: [33, 2, 3, 5, 37, 6, 41, 10, 45, 15, 48, 18, 50, 25, 59, 29], backup segments: {Cache '___defaultcache'@WriteSkewConsistencyTest[DIST_SYNC]-NodeA-21455=[35, 8, 40, 12, 14, 52, 21, 53, 22, 24, 57, 58, 27, 31]}
> at org.infinispan.distribution.MagicKey.<init>(MagicKey.java:85) ~[test-classes/:?]
> at org.infinispan.distribution.MagicKey.<init>(MagicKey.java:136) ~[test-classes/:?]
> at org.infinispan.container.versioning.WriteSkewConsistencyTest.testValidationOnlyInPrimaryOwner(WriteSkewConsistencyTest.java:58) ~[test-classes/:?]
> {noformat}
> The test should either use a fixed key and accept random owners, or use a {{ControlledConsistentHashFactory}} to pin the owners.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months
[JBoss JIRA] (IPROTO-146) Add marshalling support for java.time.* classes
by William Watson (Jira)
William Watson created IPROTO-146:
-------------------------------------
Summary: Add marshalling support for java.time.* classes
Key: IPROTO-146
URL: https://issues.redhat.com/browse/IPROTO-146
Project: Infinispan ProtoStream
Issue Type: Feature Request
Affects Versions: 4.3.3.Final
Reporter: William Watson
Add marshalling support for these commonly used, {{serializable}} classes:
* {{java.time.LocalDate}}
* {{java.time.LocalDateTime}}
* {{java.time.LocalTime}}
* {{java.time.MonthDay}}
* {{java.time.Year}}
* {{java.time.YearMonth}}
* {{java.time.ZonedDateTime}}
* {{java.time.ZoneId}}
* {{java.time.ZoneOffset}}
This will make it easier for developers who are use {{@ProtoField}} on objects with member variables of these types.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months
[JBoss JIRA] (ISPN-11841) Listener leaking and produce OOM error
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11841?page=com.atlassian.jira.plugi... ]
Dan Berindei commented on ISPN-11841:
-------------------------------------
Also fixed in 10.0 with ISPN-9849
> Listener leaking and produce OOM error
> --------------------------------------
>
> Key: ISPN-11841
> URL: https://issues.redhat.com/browse/ISPN-11841
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 9.4.19.Final
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Critical
> Fix For: 9.4.20.Final
>
>
> Register Listener will end up in a OutOfMemory error because it is never unregistered.
> A Listener will be added per client connection and never removed.
> Here TransactionRequestProcessor has a bug.
> HeapDump analysis will show
> {quote}
> java.lang.Thread @ 0x760886888 timeout-thread--p3-t1 Native Stack, Thread
> '- <Java Local> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue @ 0x76088ab00
> '- queue java.util.concurrent.RunnableScheduledFuture[24] @ 0x760ec5ef0
> '- [0] java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask @ 0x7617bde40
> '- callable java.util.concurrent.Executors$RunnableAdapter @ 0x7618b76c0
> '- task org.infinispan.transaction.impl.TransactionTable$$Lambda$692 @ 0x7618b76d8
> '- arg$1 org.infinispan.transaction.impl.TransactionTable @ 0x761617028
> '- cacheManagerNotifier org.infinispan.notifications.cachemanagerlistener.CacheManagerNotifierImpl @ 0x760f67878
> '- cacheStoppedListeners java.util.concurrent.CopyOnWriteArrayList @ 0x762068998
> '- array java.lang.Object[647063] @ 0x7951cb888
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months
[JBoss JIRA] (ISPN-3729) Minimize the number of moved segments for SyncConsistentHashFactory
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-3729?page=com.atlassian.jira.plugin... ]
Dan Berindei closed ISPN-3729.
------------------------------
Fix Version/s: 11.0.0.Final
Resolution: Done
Fixed with ISPN-11679
> Minimize the number of moved segments for SyncConsistentHashFactory
> -------------------------------------------------------------------
>
> Key: ISPN-3729
> URL: https://issues.redhat.com/browse/ISPN-3729
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 11.0.0.Final
>
>
> SyncConsistentHash uses an algorithm that's similar to consistent hashing, but when there is a collision (two nodes map to the same segment), the second node is moved to the next segment. Since the nodes are ordered by their UUID, that means it's possible for a joiner to change the mapping of existing nodes.
> In order to make the load distribution more even, SyncConsistentHash also uses "virtual nodes": each node actually maps to multiple segments. This makes the number of collisions much higher (and implicitly, the number of extra moved segments).
> Reading the original [consistent hashing paper|http://thor.cs.ucsb.edu/~ravenben/papers/coreos/kll%2B97.pdf], it looks like the collision handling should be done differently: a joiner should replace an existing node when it's "closer" to the segment boundary, but the existing node should never "lose" segments to another existing node (the property of monotonicity mentioned in the paper). We should investigate whether changing this would allow us to achieve better load balancing by using a much higher number of "virtual nodes" (without moving extra segments). If successful, we could even use SyncConsistentHashFactory as the default hash algorithm.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months
[JBoss JIRA] (ISPN-7166) WriteSkewConsistencyTest.testValidationOnlyInPrimaryOwner[DIST_SYNC] random failures
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-7166?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-7166:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> WriteSkewConsistencyTest.testValidationOnlyInPrimaryOwner[DIST_SYNC] random failures
> ------------------------------------------------------------------------------------
>
> Key: ISPN-7166
> URL: https://issues.redhat.com/browse/ISPN-7166
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 9.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 11.0.2.Final, 12.0.0.Dev02
>
>
> The test requires a key to have a specific primary owner and backup owner, but because is uses the default {{SynchronizedConsistentHashFactory}}, sometimes there's no segment meeting that requirement.
> {noformat}
> 16:52:02,516 ERROR (testng-WriteSkewConsistencyTest[DIST_SYNC]:[]) [TestSuiteProgress] Test failed: org.infinispan.container.versioning.WriteSkewConsistencyTest.testValidationOnlyInPrimaryOwner[DIST_SYNC]
> java.lang.IllegalStateException: Could not find any segment owned by Cache '___defaultcache'@WriteSkewConsistencyTest[DIST_SYNC]-NodeB-47455, [Cache '___defaultcache'@WriteSkewConsistencyTest[DIST_SYNC]-NodeA-21455], primary segments: [33, 2, 3, 5, 37, 6, 41, 10, 45, 15, 48, 18, 50, 25, 59, 29], backup segments: {Cache '___defaultcache'@WriteSkewConsistencyTest[DIST_SYNC]-NodeA-21455=[35, 8, 40, 12, 14, 52, 21, 53, 22, 24, 57, 58, 27, 31]}
> at org.infinispan.distribution.MagicKey.<init>(MagicKey.java:85) ~[test-classes/:?]
> at org.infinispan.distribution.MagicKey.<init>(MagicKey.java:136) ~[test-classes/:?]
> at org.infinispan.container.versioning.WriteSkewConsistencyTest.testValidationOnlyInPrimaryOwner(WriteSkewConsistencyTest.java:58) ~[test-classes/:?]
> {noformat}
> The test should either use a fixed key and accept random owners, or use a {{ControlledConsistentHashFactory}} to pin the owners.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months
[JBoss JIRA] (ISPN-12148) Hibernate-cache NullPointerException in CacheMgmtInterceptor
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-12148?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-12148:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Hibernate-cache NullPointerException in CacheMgmtInterceptor
> ------------------------------------------------------------
>
> Key: ISPN-12148
> URL: https://issues.redhat.com/browse/ISPN-12148
> Project: Infinispan
> Issue Type: Bug
> Components: Hibernate Cache
> Affects Versions: 11.0.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 12.0.0.Dev02
>
>
> There is a mismatch between the {{command.hasAnyFlag(FlagBitSets.SKIP_STATISTICS)}} check in {{CacheMgmtInterceptor}} and the {{Param.StatisticsMode.isSkip(command.getParams())}} check in {{CallInterceptor}}, causing the return value to be {{null}} when {{CacheMgmtInterceptor}} expects a {{StatisticsEnvelope}} instance.
>
> {noformat}
> 17:02:05,601 ERROR (Executor-2:[]) [InvocationContextInterceptor] ISPN000136: Error executing command ReadWriteKeyCommand on Cache 'org.infinispan.test.hibernate.cache.commons.functional.entities.Item', writing keys [7]
> java.lang.NullPointerException: null
> at org.infinispan.interceptors.impl.CacheMgmtInterceptor.lambda$updateStatisticsReadWrite$10(CacheMgmtInterceptor.java:372) ~[classes/:?]
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenApply(BaseAsyncInterceptor.java:86) ~[classes/:?]
> at org.infinispan.interceptors.impl.CacheMgmtInterceptor.updateStatisticsReadWrite(CacheMgmtInterceptor.java:368) ~[classes/:?]
> at org.infinispan.interceptors.impl.CacheMgmtInterceptor.visitReadWriteKeyCommand(CacheMgmtInterceptor.java:396) ~[classes/:?]
> at org.infinispan.commands.functional.ReadWriteKeyCommand.acceptVisitor(ReadWriteKeyCommand.java:91) ~[classes/:?]
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:59) ~[classes/:?]
> at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:53) ~[classes/:?]
> at org.infinispan.interceptors.DDAsyncInterceptor.visitReadWriteKeyCommand(DDAsyncInterceptor.java:200) ~[classes/:?]
> at org.infinispan.commands.functional.ReadWriteKeyCommand.acceptVisitor(ReadWriteKeyCommand.java:91) ~[classes/:?]
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:128) ~[classes/:?]
> at org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:90) ~[classes/:?]
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:61) ~[classes/:?]
> at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:53) ~[classes/:?]
> at org.infinispan.interceptors.DDAsyncInterceptor.visitReadWriteKeyCommand(DDAsyncInterceptor.java:200) ~[classes/:?]
> at org.infinispan.commands.functional.ReadWriteKeyCommand.acceptVisitor(ReadWriteKeyCommand.java:91) ~[classes/:?]
> at org.infinispan.interceptors.DDAsyncInterceptor.visitCommand(DDAsyncInterceptor.java:49) ~[classes/:?]
> at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invokeAsync(AsyncInterceptorChainImpl.java:226) ~[classes/:?]
> at org.infinispan.functional.impl.AbstractFunctionalMap.invokeAsync(AbstractFunctionalMap.java:131) ~[classes/:?]
> at org.infinispan.functional.impl.ReadWriteMapImpl.eval(ReadWriteMapImpl.java:56) ~[classes/:?]
> at org.infinispan.hibernate.cache.commons.access.NonStrictAccessDelegate.putFromLoad(NonStrictAccessDelegate.java:118) ~[classes/:?]
> at org.infinispan.hibernate.cache.v53.impl.ReadOnlyEntityDataAccess.putFromLoad(ReadOnlyEntityDataAccess.java:30) ~[classes/:?]
> at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:254) ~[hibernate-core-5.3.17.Final.jar:5.3.17.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:160) ~[hibernate-core-5.3.17.Final.jar:5.3.17.Final]
> at org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.performTwoPhaseLoad(AbstractRowReader.java:252) ~[hibernate-core-5.3.17.Final.jar:5.3.17.Final]
> at org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.finishUp(AbstractRowReader.java:215) ~[hibernate-core-5.3.17.Final.jar:5.3.17.Final]
> at org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:133) ~[hibernate-core-5.3.17.Final.jar:5.3.17.Final]
> at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:107) ~[hibernate-core-5.3.17.Final.jar:5.3.17.Final]
> at org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:188) ~[hibernate-core-5.3.17.Final.jar:5.3.17.Final]
> at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4289) ~[hibernate-core-5.3.17.Final.jar:5.3.17.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:597) ~[hibernate-core-5.3.17.Final.jar:5.3.17.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:565) ~[hibernate-core-5.3.17.Final.jar:5.3.17.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:226) ~[hibernate-core-5.3.17.Final.jar:5.3.17.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:122) ~[hibernate-core-5.3.17.Final.jar:5.3.17.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:93) ~[hibernate-core-5.3.17.Final.jar:5.3.17.Final]
> at org.hibernate.internal.SessionImpl.fireLoadNoChecks(SessionImpl.java:1277) ~[hibernate-core-5.3.17.Final.jar:5.3.17.Final]
> at org.hibernate.internal.SessionImpl.immediateLoad(SessionImpl.java:1119) ~[hibernate-core-5.3.17.Final.jar:5.3.17.Final]
> at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:178) ~[hibernate-core-5.3.17.Final.jar:5.3.17.Final]
> at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:309) ~[hibernate-core-5.3.17.Final.jar:5.3.17.Final]
> at org.hibernate.proxy.pojo.bytebuddy.ByteBuddyInterceptor.intercept(ByteBuddyInterceptor.java:45) ~[hibernate-core-5.3.17.Final.jar:5.3.17.Final]
> at org.hibernate.proxy.ProxyConfiguration$InterceptorDispatcher.intercept(ProxyConfiguration.java:95) ~[hibernate-core-5.3.17.Final.jar:5.3.17.Final]
> at org.infinispan.test.hibernate.cache.commons.functional.entities.Item$HibernateProxy$vC8GnuyS.getName(Unknown Source) ~[test-classes/:?]
> at org.infinispan.test.hibernate.cache.commons.functional.AbstractNonInvalidationTest.lambda$removeFlushWait$2(AbstractNonInvalidationTest.java:127) ~[test-classes/:?]
> at org.infinispan.test.hibernate.cache.commons.util.TxUtil.withResourceLocalTx(TxUtil.java:105) ~[test-classes/:?]
> at org.infinispan.test.hibernate.cache.commons.util.TxUtil.lambda$withTxSessionApply$5(TxUtil.java:56) ~[test-classes/:?]
> at org.infinispan.test.hibernate.cache.commons.util.TxUtil.withSessionApply(TxUtil.java:72) ~[test-classes/:?]
> at org.infinispan.test.hibernate.cache.commons.util.TxUtil.withTxSessionApply(TxUtil.java:56) ~[test-classes/:?]
> at org.infinispan.test.hibernate.cache.commons.functional.SingleNodeTest.withTxSessionApply(SingleNodeTest.java:43) ~[test-classes/:?]
> at org.infinispan.test.hibernate.cache.commons.functional.AbstractNonInvalidationTest.lambda$removeFlushWait$3(AbstractNonInvalidationTest.java:124) ~[test-classes/:?]
> {noformat}
>
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months