December 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1014) Drools OOM when loading session

by Artur Kronenberg (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1014?page=com.atlassian.jira.plugi... ] Artur Kronenberg commented on DROOLS-1014: ------------------------------------------ And more info: When taking the second rule and removing the entry-point from it, the problem disappears. It runs as quick as in standalone and seems perfectly happy. This should do as a workaround for now. But I have no idea why it behaves like that. So summing up: entry-points seem to have a weird behaviour when marshalling/unmarshalling that eats up heaps and heaps of memory. (Or my rules are just rubbish) > Drools OOM when loading session > ------------------------------- > > Key: DROOLS-1014 > URL: https://issues.jboss.org/browse/DROOLS-1014 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Environment: Mac OS 10.10.5, Eclipse Mars Release, Java 1.8, Drools 6.3.0.Final > Reporter: Artur Kronenberg > Assignee: Mario Fusco > Priority: Critical > > I ran into an issue loading the session from my JPA. > I am getting this stacktrace: > http://pastebin.com/PMKpdBWM > This is happening for this rule: > http://pastebin.com/HZmLmsEH > And this module: > http://pastebin.com/2Q6k73tC > What I am doing is: > 1. Create a new session > 2. Insert an ApplicationEvent > 3. fireAllRules > 4. Reload -> OOM > The ApplicationEvent has a list of 6345 facts in there. I load them from a CSV file, and use drools to insert them into my knowledge base as facts. > When I restart my server and have the session reloaded, it ooms when trying to deserialize the session. > I am still looking for a workaround. I am not sure what is happening and could not find any more info at this point. > I am using: > JPA + Hibernate 4.2.21.Final > org.codehaus.btm:btm:2.1.4 as a standalone JTA platform > Let me know if there's any other info needed. > Thanks, > Artur -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1249) Add "ShutdownInProgress" event to the ServiceContainer.TerminateListener

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1249?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1249: ------------------------------------------ [~rareddy] I believe WFCORE-1157 will be the solution for this use case. > Add "ShutdownInProgress" event to the ServiceContainer.TerminateListener > ------------------------------------------------------------------------ > > Key: WFCORE-1249 > URL: https://issues.jboss.org/browse/WFCORE-1249 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Reporter: Ramesh Reddy > Assignee: Jason Greene > > Currently the ServiceContainer.TerminateListener only notifies the listener after all the services are down notifying that Server is completely shutdown, However, it would be beneficial for services that are listening to event to get notified when the server is starting the shutdown cycle and after it completes. > usecase: in Teiid we differentiate between a undeploy event because of the undeploy, undeploy due to the shutdown to clean up cache entries, currently I see no way differentiate between two. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1249) Add "ShutdownInProgress" event to the ServiceContainer.TerminateListener

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1249?page=com.atlassian.jira.plugi... ] Brian Stansberry moved WFLY-1027 to WFCORE-1249: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-1249 (was: WFLY-1027) Component/s: Server (was: Server) > Add "ShutdownInProgress" event to the ServiceContainer.TerminateListener > ------------------------------------------------------------------------ > > Key: WFCORE-1249 > URL: https://issues.jboss.org/browse/WFCORE-1249 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Reporter: Ramesh Reddy > Assignee: Jason Greene > > Currently the ServiceContainer.TerminateListener only notifies the listener after all the services are down notifying that Server is completely shutdown, However, it would be beneficial for services that are listening to event to get notified when the server is starting the shutdown cycle and after it completes. > usecase: in Teiid we differentiate between a undeploy event because of the undeploy, undeploy due to the shutdown to clean up cache entries, currently I see no way differentiate between two. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-999) JBoss 7 hangs after "Started FileSystemDeploymentService for directory ..." message

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-999?page=com.atlassian.jira.plugin.s... ] Brian Stansberry resolved WFLY-999. ----------------------------------- Resolution: Out of Date > JBoss 7 hangs after "Started FileSystemDeploymentService for directory ..." message > ----------------------------------------------------------------------------------- > > Key: WFLY-999 > URL: https://issues.jboss.org/browse/WFLY-999 > Project: WildFly > Issue Type: Bug > Components: Server > Environment: Operating System z/OS > java version "1.7.0" > Java(TM) SE Runtime Environment (build pmz6470sr2-20120901_01(SR2)) > IBM J9 VM (build 2.6, JRE 1.7.0 z/OS s390x-64 20120809_118929 (JIT enabled, AOT enabled) > J9VM - R26_Java726_SR2_20120809_0948_B118929 > JIT - r11.b01_20120808_24925 > GC - R26_Java726_SR2_20120809_0948_B118929 > J9CL - 20120809_118929) > JCL - 20120831_02 based on Oracle 7u3-b05 > Reporter: gaurav singhal > Assignee: Jason Greene > Priority: Minor > Attachments: boot.log, javacore.20121017.204740.33554879.0002.txt, server.log > > > When we start jboss, it doesn't go past this log message: > 20:46:24,504 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-8) JBAS015012: Started FileSystemDeploymentService for directory /u/users/castoadm/chorus/jboss/standalone/deployments > and we never see the Brontes started message. server and boot log as well as the thread dump from when it stays hung at that message is attached. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1248) Make working directory for server processes configurable

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1248?page=com.atlassian.jira.plugi... ] Brian Stansberry moved WFLY-1052 to WFCORE-1248: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-1248 (was: WFLY-1052) Component/s: Domain Management (was: Server) > Make working directory for server processes configurable > -------------------------------------------------------- > > Key: WFCORE-1248 > URL: https://issues.jboss.org/browse/WFCORE-1248 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Environment: all > Reporter: Rico Neubauer > > Currently there is no configuration option to set the working directory of the server-process(es). > Host- and domain-controller both use system-property "user.dir", but for the server-process in org.jboss.as.host.controller.ManagedServer.ProcessAddTask#execute() the following is used to initiate the new process: > > processControllerClient.addProcess(serverProcessName, authKey, command.toArray(new String[command.size()]), environment.getHomeDir().getAbsolutePath(), env); > where environment.getHomeDir().getAbsolutePath() donates the working directory for the new process. > I tested JBoss with changed working directory and this seems not to introduce any issue, so I would request this becomming a configuration option. > A simple approach is to use system-property "user.dir" also for the server-processes. A more advanced soltion is to make this a configuration element/attribute beneath the server-configuration. > See the forum discussion for more references. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1247) There should be a unique OperationContext for each operation within composite operations

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1247?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-1247: ---------------------------------------- Assignee: (was: Jason Greene) > There should be a unique OperationContext for each operation within composite operations > ---------------------------------------------------------------------------------------- > > Key: WFCORE-1247 > URL: https://issues.jboss.org/browse/WFCORE-1247 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Chris Sams > Priority: Minor > > There is a concept of an attachment API that can be used to carry objects through the lifecycle of an "operation" when developing > JBoss DeploymentUnitProcessors. The DeploymentUnit object which can carry attachments is scoped to one concrete > deployment. If this is a composite deployment, the child deployments get their own DeploymentUnit that can carry their own attachments. A child DeploymentUnit > can access it's parent via API and thus also access attachments of the composite deployment. This is exactly what could be expected of the > OperationContext concept. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1247) There should be a unique OperationContext for each operation within composite operations

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1247?page=com.atlassian.jira.plugi... ] Brian Stansberry moved WFLY-1399 to WFCORE-1247: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-1247 (was: WFLY-1399) Component/s: Domain Management (was: Server) Affects Version/s: (was: 8.0.0.Final) > There should be a unique OperationContext for each operation within composite operations > ---------------------------------------------------------------------------------------- > > Key: WFCORE-1247 > URL: https://issues.jboss.org/browse/WFCORE-1247 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Chris Sams > Assignee: Jason Greene > Priority: Minor > > There is a concept of an attachment API that can be used to carry objects through the lifecycle of an "operation" when developing > JBoss DeploymentUnitProcessors. The DeploymentUnit object which can carry attachments is scoped to one concrete > deployment. If this is a composite deployment, the child deployments get their own DeploymentUnit that can carry their own attachments. A child DeploymentUnit > can access it's parent via API and thus also access attachments of the composite deployment. This is exactly what could be expected of the > OperationContext concept. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2816) Favour jboss-persistence.xml if present

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-2816?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-2816: ----------------------------------- Component/s: (was: Server) > Favour jboss-persistence.xml if present > --------------------------------------- > > Key: WFLY-2816 > URL: https://issues.jboss.org/browse/WFLY-2816 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Reporter: Christopher Klein > Assignee: Scott Marlow > Priority: Minor > > For developing for different target application servers (e.g. JBoss and WebSphere) it would be nice if WildFly favours a jboss-persistence.xml instead of the original persistence.xml. > The jboss-persistence.xml is specific for the deployment inside WildFly, the persistence.xml would be the fallback/default for other application servers. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3313) Websocket Auth - Container is not aware of the Principal

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3313?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-3313: ----------------------------------- Component/s: EJB Security Web (Undertow) > Websocket Auth - Container is not aware of the Principal > -------------------------------------------------------- > > Key: WFLY-3313 > URL: https://issues.jboss.org/browse/WFLY-3313 > Project: WildFly > Issue Type: Bug > Components: EJB, Security, Web (Undertow) > Affects Versions: 8.1.0.CR1 > Reporter: Markus D > Assignee: Jason Greene > > The Websocket is protected by the web.xml. The session object of the callback object correctly returns the principal. > When an EJB is called the callerPrincipal is always anonymous. > @Resource > private SessionContext ctx; > Principal callerPrincipal = ctx.getCallerPrincipal(); > Running thread here: > https://community.jboss.org/thread/240617 > Shouldn't the principal be propagated to the EJB container when a websocket callback method triggered? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4287) Typo on Wilfly.org - Sponsors box

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-4287?page=com.atlassian.jira.plugin.... ] Brian Stansberry resolved WFLY-4287. ------------------------------------ Fix Version/s: No Release Assignee: Tomaz Cerar Resolution: Done Thanks, [~esantana]! > Typo on Wilfly.org - Sponsors box > --------------------------------- > > Key: WFLY-4287 > URL: https://issues.jboss.org/browse/WFLY-4287 > Project: WildFly > Issue Type: Bug > Reporter: Ondrej Zizka > Assignee: Tomaz Cerar > Priority: Trivial > Fix For: No Release > > > "Red Hat employees the majority of contributors and provides all project infrastructure." > Should be "employs" (FWICT). > E.g. http://wildfly.org/downloads > If this belongs to WFLY jira, please move. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2015