[JBoss JIRA] (ISPN-11158) Docs: index.html improvements and productization
by Donald Naro (Jira)
[ https://issues.redhat.com/browse/ISPN-11158?page=com.atlassian.jira.plugi... ]
Donald Naro updated ISPN-11158:
-------------------------------
Description: Improve index.html to make it easier to find info. Also sort out Admin/Config Guides. (was: Productization, exclude chapters that are not ready for qe validation in Server Guide and Configuring.
Community, improve index.html to make it easier to find info. Also sort out Admin/Config Guides.)
> Docs: index.html improvements and productization
> ------------------------------------------------
>
> Key: ISPN-11158
> URL: https://issues.redhat.com/browse/ISPN-11158
> Project: Infinispan
> Issue Type: Enhancement
> Components: Documentation
> Reporter: Donald Naro
> Assignee: Donald Naro
> Priority: Major
>
> Improve index.html to make it easier to find info. Also sort out Admin/Config Guides.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-10473) Interceptor chain is null for hibernate collection caches
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-10473?page=com.atlassian.jira.plugi... ]
Dan Berindei commented on ISPN-10473:
-------------------------------------
[~rvansa] was 2LC really intended to use a functional map on simple caches, or is this an oversight?
We've changed the simple cache so it no longer registers an {{AsyncInterceptorChain}} component in the registry and that causes the NPE.
But IIRC simple caches weren't supposed to have an interceptor chain, so I don't see how functional maps were supposed to work with them.
> Interceptor chain is null for hibernate collection caches
> ---------------------------------------------------------
>
> Key: ISPN-10473
> URL: https://issues.redhat.com/browse/ISPN-10473
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.4.16.Final
> Reporter: Moritz Becker
> Priority: Major
>
> {noformat}
> Caused by: java.lang.NullPointerException
> at org.infinispan.functional.impl.AbstractFunctionalMap.invokeAsync(AbstractFunctionalMap.java:127) ~[infinispan-core-9.4.15.Final.jar:9.4.15.Final]
> at org.infinispan.functional.impl.ReadWriteMapImpl.eval(ReadWriteMapImpl.java:56) ~[infinispan-core-9.4.15.Final.jar:9.4.15.Final]
> at org.infinispan.hibernate.cache.commons.access.NonStrictAccessDelegate.putFromLoad(NonStrictAccessDelegate.java:118) ~[infinispan-hibernate-cache-commons-9.4.15.Final.jar:9.4.15.Final]
> at org.infinispan.hibernate.cache.v53.impl.CollectionDataAccessImpl.putFromLoad(CollectionDataAccessImpl.java:30) ~[infinispan-hibernate-cache-v53-9.4.15.Final.jar:9.4.15.Final]
> at org.hibernate.engine.loading.internal.CollectionLoadContext.addCollectionToCache(CollectionLoadContext.java:390) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.engine.loading.internal.CollectionLoadContext.endLoadingCollection(CollectionLoadContext.java:295) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.engine.loading.internal.CollectionLoadContext.endLoadingCollections(CollectionLoadContext.java:223) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.engine.loading.internal.CollectionLoadContext.endLoadingCollections(CollectionLoadContext.java:196) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.loader.Loader.endCollectionLoad(Loader.java:1198) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1162) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.loader.Loader.processResultSet(Loader.java:1010) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.loader.Loader.doQuery(Loader.java:948) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:340) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2689) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2672) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2506) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.loader.Loader.list(Loader.java:2501) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:504) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:395) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:220) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1508) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.query.internal.AbstractProducedQuery.doList(AbstractProducedQuery.java:1537) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.query.internal.AbstractProducedQuery.list(AbstractProducedQuery.java:1505) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.query.Query.getResultList(Query.java:135) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> {noformat}
> This is because the collection cache is defined as simple cache and {{org.infinispan.factories.InterceptorChainFactory#construct}} returns null if {{configuration.simpleCache()}} is true. As far as I can see, this behavior has changed in 10.x, commit 55682f391d0f6e28dd6be4ab780cb9e62a639fbd where {{EmptyAsyncInterceptorChain.INSTANCE}} is returned in this case.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-11179) server-runtime test suite reports thread leaks
by Dan Berindei (Jira)
Dan Berindei created ISPN-11179:
-----------------------------------
Summary: server-runtime test suite reports thread leaks
Key: ISPN-11179
URL: https://issues.redhat.com/browse/ISPN-11179
Project: Infinispan
Issue Type: Bug
Components: Server, Test Suite
Affects Versions: 10.1.0.Final
Reporter: Dan Berindei
Fix For: 10.1.1.Final
{{Testcontainers}} connects to the Docker daemon using the REST API over the Unix socket at {{/var/run/docker.sock}} (using {{dockerjava}} and {{OkHttpClient}}).
Following logs requires a long-running connection, and {{LogUtils.attachConsumer}} discards the stream from OkHttpClient/dockerjava, so the connection is never closed. Perhaps the Testcontainers authors assumed that the docker server will kill the connection when the container is stopped, but that doesn't happen.
{noformat}
testng-ResilienceIT starting thread tc-okhttp-stream-1106493516
at org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder.executeAndStream(OkHttpInvocationBuilder.java:322)
at org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder.executeAndStream(OkHttpInvocationBuilder.java:295)
at org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder.get(OkHttpInvocationBuilder.java:89)
at com.github.dockerjava.core.exec.LogContainerCmdExec.execute0(LogContainerCmdExec.java:42)
at com.github.dockerjava.core.exec.LogContainerCmdExec.execute0(LogContainerCmdExec.java:12)
at com.github.dockerjava.core.exec.AbstrAsyncDockerCmdExec.execute(AbstrAsyncDockerCmdExec.java:56)
at com.github.dockerjava.core.exec.AbstrAsyncDockerCmdExec.exec(AbstrAsyncDockerCmdExec.java:21)
at com.github.dockerjava.core.exec.AbstrAsyncDockerCmdExec.exec(AbstrAsyncDockerCmdExec.java:12)
at com.github.dockerjava.core.command.AbstrAsyncDockerCmd.exec(AbstrAsyncDockerCmd.java:21)
at org.testcontainers.utility.LogUtils.attachConsumer(LogUtils.java:99)
at org.testcontainers.utility.LogUtils.followOutput(LogUtils.java:36)
at org.testcontainers.utility.LogUtils.followOutput(LogUtils.java:51)
at org.testcontainers.containers.Container.followOutput(Container.java:391)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
at org.testcontainers.containers.GenericContainer.tryStart(GenericContainer.java:412)
at org.testcontainers.containers.GenericContainer.lambda$doStart$0(GenericContainer.java:317)
at org.rnorth.ducttape.unreliables.Unreliables.retryUntilSuccess(Unreliables.java:81)
at org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:315)
at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:302)
at org.infinispan.server.test.ContainerInfinispanServerDriver.start(ContainerInfinispanServerDriver.java:146)
at org.infinispan.server.test.InfinispanServerDriver.start(InfinispanServerDriver.java:109)
at org.infinispan.server.test.InfinispanServerRule$1.evaluate(InfinispanServerRule.java:86)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-11139) Create separate modules for embedded and remote JCache TCK
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11139?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11139:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Create separate modules for embedded and remote JCache TCK
> ----------------------------------------------------------
>
> Key: ISPN-11139
> URL: https://issues.redhat.com/browse/ISPN-11139
> Project: Infinispan
> Issue Type: Task
> Components: JCache, Test Suite
> Affects Versions: 10.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.1.1.Final
>
>
> The {{jcache-tck-runner}} POM is very complex, because it needs both the embedded and the remote dependencies, and then needs two {{maven-failsafe-plugin}} executions that filter out unneeded dependencies.
> Having two separate modules will simplify the POMs and will also allow running the embedded TCK without starting (and building!) the server.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-11175) Improve Log::unsupportedConfiguration method adding that a missing dependency can cause the issue
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11175?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11175:
-----------------------------------
Fix Version/s: 9.4.18.Final
> Improve Log::unsupportedConfiguration method adding that a missing dependency can cause the issue
> -------------------------------------------------------------------------------------------------
>
> Key: ISPN-11175
> URL: https://issues.redhat.com/browse/ISPN-11175
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 10.1.0.Final
> Reporter: Diego Lovison
> Assignee: Diego Lovison
> Priority: Minor
> Fix For: 10.1.1.Final, 9.4.18.Final
>
>
> The config file {{string-based.xml}} is not working
> {code:java}
> new DefaultCacheManager("/path/to/persistence/jdbc/src/test/resources/configs/string-based.xml")
> {code}
> {noformat}
> org.infinispan.commons.CacheConfigurationException: ISPN000327: Cannot find a parser for element 'string-keyed-jdbc-store' in namespace ''. Check that your configuration is up-to date for this version of Infinispan.
> at org.infinispan.configuration.parsing.ParserRegistry.parseElement(ParserRegistry.java:174)
> at org.infinispan.configuration.parsing.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:38)
> at org.infinispan.configuration.parsing.Parser.parsePersistence(Parser.java:2361)
> at org.infinispan.configuration.parsing.Parser.parseCacheElement(Parser.java:1544)
> at org.infinispan.configuration.parsing.Parser.parseLocalCache(Parser.java:1248)
> at org.infinispan.configuration.parsing.Parser.parseContainer(Parser.java:579)
> at org.infinispan.configuration.parsing.Parser.readElement(Parser.java:116)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months