[JBoss JIRA] (ISPN-10352) Externalize all code and config samples in docs
by Donald Naro (Jira)
Donald Naro created ISPN-10352:
----------------------------------
Summary: Externalize all code and config samples in docs
Key: ISPN-10352
URL: https://issues.jboss.org/browse/ISPN-10352
Project: Infinispan
Issue Type: Enhancement
Components: Documentation-Core
Affects Versions: 10.0.0.Beta4
Reporter: Donald Naro
Assignee: Donald Naro
All code samples in docs should be run and tested …
[View More]at build time. Externalize all code samples to a separate directory and include them. Do the same for all config samples in any format, yaml, xml, and so on.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
[View Less]
5 years, 7 months
[JBoss JIRA] (ISPN-10350) Reduce operator product image size
by Galder Zamarreño (Jira)
Galder Zamarreño created ISPN-10350:
---------------------------------------
Summary: Reduce operator product image size
Key: ISPN-10350
URL: https://issues.jboss.org/browse/ISPN-10350
Project: Infinispan
Issue Type: Task
Components: Operator
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
So far with the work of JDG-2976, the operator product image is around ~350mb.
The reason …
[View More]this is so big is cos the image where the operator lives when the operator is built is the same image that builds the operator itself. There's a couple of reasons that would explain the big size: base image and leftover from build.
The base image right now is the standard UBI image. I tried to use UBI-minimal, but the tooling available there is not as advanced (e.g. yum vs microdnf), and as a result of that, after building the operator you're not able to do cleanup in the same way (microdnf does not have autoremove option). Without digging into the details, the resulting image with UBI minimal was ~700mb.
So, the aim of this JIRA is to reduce the image to only have the bare minimal plus the operator binary. This is not urgent but needs some deeper understanding.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
[View Less]
5 years, 7 months
[JBoss JIRA] (ISPN-10346) InitialClusterSizeTest thread leak
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10346?page=com.atlassian.jira.plugin... ]
Dan Berindei updated ISPN-10346:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/7090
> InitialClusterSizeTest thread leak
> ----------------------------------
>
> Key: ISPN-10346
> URL: https://issues.jboss.org/browse/ISPN-10346
> Project: …
[View More]Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 10.0.0.Beta3
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Beta4
>
>
> I got a thread leak when running the test suite with trace logging enabled and {{taskset -c 1-2}}:
> {noformat}
> 17:06:05,307 DEBUG (testng-Test:[]) [TestSuiteProgress] Test configuration finished: org.infinispan.remoting.transport.InitialClusterSizeTest.testClassFinished
> 17:15:17,284 ERROR [TestSuiteProgress] Test failed: InitialClusterSizeTest.ThreadLeakChecker
> java.lang.RuntimeException: Leaked thread Controller-remote-thread-InitialClusterSizeTest-NodeB
> at jdk.internal.misc.Unsafe.park(Native Method) ~[?:?]
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) ~[?:?]
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:885) ~[?:?]
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1039) ~[?:?]
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1345) ~[?:?]
> at java.util.concurrent.Semaphore.acquire(Semaphore.java:318) ~[?:?]
> at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl$ControllerThread.run(BlockingTaskAwareExecutorServiceImpl.java:159) ~[classes/:?]
> {noformat}
> I believe it may be caused by {{doExecute()}} adding a task to the blocked tasks queue without calling {{checkForReadyTasks()}} (after the executor rejected the task). {{ControllerThread.run()}} needs a semaphore permit to start polling for tasks, so it needs a {{semaphore.release()}} after each {{blockedTasks.add().
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
[View Less]
5 years, 7 months
[JBoss JIRA] (ISPN-10346) InitialClusterSizeTest thread leak
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10346?page=com.atlassian.jira.plugin... ]
Dan Berindei updated ISPN-10346:
--------------------------------
Summary: InitialClusterSizeTest thread leak (was: BlockingTaskAwareExecutorServiceImpl may leak controller thread)
> InitialClusterSizeTest thread leak
> ----------------------------------
>
> Key: ISPN-10346
> URL: https://issues.jboss.org/browse/ISPN-10346
> Project: Infinispan
…
[View More]> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 10.0.0.Beta3
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Beta4
>
>
> I got a thread leak when running the test suite with trace logging enabled and {{taskset -c 1-2}}:
> {noformat}
> 17:06:05,307 DEBUG (testng-Test:[]) [TestSuiteProgress] Test configuration finished: org.infinispan.remoting.transport.InitialClusterSizeTest.testClassFinished
> 17:15:17,284 ERROR [TestSuiteProgress] Test failed: InitialClusterSizeTest.ThreadLeakChecker
> java.lang.RuntimeException: Leaked thread Controller-remote-thread-InitialClusterSizeTest-NodeB
> at jdk.internal.misc.Unsafe.park(Native Method) ~[?:?]
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) ~[?:?]
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:885) ~[?:?]
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1039) ~[?:?]
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1345) ~[?:?]
> at java.util.concurrent.Semaphore.acquire(Semaphore.java:318) ~[?:?]
> at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl$ControllerThread.run(BlockingTaskAwareExecutorServiceImpl.java:159) ~[classes/:?]
> {noformat}
> I believe it may be caused by {{doExecute()}} adding a task to the blocked tasks queue without calling {{checkForReadyTasks()}} (after the executor rejected the task). {{ControllerThread.run()}} needs a semaphore permit to start polling for tasks, so it needs a {{semaphore.release()}} after each {{blockedTasks.add().
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
[View Less]
5 years, 7 months