[JBoss JIRA] (DROOLS-964) Kie Drools WB - Startup error(org.eclipse.jgit.util.FS.readPipe)
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-964?page=com.atlassian.jira.plugin... ]
Michael Anstis commented on DROOLS-964:
---------------------------------------
Copied relevant forum discussion here:
The error seems to relate to this: https://www.eclipse.org/forums/index.php/t/1031740/
We're using 3.7.1.201504261725-r (and the fix appears to be in 4.1.0.201509280440-r)
> Kie Drools WB - Startup error(org.eclipse.jgit.util.FS.readPipe)
> ----------------------------------------------------------------
>
> Key: DROOLS-964
> URL: https://issues.jboss.org/browse/DROOLS-964
> Project: Drools
> Issue Type: Bug
> Components: tools
> Affects Versions: 6.3.0.Final
> Environment: Tomcat 7 / 8
> 6.3.0.Final
> Reporter: Jebuselwyn Martin
> Assignee: Michael Biarnes Kiefer
> Priority: Minor
>
> Issue in startup of DroolsWB + Drools Execution Server
> 23-Oct-2015 15:40:18.898 SEVERE [localhost-startStop-1] org.eclipse.jgit.util.FS.readPipe Caught exception in FS.readPipe()
> java.io.IOException: Cannot run program "bash" (in directory "C:\Users\selwyn.martin"): CreateProcess error=2, The system cannot find the file specified
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
> at java.lang.Runtime.exec(Runtime.java:620)
> at org.eclipse.jgit.util.FS.readPipe(FS.java:431)
> at org.eclipse.jgit.util.FS_Win32.discoverGitPrefix(FS_Win32.java:113)
> at org.eclipse.jgit.util.FS.gitPrefix(FS.java:517)
> at org.eclipse.jgit.util.SystemReader$Default.openSystemConfig(SystemReader.java:92)
> at org.eclipse.jgit.internal.storage.file.FileRepository.<init>(FileRepository.java:171)
> at org.eclipse.jgit.lib.BaseRepositoryBuilder.build(BaseRepositoryBuilder.java:577)
> at org.eclipse.jgit.api.InitCommand.call(InitCommand.java:113)
> at org.uberfire.java.nio.fs.jgit.util.JGitUtil.newRepository(JGitUtil.java:104)
> at org.uberfire.java.nio.fs.jgit.JGitFileSystemProvider.rescanForExistingRepositories(JGitFileSystemProvider.java:407)
> at org.uberfire.java.nio.fs.jgit.JGitFileSystemProvider.<init>(JGitFileSystemProvider.java:371)
> at org.uberfire.java.nio.fs.jgit.JGitFileSystemProvider.<init>(JGitFileSystemProvider.java:343)
> 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:422)
> at java.lang.Class.newInstance(Class.java:442)
> at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
> at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
> at org.uberfire.java.nio.file.api.FileSystemProviders.buildProviders(FileSystemProviders.java:65)
> at org.uberfire.java.nio.file.api.FileSystemProviders.setup(FileSystemProviders.java:48)
> at org.uberfire.java.nio.file.api.FileSystemProviders.resolveProvider(FileSystemProviders.java:104)
> at org.uberfire.java.nio.file.FileSystems.newFileSystem(FileSystems.java:117)
> at org.uberfire.java.nio.file.FileSystems.newFileSystem(FileSystems.java:83)
> at org.uberfire.io.impl.AbstractIOService.newFileSystem(AbstractIOService.java:241)
> at org.uberfire.backend.server.cdi.SystemConfigProducer$2.create(SystemConfigProducer.java:252)
> at org.uberfire.backend.server.cdi.SystemConfigProducer$2.create(SystemConfigProducer.java:187)
> at org.jboss.weld.context.AbstractContext.get(AbstractContext
> https://groups.google.com/forum/#!topic/drools-setup/qCMYwdOiBAI
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (DROOLS-964) Kie Drools WB - Startup error(org.eclipse.jgit.util.FS.readPipe)
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-964?page=com.atlassian.jira.plugin... ]
Michael Anstis commented on DROOLS-964:
---------------------------------------
[~mbiarnes] Hi Michael, is this something you could look into for us (possibly speak to [~porcelli] too)?
> Kie Drools WB - Startup error(org.eclipse.jgit.util.FS.readPipe)
> ----------------------------------------------------------------
>
> Key: DROOLS-964
> URL: https://issues.jboss.org/browse/DROOLS-964
> Project: Drools
> Issue Type: Bug
> Components: tools
> Affects Versions: 6.3.0.Final
> Environment: Tomcat 7 / 8
> 6.3.0.Final
> Reporter: Jebuselwyn Martin
> Assignee: Michael Biarnes Kiefer
> Priority: Minor
>
> Issue in startup of DroolsWB + Drools Execution Server
> 23-Oct-2015 15:40:18.898 SEVERE [localhost-startStop-1] org.eclipse.jgit.util.FS.readPipe Caught exception in FS.readPipe()
> java.io.IOException: Cannot run program "bash" (in directory "C:\Users\selwyn.martin"): CreateProcess error=2, The system cannot find the file specified
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
> at java.lang.Runtime.exec(Runtime.java:620)
> at org.eclipse.jgit.util.FS.readPipe(FS.java:431)
> at org.eclipse.jgit.util.FS_Win32.discoverGitPrefix(FS_Win32.java:113)
> at org.eclipse.jgit.util.FS.gitPrefix(FS.java:517)
> at org.eclipse.jgit.util.SystemReader$Default.openSystemConfig(SystemReader.java:92)
> at org.eclipse.jgit.internal.storage.file.FileRepository.<init>(FileRepository.java:171)
> at org.eclipse.jgit.lib.BaseRepositoryBuilder.build(BaseRepositoryBuilder.java:577)
> at org.eclipse.jgit.api.InitCommand.call(InitCommand.java:113)
> at org.uberfire.java.nio.fs.jgit.util.JGitUtil.newRepository(JGitUtil.java:104)
> at org.uberfire.java.nio.fs.jgit.JGitFileSystemProvider.rescanForExistingRepositories(JGitFileSystemProvider.java:407)
> at org.uberfire.java.nio.fs.jgit.JGitFileSystemProvider.<init>(JGitFileSystemProvider.java:371)
> at org.uberfire.java.nio.fs.jgit.JGitFileSystemProvider.<init>(JGitFileSystemProvider.java:343)
> 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:422)
> at java.lang.Class.newInstance(Class.java:442)
> at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
> at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
> at org.uberfire.java.nio.file.api.FileSystemProviders.buildProviders(FileSystemProviders.java:65)
> at org.uberfire.java.nio.file.api.FileSystemProviders.setup(FileSystemProviders.java:48)
> at org.uberfire.java.nio.file.api.FileSystemProviders.resolveProvider(FileSystemProviders.java:104)
> at org.uberfire.java.nio.file.FileSystems.newFileSystem(FileSystems.java:117)
> at org.uberfire.java.nio.file.FileSystems.newFileSystem(FileSystems.java:83)
> at org.uberfire.io.impl.AbstractIOService.newFileSystem(AbstractIOService.java:241)
> at org.uberfire.backend.server.cdi.SystemConfigProducer$2.create(SystemConfigProducer.java:252)
> at org.uberfire.backend.server.cdi.SystemConfigProducer$2.create(SystemConfigProducer.java:187)
> at org.jboss.weld.context.AbstractContext.get(AbstractContext
> https://groups.google.com/forum/#!topic/drools-setup/qCMYwdOiBAI
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (DROOLS-964) Kie Drools WB - Startup error(org.eclipse.jgit.util.FS.readPipe)
by Jebuselwyn Martin (JIRA)
Jebuselwyn Martin created DROOLS-964:
----------------------------------------
Summary: Kie Drools WB - Startup error(org.eclipse.jgit.util.FS.readPipe)
Key: DROOLS-964
URL: https://issues.jboss.org/browse/DROOLS-964
Project: Drools
Issue Type: Bug
Components: tools
Affects Versions: 6.3.0.Final
Environment: Tomcat 7 / 8
6.3.0.Final
Reporter: Jebuselwyn Martin
Assignee: Mario Fusco
Priority: Minor
Issue in startup of DroolsWB + Drools Execution Server
23-Oct-2015 15:40:18.898 SEVERE [localhost-startStop-1] org.eclipse.jgit.util.FS.readPipe Caught exception in FS.readPipe()
java.io.IOException: Cannot run program "bash" (in directory "C:\Users\selwyn.martin"): CreateProcess error=2, The system cannot find the file specified
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
at java.lang.Runtime.exec(Runtime.java:620)
at org.eclipse.jgit.util.FS.readPipe(FS.java:431)
at org.eclipse.jgit.util.FS_Win32.discoverGitPrefix(FS_Win32.java:113)
at org.eclipse.jgit.util.FS.gitPrefix(FS.java:517)
at org.eclipse.jgit.util.SystemReader$Default.openSystemConfig(SystemReader.java:92)
at org.eclipse.jgit.internal.storage.file.FileRepository.<init>(FileRepository.java:171)
at org.eclipse.jgit.lib.BaseRepositoryBuilder.build(BaseRepositoryBuilder.java:577)
at org.eclipse.jgit.api.InitCommand.call(InitCommand.java:113)
at org.uberfire.java.nio.fs.jgit.util.JGitUtil.newRepository(JGitUtil.java:104)
at org.uberfire.java.nio.fs.jgit.JGitFileSystemProvider.rescanForExistingRepositories(JGitFileSystemProvider.java:407)
at org.uberfire.java.nio.fs.jgit.JGitFileSystemProvider.<init>(JGitFileSystemProvider.java:371)
at org.uberfire.java.nio.fs.jgit.JGitFileSystemProvider.<init>(JGitFileSystemProvider.java:343)
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:422)
at java.lang.Class.newInstance(Class.java:442)
at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
at org.uberfire.java.nio.file.api.FileSystemProviders.buildProviders(FileSystemProviders.java:65)
at org.uberfire.java.nio.file.api.FileSystemProviders.setup(FileSystemProviders.java:48)
at org.uberfire.java.nio.file.api.FileSystemProviders.resolveProvider(FileSystemProviders.java:104)
at org.uberfire.java.nio.file.FileSystems.newFileSystem(FileSystems.java:117)
at org.uberfire.java.nio.file.FileSystems.newFileSystem(FileSystems.java:83)
at org.uberfire.io.impl.AbstractIOService.newFileSystem(AbstractIOService.java:241)
at org.uberfire.backend.server.cdi.SystemConfigProducer$2.create(SystemConfigProducer.java:252)
at org.uberfire.backend.server.cdi.SystemConfigProducer$2.create(SystemConfigProducer.java:187)
at org.jboss.weld.context.AbstractContext.get(AbstractContext
https://groups.google.com/forum/#!topic/drools-setup/qCMYwdOiBAI
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFLY-5569) Module dependencies don't work correctly when JAAS login is used in deployments
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/WFLY-5569?page=com.atlassian.jira.plugin.... ]
Josef Cacek updated WFLY-5569:
------------------------------
Description:
When user wants to use direct JAAS login call from a deployment (e.g. servlet), (s)he will experience problems when LoginModule is placed in custom AS module.
Login modules works correctly if they come from PicketBox, but new modules doesn't work.
This issue is based on [this StackOverflow question|http://stackoverflow.com/questions/33203277/wildfly-and-jaas-log...]
was:
When user wants to use direct JAAS login call from a deployment (e.g. servlet), (s)he will experience problems when LoginModule is placed in custom AS module.
Login modules works correctly if they come from PicketBox, but new modules doesn't work.
Steps to Reproduce:
Install custom AS module ({{login.mongodb}} in my case) which contains custom login module ({{org.jboss.test.MongoLoginModule}}).
Create new security domain, which uses the new login module:
{code:xml}
<security-domain name="web-tests" cache-type="default">
<authentication>
<login-module code="org.jboss.test.MongoLoginModule" flag="required" module="login.mongodb">
<module-option name="mongodb.uri" value="mongodb://localhost:21017/test?collection"/>
</login-module>
</authentication>
</security-domain>
{code}
Deploy application with servlet containing following code:
{code:java}
//...
LoginContext loginContext = new LoginContext("web-tests", new CallbackHandler() {
@Override
public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {
for (Callback c : callbacks) {
if (c instanceof PasswordCallback) {
((PasswordCallback) c).setPassword(req.getParameter("password").toCharArray());
} else if (c instanceof NameCallback) {
((NameCallback) c).setName(req.getParameter("user"));
}
}
}
});
loginContext.login();
Subject subject = loginContext.getSubject();
LOGGER.info("Login successful. Subject: " + subject);
//...
{code}
After making request to the servlet, user will see following exception:
{code}
javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.test.MongoLoginModule from [Module "deployment.secured-webapp.war:main" from Service Module Loader]
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:794)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
at org.jboss.test.JaasLoginServlet.doGet(JaasLoginServlet.java:61)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:198)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:784)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
If a login module from PicketBox (e.g. "UsersRoles") is used in the {{"web-tests"}} security domain, then everything works correctly and user is authenticated.
If security domain is referenced from the {{jboss-web.xml}} and {{HttpServletRequest.login(String,String)}} is used instead of direct JAAS, then it works also for login module in the custom AS module.
> Module dependencies don't work correctly when JAAS login is used in deployments
> -------------------------------------------------------------------------------
>
> Key: WFLY-5569
> URL: https://issues.jboss.org/browse/WFLY-5569
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading, Security
> Reporter: Josef Cacek
> Assignee: David Lloyd
>
> When user wants to use direct JAAS login call from a deployment (e.g. servlet), (s)he will experience problems when LoginModule is placed in custom AS module.
> Login modules works correctly if they come from PicketBox, but new modules doesn't work.
> This issue is based on [this StackOverflow question|http://stackoverflow.com/questions/33203277/wildfly-and-jaas-log...]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFLY-5569) Module dependencies don't work correctly when JAAS login is used in deployments
by Josef Cacek (JIRA)
Josef Cacek created WFLY-5569:
---------------------------------
Summary: Module dependencies don't work correctly when JAAS login is used in deployments
Key: WFLY-5569
URL: https://issues.jboss.org/browse/WFLY-5569
Project: WildFly
Issue Type: Bug
Components: Class Loading, Security
Reporter: Josef Cacek
Assignee: David Lloyd
When user wants to use direct JAAS login call from a deployment (e.g. servlet), (s)he will experience problems when LoginModule is placed in custom AS module.
Login modules works correctly if they come from PicketBox, but new modules doesn't work.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (DROOLS-963) Guava Version too old required by KIE-CI
by Mauricio Salatino (JIRA)
Mauricio Salatino created DROOLS-963:
----------------------------------------
Summary: Guava Version too old required by KIE-CI
Key: DROOLS-963
URL: https://issues.jboss.org/browse/DROOLS-963
Project: Drools
Issue Type: Enhancement
Reporter: Mauricio Salatino
Assignee: Mario Fusco
This might not be fixable, but testing drools (6.3.0.Final) with Arquillian and KIE-CI I found that KIE-CI is using a very very old version of Guava (version 10.x). In order to get it working with Arquillian and Weld I needed to go to middle ground between Weld requirement (version 18) and KIE-CI to get it working. I ended up adding Guava 14 as a direct dependency and that gets the project working.
I link the pom.xml file that I've used with all the versions: https://github.com/Salaboy/drools-workshop/blob/master/drools-kie-ci-exam...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (DROOLS-962) Kie-CI integration with Applications using Guava
by Jebuselwyn Martin (JIRA)
[ https://issues.jboss.org/browse/DROOLS-962?page=com.atlassian.jira.plugin... ]
Jebuselwyn Martin commented on DROOLS-962:
------------------------------------------
As a result of this issue, unable to use the dynamic-kie module / Drools WB integration features.
> Kie-CI integration with Applications using Guava
> ------------------------------------------------
>
> Key: DROOLS-962
> URL: https://issues.jboss.org/browse/DROOLS-962
> Project: Drools
> Issue Type: Bug
> Components: core engine, tools
> Affects Versions: 6.2.0.Final
> Environment: Drools WB - 6.2.0.Final
> Tomcat 7/8
> Reporter: Jebuselwyn Martin
> Assignee: Mario Fusco
> Fix For: 6.2.0.Final
>
>
> Unable to start application with the 'kie-ci' dependency due to the older version of Guava transitively pulled from maven libraries.
> Caused by: java.lang.IllegalAccessError: tried to access method com.google.common.collect.MapMaker.makeComputingMap(Lcom/google/common/base/Function;)Ljava/util/concurrent/ConcurrentMap; from class com.google.inject.internal.Annotations$AnnotationChecker
> at com.google.inject.internal.Annotations$AnnotationChecker.<init>(Annotations.java:104)
> at com.google.inject.internal.Annotations.<clinit>(Annotations.java:122)
> at com.google.inject.Key.ensureRetainedAtRuntime(Key.java:362)
> at com.google.inject.Key.strategyFor(Key.java:354)
> at com.google.inject.Key.get(Key.java:222)
> at org.eclipse.sisu.wire.ParameterKeys.<clinit>(ParameterKeys.java:28)
> at org.eclipse.sisu.wire.DependencyAnalyzer.<init>(DependencyAnalyzer.java:92)
> at org.eclipse.sisu.wire.ElementAnalyzer.<init>(ElementAnalyzer.java:87)
> at org.eclipse.sisu.wire.WireModule.configure(WireModule.java:74)
> at com.google.inject.spi.Elements$RecordingBinder.install(Elements.java:229)
> at com.google.inject.spi.Elements.getElements(Elements.java:103)
> at com.google.inject.internal.InjectorShell$Builder.build(InjectorShell.java:136)
> at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:104)
> at com.google.inject.Guice.createInjector(Guice.java:94)
> at com.google.inject.Guice.createInjector(Guice.java:71)
> at com.google.inject.Guice.createInjector(Guice.java:61)
> More details here:
> https://groups.google.com/forum/#!topic/drools-setup/Mq6dW_fhQ9I
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (JGRP-1971) Cycling a channel results in leftover timer threads
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1971?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1971.
----------------------------
Resolution: Done
> Cycling a channel results in leftover timer threads
> ---------------------------------------------------
>
> Key: JGRP-1971
> URL: https://issues.jboss.org/browse/JGRP-1971
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> When a channel is cycled a few times in the same process (creating a channel and calling {{destroy()}} on it, there are leftover timer thread.
> The reason is that the timer thread pool uses {{LazyThreadFactory}}, which keeps a list of threads to potentially rename them at runtime. The element are weak references to threads, but because we don't run out of memory, those refs are never garbage-collected.
> SOLUTION: add a method {{destroy()}} to {{ThreadFactory}}, and {{LazyThreadFactory}} would simply clear the list when called.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months