[JBoss JIRA] (ELY-783) alias-filter from Elytron key-store does not work for non-lower-case alias with JKS
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/ELY-783?page=com.atlassian.jira.plugin.sy... ]
Ondrej Lukas updated ELY-783:
-----------------------------
Affects Version/s: 1.1.0.Beta13
> alias-filter from Elytron key-store does not work for non-lower-case alias with JKS
> -----------------------------------------------------------------------------------
>
> Key: ELY-783
> URL: https://issues.jboss.org/browse/ELY-783
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta13
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> In case when {{alias-filter}} attribute from Elytron {{key-store}} references non-lower-case alias (e.g. elytronAppServer) then SSL is not working. In case when this alias is set to lower-case in alias-filter (e.g. elytronappserver), then SSL works correctly.
> It seems JKS always transforms aliases to lower-case (even if they are created with some upper-case characters). However legacy security solution was able to use alias filter with non-lower-case characters to assign key from JKS keystore (probably through some internal {{.toLowerCase()}}).
> In case it is intended to do not use alias-filter with some upper-case for JKS then this issue can be changed to documentation issue. This is different behavior than was provided by legacy solution.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JBMETA-397) Typo in jboss-client_6_0.xsd - "applicetion"
by Martin Stefanko (JIRA)
Martin Stefanko created JBMETA-397:
--------------------------------------
Summary: Typo in jboss-client_6_0.xsd - "applicetion"
Key: JBMETA-397
URL: https://issues.jboss.org/browse/JBMETA-397
Project: JBoss Metadata
Issue Type: Bug
Reporter: Martin Stefanko
Assignee: Martin Stefanko
Priority: Trivial
Typo in jboss-client_6_0.xsd:
...All the applicetion client deployment descriptors must...
should be:
...All the application client deployment descriptors must...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (HIBERNATE-157) InvocationTargetException when opening hibernate structure
by Koen Aers (JIRA)
[ https://issues.jboss.org/browse/HIBERNATE-157?page=com.atlassian.jira.plu... ]
Koen Aers commented on HIBERNATE-157:
-------------------------------------
[~amenel] That would be great, thanks a lot.
> InvocationTargetException when opening hibernate structure
> ----------------------------------------------------------
>
> Key: HIBERNATE-157
> URL: https://issues.jboss.org/browse/HIBERNATE-157
> Project: Hibernate Integration
> Issue Type: Bug
> Environment: MacOS10.11.6(El Capitan), Eclipse4.6.0(Neon)
> Reporter: Yasuyuki Inoue
> Assignee: Koen Aers
>
> InvocationTargetException occured when opening existing Hibernate structure.
> !ENTRY org.hibernate.eclipse.console 4 2 2016-09-06 15:19:57.154
> !MESSAGE java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> !SUBENTRY 1 org.hibernate.eclipse.console 4 150 2016-09-06 15:19:57.154
> !MESSAGE java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> !STACK 0
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:78)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadata(MetadataHelper.java:16)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.getMetadata(ConfigurationFacadeImpl.java:167)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.buildMappings(ConfigurationFacadeImpl.java:105)
> at org.hibernate.console.ConsoleConfiguration$4.execute(ConsoleConfiguration.java:272)
> at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:63)
> at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:108)
> at org.hibernate.console.ConsoleConfiguration.buildMappings(ConsoleConfiguration.java:270)
> at org.hibernate.eclipse.console.workbench.ConsoleConfigurationWorkbenchAdapter.getChildren(ConsoleConfigurationWorkbenchAdapter.java:44)
> at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.getChildren(BasicWorkbenchAdapter.java:98)
> at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.fetchDeferredChildren(BasicWorkbenchAdapter.java:104)
> at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:231)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:72)
> ... 12 more
> Caused by: java.lang.NullPointerException
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.JPAConfiguration.getMetadata(JPAConfiguration.java:36)
> ... 17 more
> !SUBENTRY 2 org.hibernate.eclipse.console 4 150 2016-09-06 15:19:57.154
> !MESSAGE java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> !STACK 0
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:78)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadata(MetadataHelper.java:16)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.getMetadata(ConfigurationFacadeImpl.java:167)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.buildMappings(ConfigurationFacadeImpl.java:105)
> at org.hibernate.console.ConsoleConfiguration$4.execute(ConsoleConfiguration.java:272)
> at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:63)
> at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:108)
> at org.hibernate.console.ConsoleConfiguration.buildMappings(ConsoleConfiguration.java:270)
> at org.hibernate.eclipse.console.workbench.ConsoleConfigurationWorkbenchAdapter.getChildren(ConsoleConfigurationWorkbenchAdapter.java:44)
> at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.getChildren(BasicWorkbenchAdapter.java:98)
> at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.fetchDeferredChildren(BasicWorkbenchAdapter.java:104)
> at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:231)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:72)
> ... 12 more
> Caused by: java.lang.NullPointerException
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.JPAConfiguration.getMetadata(JPAConfiguration.java:36)
> ... 17 more
> !SUBENTRY 2 org.hibernate.eclipse.console 4 150 2016-09-06 15:19:57.154
> !MESSAGE java.lang.reflect.InvocationTargetException: <no message>
> !STACK 0
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:72)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadata(MetadataHelper.java:16)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.getMetadata(ConfigurationFacadeImpl.java:167)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.buildMappings(ConfigurationFacadeImpl.java:105)
> at org.hibernate.console.ConsoleConfiguration$4.execute(ConsoleConfiguration.java:272)
> at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:63)
> at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:108)
> at org.hibernate.console.ConsoleConfiguration.buildMappings(ConsoleConfiguration.java:270)
> at org.hibernate.eclipse.console.workbench.ConsoleConfigurationWorkbenchAdapter.getChildren(ConsoleConfigurationWorkbenchAdapter.java:44)
> at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.getChildren(BasicWorkbenchAdapter.java:98)
> at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.fetchDeferredChildren(BasicWorkbenchAdapter.java:104)
> at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:231)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: java.lang.NullPointerException
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.JPAConfiguration.getMetadata(JPAConfiguration.java:36)
> ... 17 more
> Root exception:
> java.lang.NullPointerException
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.JPAConfiguration.getMetadata(JPAConfiguration.java:36)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:72)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadata(MetadataHelper.java:16)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.getMetadata(ConfigurationFacadeImpl.java:167)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.buildMappings(ConfigurationFacadeImpl.java:105)
> at org.hibernate.console.ConsoleConfiguration$4.execute(ConsoleConfiguration.java:272)
> at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:63)
> at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:108)
> at org.hibernate.console.ConsoleConfiguration.buildMappings(ConsoleConfiguration.java:270)
> at org.hibernate.eclipse.console.workbench.ConsoleConfigurationWorkbenchAdapter.getChildren(ConsoleConfigurationWorkbenchAdapter.java:44)
> at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.getChildren(BasicWorkbenchAdapter.java:98)
> at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.fetchDeferredChildren(BasicWorkbenchAdapter.java:104)
> at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:231)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> !SUBENTRY 2 org.hibernate.eclipse.console 4 150 2016-09-06 15:19:57.154
> !MESSAGE java.lang.NullPointerException: <no message>
> !STACK 0
> java.lang.NullPointerException
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.JPAConfiguration.getMetadata(JPAConfiguration.java:36)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:72)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadata(MetadataHelper.java:16)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.getMetadata(ConfigurationFacadeImpl.java:167)
> at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.buildMappings(ConfigurationFacadeImpl.java:105)
> at org.hibernate.console.ConsoleConfiguration$4.execute(ConsoleConfiguration.java:272)
> at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:63)
> at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:108)
> at org.hibernate.console.ConsoleConfiguration.buildMappings(ConsoleConfiguration.java:270)
> at org.hibernate.eclipse.console.workbench.ConsoleConfigurationWorkbenchAdapter.getChildren(ConsoleConfigurationWorkbenchAdapter.java:44)
> at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.getChildren(BasicWorkbenchAdapter.java:98)
> at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.fetchDeferredChildren(BasicWorkbenchAdapter.java:104)
> at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:231)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-6744) Problem logout in cluster, not destroyed session (javax.faces.FacesException: UT000010: Session not found)
by Guillermo González de Agüero (JIRA)
[ https://issues.jboss.org/browse/WFLY-6744?page=com.atlassian.jira.plugin.... ]
Guillermo González de Agüero edited comment on WFLY-6744 at 11/23/16 6:18 AM:
------------------------------------------------------------------------------
I think this is caused by WFLY-7651.
Checking the stacktrace from the description, I think the offending line actually is this: https://github.com/javaserverfaces/mojarra/blob/MOJARRA_2_2X_ROLLING/jsf-...
That private method is called from requestDestroyed. As you can see, it checks for a valid session, but as WFLY-7651, the session is still returned when it was valid at the beginning of the request.
I think this one is for [~swd847].
was (Author: ggam):
I think this is caused by WFLY-7651.
Checking the stacktrace from the description, I think the offending line actually is this: https://github.com/javaserverfaces/mojarra/blob/MOJARRA_2_2X_ROLLING/jsf-...
That private method is called from requestDestroyed. As you can see, it checks for a valid session, but as WFLY-7651, the session is still returned.
I think this one is for [~swd847].
> Problem logout in cluster, not destroyed session (javax.faces.FacesException: UT000010: Session not found)
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6744
> URL: https://issues.jboss.org/browse/WFLY-6744
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.1.0.CR1
> Environment: Create a cluster with two nodes using standalone-ha.xml (default configuration), create an application with <distributable/> in the web.xml and it must have around 300 requests per seconds and I'm using SSO.
> Reporter: Bruno Silva
> Assignee: Paul Ferraro
>
> I reproduced the bug on Wildfly master (https://ci.jboss.org/hudson/job/WildFly-latest-master/lastBuild/artifact/...) . The problem is intermittent, sometimes it works but others not.
> {noformat}
> 2016-06-17 11:37:32,366 ERROR [io.undertow.servlet.request] (default task-3) UT015005: Error invoking method requestDestroyed on listener class com.sun.faces.config.ConfigureListener: javax.faces.FacesException: UT000010: Session not found 216sQVCJxKl2ALOykRmdC25xox30nESzAxB-znFS
> at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:136)
> at com.sun.faces.application.WebappLifecycleListener.requestDestroyed(WebappLifecycleListener.java:122)
> at com.sun.faces.config.ConfigureListener.requestDestroyed(ConfigureListener.java:346)
> at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:257)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:328)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)
> 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)
> Caused by: java.lang.IllegalStateException: UT000010: Session not found 216sQVCJxKl2ALOykRmdC25xox30nESzAxB-znFS
> at org.wildfly.clustering.web.undertow.session.DistributableSession.validate(DistributableSession.java:56)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.getAttributeNames(DistributableSession.java:134)
> at io.undertow.servlet.spec.HttpSessionImpl.getFilteredAttributeNames(HttpSessionImpl.java:140)
> at io.undertow.servlet.spec.HttpSessionImpl.getAttributeNames(HttpSessionImpl.java:135)
> at com.sun.faces.application.WebappLifecycleListener.syncSessionScopedBeans(WebappLifecycleListener.java:405)
> at com.sun.faces.application.WebappLifecycleListener.requestDestroyed(WebappLifecycleListener.java:116)
> ... 11 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-6744) Problem logout in cluster, not destroyed session (javax.faces.FacesException: UT000010: Session not found)
by Guillermo González de Agüero (JIRA)
[ https://issues.jboss.org/browse/WFLY-6744?page=com.atlassian.jira.plugin.... ]
Guillermo González de Agüero commented on WFLY-6744:
----------------------------------------------------
I think this is caused by WFLY-7651.
Checking the stacktrace from the description, I think the offending line actually is this: https://github.com/javaserverfaces/mojarra/blob/MOJARRA_2_2X_ROLLING/jsf-...
That private method is called from requestDestroyed. As you can see, it checks for a valid session, but as WFLY-7651, the session is still returned.
I think this one is for [~swd847].
> Problem logout in cluster, not destroyed session (javax.faces.FacesException: UT000010: Session not found)
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6744
> URL: https://issues.jboss.org/browse/WFLY-6744
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.1.0.CR1
> Environment: Create a cluster with two nodes using standalone-ha.xml (default configuration), create an application with <distributable/> in the web.xml and it must have around 300 requests per seconds and I'm using SSO.
> Reporter: Bruno Silva
> Assignee: Paul Ferraro
>
> I reproduced the bug on Wildfly master (https://ci.jboss.org/hudson/job/WildFly-latest-master/lastBuild/artifact/...) . The problem is intermittent, sometimes it works but others not.
> {noformat}
> 2016-06-17 11:37:32,366 ERROR [io.undertow.servlet.request] (default task-3) UT015005: Error invoking method requestDestroyed on listener class com.sun.faces.config.ConfigureListener: javax.faces.FacesException: UT000010: Session not found 216sQVCJxKl2ALOykRmdC25xox30nESzAxB-znFS
> at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:136)
> at com.sun.faces.application.WebappLifecycleListener.requestDestroyed(WebappLifecycleListener.java:122)
> at com.sun.faces.config.ConfigureListener.requestDestroyed(ConfigureListener.java:346)
> at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:257)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:328)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)
> 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)
> Caused by: java.lang.IllegalStateException: UT000010: Session not found 216sQVCJxKl2ALOykRmdC25xox30nESzAxB-znFS
> at org.wildfly.clustering.web.undertow.session.DistributableSession.validate(DistributableSession.java:56)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.getAttributeNames(DistributableSession.java:134)
> at io.undertow.servlet.spec.HttpSessionImpl.getFilteredAttributeNames(HttpSessionImpl.java:140)
> at io.undertow.servlet.spec.HttpSessionImpl.getAttributeNames(HttpSessionImpl.java:135)
> at com.sun.faces.application.WebappLifecycleListener.syncSessionScopedBeans(WebappLifecycleListener.java:405)
> at com.sun.faces.application.WebappLifecycleListener.requestDestroyed(WebappLifecycleListener.java:116)
> ... 11 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (DROOLS-1364) InMemorySessionFactory has apparent memory leak
by Maciej Swiderski (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1364?page=com.atlassian.jira.plugi... ]
Maciej Swiderski commented on DROOLS-1364:
------------------------------------------
Eli,
KieContainer and KieFileSystem can be accessed without runtime manager whatsoever. You should then use stateless sessions that are directly disposed by kie container.
> InMemorySessionFactory has apparent memory leak
> -----------------------------------------------
>
> Key: DROOLS-1364
> URL: https://issues.jboss.org/browse/DROOLS-1364
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.Final
> Reporter: Eli Israel
> Assignee: Maciej Swiderski
>
> I'm running drools with a runtime manager creating using PerRequest strategy and SessionCache turned on. (I process a LOT of requests but I want each one to be isolated)
> The SessionCache properly gets rid of sessions that have hung around too long, which is great.
> But the InMemorySessionFactory keeps a copy of every session it ever created, which -- it seems to me -- impedes garbage collection of unneeded, old sessions.
> It's possible I'm just reading this wrong, but examinations of running code using VisualVM show a LOT of RightTuple objects hanging around, attached to sessions and their GC root appears to be the InMemorySessionFactory.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (DROOLS-1326) Stateful working memory regression OCT-2016: nurserostering long_hint01.xml
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1326?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-1326:
----------------------------------------
Using this as a reference and passing test, for A/B testing comparison for the failing test synthetic above. (using the .equals() instead of == in the not node will cause to have the redblacktree working, instead of the hashtable as per the test above)
{code:java}
public class ReferenceTest {
@Test
public void test() {
String drl = "package "+this.getClass().getPackage().getName()+";\n" +
"import "+my.MyPojo.class.getCanonicalName()+"\n" +
"global java.util.Set controlSet;\n" +
"rule R1\n" +
"when\n" +
" $my: MyPojo(\n" +
" vBoolean == true,\n" +
" $s : vString, vString != null,\n" +
" $l : vLong\n" +
" )\n" +
" not MyPojo(\n" +
" vBoolean == true,\n" +
" vString.equals($s),\n" +
" vLong > $l\n" +
" )\n" +
"then\n" +
" System.out.println(\"->> firing with \"+ kcontext.getKieRuntime().getFactHandle($my) );\n" +
" System.out.println(\"->> firing with \"+$l);\n" +
" controlSet.add($l);\n" +
"end";
System.out.println(drl);
KieSession session = new KieHelper().addContent(drl, ResourceType.DRL).build().newKieSession();
Set<Long> check = new HashSet<Long>();
session.setGlobal("controlSet", check);
my.MyPojo a = new my.MyPojo(true, "x", 0, "a");
my.MyPojo b = new my.MyPojo(true, "x", 7, "b");
my.MyPojo c = new my.MyPojo(false, null, 7, "c");
FactHandle fh_a = session.insert(a);
FactHandle fh_b = session.insert(b);
FactHandle fh_c = session.insert(c);
System.out.println("a: "+fh_a);
System.out.println("b: "+fh_b);
System.out.println("c: "+fh_c);
System.out.println("1st fireAllRules");
session.fireAllRules();
assertFalse( check.contains(0) ); // A should be blocked by B.
c.setvBoolean(true); c.setvString("x");
session.update(fh_c, c);
b.setvBoolean(false); b.setvString(null);
session.update(fh_b, b);
System.out.println("2nd fireAllRules");
session.fireAllRules();
assertFalse( check.contains(0L) ); // A is no longer blocked by B, *however* it is now blocked by C !
}
}
{code}
> Stateful working memory regression OCT-2016: nurserostering long_hint01.xml
> ---------------------------------------------------------------------------
>
> Key: DROOLS-1326
> URL: https://issues.jboss.org/browse/DROOLS-1326
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.0.0.Beta2
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
> Priority: Blocker
> Attachments: screenshot-1.png
>
>
> Something regressed in Drools master between 27-SEP and 11-OCT.
> See:
> https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/optaplanner-turtl...
> I 'll ask [~jlocker] to isolate.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JGRP-2135) OOM with Jgroups 3.6.11.
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2135?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2135:
---------------------------
Fix Version/s: 3.6.12
4.0
This should not happen because some other process connects to the socket, as socket conn establishment exchanges a cookie first and closes the conn is the cookies don't match.
Note to self: run IspnPerfTest or UPerf with `-XX:OnOutOfMemoryError="kill -9 %p`.
> OOM with Jgroups 3.6.11.
> ------------------------
>
> Key: JGRP-2135
> URL: https://issues.jboss.org/browse/JGRP-2135
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.11
> Reporter: Zoltan Farkas
> Assignee: Bela Ban
> Fix For: 3.6.12, 4.0
>
>
> We are running our JVMs with : -XX:OnOutOfMemoryError="kill -9 %p"
> we have been experiencing OOMs fairly often, and the OOMs happen at:
> {code}
> Object / Stack Frame |Name | Shallow Heap | Retained Heap |Context Class Loader |Is Daemon
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> java.lang.Thread @ 0x81bdf838 |Connection.Receiver [144.77.77.53:50363 - 144.77.77.53:50363],sis-cluster.service,prodpmwsv5-6461| 120 | 456 |sun.misc.Launcher$AppClassLoader @ 0x800175a8|false
> |- at java.lang.OutOfMemoryError.<init>()V (OutOfMemoryError.java:48) | | | | |
> |- at org.jgroups.blocks.cs.TcpConnection$Receiver.run()V (TcpConnection.java:310)| | | | |
> |- at java.lang.Thread.run()V (Thread.java:745) | | | | |
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> {code}
> the Code where it happens is in TcpConnection.java:
> {code}
> while(canRun()) {
> try {
> int len=in.readInt();
> if(buffer == null || buffer.length < len)
> buffer=new byte[len];
> in.readFully(buffer, 0, len);
> updateLastAccessed();
> server.receive(peer_addr, buffer, 0, len);
> }
> catch(OutOfMemoryError mem_ex) {
> t=mem_ex;
> break; // continue;
> }
> catch(IOException io_ex) {
> t=io_ex;
> break;
> }
> catch(Throwable e) {
> }
> }
> {code}
> when allocating: buffer=new byte[len];
> it looks to me that some invalid large value is received and the process OOMs when allocating a huge byte array
> Running JVMs without kill on OOM would make this issue "dissapear" in the sense that it is swallowed by:
> {code}
> catch(OutOfMemoryError mem_ex) {
> t=mem_ex;
> break; // continue;
> }
> {code}
> Handling OutOfMemoryError is a strange implementation choice...
> instead a size limit should be employed to protect from receiving invalid sizes...
> My heap limit is 1GB and my heap dumps are 50Mb so the attempted allocation size is huge...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months