[JBoss JIRA] (ISPN-5270) Deadlock in InfinispanDirectoryProvider startup
by Nistor Adrian (Jira)
[ https://issues.redhat.com/browse/ISPN-5270?page=com.atlassian.jira.plugin... ]
Nistor Adrian closed ISPN-5270.
-------------------------------
Resolution: Out of Date
> Deadlock in InfinispanDirectoryProvider startup
> -----------------------------------------------
>
> Key: ISPN-5270
> URL: https://issues.redhat.com/browse/ISPN-5270
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 7.2.0.Alpha1, 7.1.1.Final
> Reporter: Dan Berindei
> Assignee: Nistor Adrian
> Priority: Minor
> Attachments: surefire.stacks, surefire2.stacks
>
>
> The InfinispanDirectoryProvider tries to start the metadata, data, and locking caches when it starts up, with {{DefaultCacheManager.startCaches()}}.
> However, when one of these caches (e.g. the metadata cache) starts, the {{LifecycleManager.cacheStarting()}}, which can then try to start the InfinispanDirectoryProvider again:
> {noformat}
> "CacheStartThread,null,LuceneIndexesMetadata" prio=10 tid=0x00007f5f74484000 nid=0xe42 in Object.wait() [0x00007f5efff48000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000000c2180000> (a org.infinispan.manager.DefaultCacheManager$1)
> at java.lang.Thread.join(Thread.java:1281)
> - locked <0x00000000c2180000> (a org.infinispan.manager.DefaultCacheManager$1)
> at java.lang.Thread.join(Thread.java:1355)
> at org.infinispan.manager.DefaultCacheManager.startCaches(DefaultCacheManager.java:465)
> at org.hibernate.search.infinispan.spi.InfinispanDirectoryProvider.start(InfinispanDirectoryProvider.java:84)
> at org.hibernate.search.indexes.spi.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:88)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:256)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:513)
> - locked <0x00000000ce6001d0> (a org.hibernate.search.indexes.impl.IndexManagerHolder)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManagers(IndexManagerHolder.java:482)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:91)
> - locked <0x00000000ce6001d0> (a org.hibernate.search.indexes.impl.IndexManagerHolder)
> at org.hibernate.search.spi.SearchIntegratorBuilder.initDocumentBuilders(SearchIntegratorBuilder.java:366)
> at org.hibernate.search.spi.SearchIntegratorBuilder.buildNewSearchFactory(SearchIntegratorBuilder.java:204)
> at org.hibernate.search.spi.SearchIntegratorBuilder.buildSearchIntegrator(SearchIntegratorBuilder.java:122)
> at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:35)
> at org.infinispan.query.impl.LifecycleManager.getSearchFactory(LifecycleManager.java:260)
> at org.infinispan.query.impl.LifecycleManager.cacheStarting(LifecycleManager.java:102)
> at org.infinispan.factories.ComponentRegistry.notifyCacheStarting(ComponentRegistry.java:230)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
> at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:814)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:591)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:546)
> at org.infinispan.manager.DefaultCacheManager.access$100(DefaultCacheManager.java:115)
> at org.infinispan.manager.DefaultCacheManager$1.run(DefaultCacheManager.java:452)
> {noformat}
> This can hang the test, the attached thread dumps show {{EmbeddedCompatTest}} and {{IndexCacheStopTest}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (ISPN-3961) Search across multiple caches
by Nistor Adrian (Jira)
[ https://issues.redhat.com/browse/ISPN-3961?page=com.atlassian.jira.plugin... ]
Nistor Adrian closed ISPN-3961.
-------------------------------
Resolution: Won't Do
This is an old nice-to-have that we've lived well and happy without it so we'll never implement this.
> Search across multiple caches
> -----------------------------
>
> Key: ISPN-3961
> URL: https://issues.redhat.com/browse/ISPN-3961
> Project: Infinispan
> Issue Type: Feature Request
> Components: Embedded Querying, Remote Querying
> Reporter: Nistor Adrian
> Priority: Major
>
> This would conceptually mean moving the SearchManager from Cache scope to CacheManager scope, which would allow us to share HS search factory. Would also need to add indexing configuration at cache manager level.
> Having a SearchManager at cache scope would still be desired for cases where the user needs to configure particular indexing settings for certain caches.
> Regarding indexes, we could have one index per class or one index per class + cache name; remains to be decided.
> See discussion here: http://markmail.org/message/oe4jeq4k73f44rts
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (ISPN-11201) Operator Docs: Final review feedback
by Donald Naro (Jira)
[ https://issues.redhat.com/browse/ISPN-11201?page=com.atlassian.jira.plugi... ]
Donald Naro updated ISPN-11201:
-------------------------------
Description:
Some review feedback from Galder. Needs backport to 1.1.x.
1. Remove xsite url. Not implemented.
- name: google
url: xsite://google.host:23456
2. backups should say locations
3. "defines local and backup sites"
4. In " JVM, CPU, and Memory Resources", can you explain that the cpu/memory set is used to set the pod cpu/memory limits. And also say that in terms of pod cpu requets, it sets half of that. For memory requests, it sets the same as memory limits. https://medium.com/@betz.mark/understanding-resource-limits-in-kubernetes... is a good document that explains the difference between requests and limits
5. add is "<name>-sites" service to the reference. That's created when x-site is enabled. This is independent of the external service
was:
Some review feedback from Galder. Needs backport to 1.1.x.
> Operator Docs: Final review feedback
> ------------------------------------
>
> Key: ISPN-11201
> URL: https://issues.redhat.com/browse/ISPN-11201
> Project: Infinispan
> Issue Type: Task
> Components: Documentation
> Reporter: Donald Naro
> Assignee: Donald Naro
> Priority: Major
>
> Some review feedback from Galder. Needs backport to 1.1.x.
> 1. Remove xsite url. Not implemented.
> - name: google
> url: xsite://google.host:23456
> 2. backups should say locations
> 3. "defines local and backup sites"
> 4. In " JVM, CPU, and Memory Resources", can you explain that the cpu/memory set is used to set the pod cpu/memory limits. And also say that in terms of pod cpu requets, it sets half of that. For memory requests, it sets the same as memory limits. https://medium.com/@betz.mark/understanding-resource-limits-in-kubernetes... is a good document that explains the difference between requests and limits
> 5. add is "<name>-sites" service to the reference. That's created when x-site is enabled. This is independent of the external service
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (ISPN-11179) server-runtime test suite okhttp thread leaks
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11179?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11179:
--------------------------------
Status: Open (was: New)
> server-runtime test suite okhttp 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
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.1.2.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)
6 years, 2 months