[JBoss JIRA] (WFCORE-3103) Embedded server doesn't close open file handles
by Jan Blizňák (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3103?page=com.atlassian.jira.plugi... ]
Jan Blizňák edited comment on WFCORE-3103 at 8/4/17 5:45 PM:
-------------------------------------------------------------
[~luck3y], the reproducer isn't trying to find open handles, it just tries to delete files, exactly as the manual steps say:
* start a CLI wrapper
* start embed-server from given server path
* stop embed-server
* terminate CLI wrapper
* try to delete given server path, ie. the files that were opened in order to start embed-server and that should no longer be opened after embed-server was stopped.
So test should pass when all these steps succeeded, ie. after this jira is fixed. But the last step currently fails everytime on all Win OSes I tried because there are open files from modules dir (I don't have Win 10, but I suppose Win Server 2016 is equivalent in this case). I was using EAP 7.1.0.ER3 and also today's Wildfly 11.0.0.Beta1 (wildfly-core 3.0.0.Beta30).
In case you want verbose output of the testcase, you need to download handle.exe tool from https://docs.microsoft.com/en-us/sysinternals/downloads/handle and execute the reproducer like this (the handle.exe serves only as additional info here to list locked files):
{{mvn clean test "-Dwildfly.home=C:\tmp\wildfly-11.0.0.Beta1" "-Dhandle.exe=C:\tmp\handle.exe" -Dtest=ModulesFileLockingTestCase -DtestLogToFile=false}}
was (Author: jbliznak):
[~luck3y], the reproducer isn't trying to find open handles, it just tries to delete files, exactly as the manual steps say:
* start a CLI wrapper
* start embed-server from given server path
* stop embed-server
* terminate CLI wrapper
* try to delete given server path, ie. the files that were opened in order to start embed-server and that should no longer be opened after embed-server was stopped.
So test should pass when all these steps succeeded, ie. after this jira is fixed. But the last step currently fails everytime on all Win OSes I tried because there are open files from modules dir (I don't have Win 10, but I suppose Win Server 2016 is equivalent in this case). I was using EAP 7.1.0.ER3 and also today's Wildfly 11.0.0.Beta1 (wildfly-core 3.0.0.Beta30).
In case you want verbose output of the testcase, you need to download handle.exe tool from https://docs.microsoft.com/en-us/sysinternals/downloads/handle and execute the reproducer like this (the handle.exe serves only as additional info here to list locked files):
{{mvn clean test "-Dwildfly.home=C:\tmp\wildfly-11.0.0.Beta1" "-Dhandle.exe=C:\tmp\handle.exe" -Dtest=ModulesFileLockingTestCase}}
> Embedded server doesn't close open file handles
> -----------------------------------------------
>
> Key: WFCORE-3103
> URL: https://issues.jboss.org/browse/WFCORE-3103
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Modules
> Reporter: Jan Blizňák
> Assignee: Ken Wills
>
> When embedded server is started programatically (eg. via CLI wrapper) with specified jboss home, JARs from that path are opened via classloader. But these open handles are never released even after embedded server is stopped.
> This causes problem in situation eg. when you want to delete that jboss home. This is exactly one of the scenarios used in EAP installer, you are not allowed to delete open files on Windows - see JBEAP-1404.
> I created a simple project that reproduce the issue with arbitrary EAP/WF distribution https://github.com/jbliznak/embedded-server-filelocking
> Run it with:
> mvn clean test "-Dwildfly.home=C:\dev\jboss-eap-7.1" "-Denforcer.skip" -Dtest=ModulesFileLockingTestCase
> Manual steps to reproduce in Java code:
> * start a CLI wrapper
> * start embed-server from given server path
> * stop embed-server
> * terminate CLI wrapper
> * try to delete given server path
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (LOGTOOL-129) Add a method to implementation classes that copies configures the stack trace elements
by James Perkins (JIRA)
James Perkins created LOGTOOL-129:
-------------------------------------
Summary: Add a method to implementation classes that copies configures the stack trace elements
Key: LOGTOOL-129
URL: https://issues.jboss.org/browse/LOGTOOL-129
Project: Log Tool
Issue Type: Enhancement
Reporter: James Perkins
Fix For: 2.1.0.Beta2
Currently each exception that gets created gets the current stack traces, removes the first element, then sets the stack trace on the resulting exception. A method should be added to the class that handle the copying. This helps reduces the metaspace size of the objects.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3150) Avoid multiple loading of ParallelBootOperationContext
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3150:
----------------------------------------
Summary: Avoid multiple loading of ParallelBootOperationContext
Key: WFCORE-3150
URL: https://issues.jboss.org/browse/WFCORE-3150
Project: WildFly Core
Issue Type: Task
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Analysis of the contents of metaspace shows that ParallellBootOperationContext and ParallellBootOperationContext$1 end up in memory multiple times. This indicates a problem with the classloader, for which I'll file a JBoss Modules bug, but a change in WildFly Core can work around the problem.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3149) Use "remote+http" as the default protocol for an Elytron remote outbound connection if no protocol is specified in the resolved AuthenticationConfiguration
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3149?page=com.atlassian.jira.plugi... ]
Farah Juma updated WFCORE-3149:
-------------------------------
Fix Version/s: 3.0.0.CR1
> Use "remote+http" as the default protocol for an Elytron remote outbound connection if no protocol is specified in the resolved AuthenticationConfiguration
> -----------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3149
> URL: https://issues.jboss.org/browse/WFCORE-3149
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Farah Juma
> Assignee: Farah Juma
> Priority: Blocker
> Fix For: 3.0.0.CR1
>
>
> Here's a description of the problem from [~sguilhen]:
> {quote}
> Farah Juma Not sure if this is relevant but do you remember a quick chat we had about a month ago when I was converting this QS and I was getting a $local identity when IntermediateEJB attempted to invoke the SecuredEJB? No matter what I did in terms of configuration I was getting $local even if I used a sasl-mech-selector that explicitly defined DIGEST-MD5 as the only mech.
> I found another sample app that was working correctly and the only difference was that the intermediate EJB was injecting the reference to the remote EJB instead of doing a lookup. So I've changed the QS to inject the reference to the SecuredEJB in the IntermediateEJB and it started working. I don't know if this has anything to do with the current issue but I was also getting the $local identity when running this QS.
> {quote}
> The problem occurs for EJB invocations from a remote server when doing a lookup using a PROVIDER_URL when no protocol is set on the {{AuthenticationConfiguration}} that should be used for the remote EJB invocation. In particular, in {{RemoteOutboundConnectionService#start}} when an {{AuthenticationContext}} is specified for a remote outbound connection and no protocol is set on the resolved {{AuthenticationConfiguration}}, we currently use "http-remoting" as the default protocol when constructing the destination URI. In {{EjbClientContextSetupProcessor.RegistrationService#transformOne}}, we create an {{AuthenticationContext}} with a rule that attempts to match on "http-remoting". However, because the {{InitialContext}} is created using "remote+http://localhost:8080" as the PROVIDER_URL, our rule doesn't match this PROVIDER_URL, so the desired {{AuthenticationConfiguration}} doesn't actually get used. We could update {{RemoteOutboundConnectionService#start}} so that "remote+http" is used as the default protocol instead of the "http-remoting" protocol when no protocol is set on {{AuthenticationConfiguration}} that is resolved for an Elytron remote outbound connection.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3149) Use "remote+http" as the default protocol for an Elytron remote outbound connection if no protocol is specified in the resolved AuthenticationConfiguration
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3149?page=com.atlassian.jira.plugi... ]
Farah Juma moved JBEAP-12562 to WFCORE-3149:
--------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-3149 (was: JBEAP-12562)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
> Use "remote+http" as the default protocol for an Elytron remote outbound connection if no protocol is specified in the resolved AuthenticationConfiguration
> -----------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3149
> URL: https://issues.jboss.org/browse/WFCORE-3149
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Farah Juma
> Assignee: Farah Juma
> Priority: Blocker
> Fix For: 3.0.0.CR1
>
>
> Here's a description of the problem from [~sguilhen]:
> {quote}
> Farah Juma Not sure if this is relevant but do you remember a quick chat we had about a month ago when I was converting this QS and I was getting a $local identity when IntermediateEJB attempted to invoke the SecuredEJB? No matter what I did in terms of configuration I was getting $local even if I used a sasl-mech-selector that explicitly defined DIGEST-MD5 as the only mech.
> I found another sample app that was working correctly and the only difference was that the intermediate EJB was injecting the reference to the remote EJB instead of doing a lookup. So I've changed the QS to inject the reference to the SecuredEJB in the IntermediateEJB and it started working. I don't know if this has anything to do with the current issue but I was also getting the $local identity when running this QS.
> {quote}
> The problem occurs for EJB invocations from a remote server when doing a lookup using a PROVIDER_URL when no protocol is set on the {{AuthenticationConfiguration}} that should be used for the remote EJB invocation. In particular, in {{RemoteOutboundConnectionService#start}} when an {{AuthenticationContext}} is specified for a remote outbound connection and no protocol is set on the resolved {{AuthenticationConfiguration}}, we currently use "http-remoting" as the default protocol when constructing the destination URI. In {{EjbClientContextSetupProcessor.RegistrationService#transformOne}}, we create an {{AuthenticationContext}} with a rule that attempts to match on "http-remoting". However, because the {{InitialContext}} is created using "remote+http://localhost:8080" as the PROVIDER_URL, our rule doesn't match this PROVIDER_URL, so the desired {{AuthenticationConfiguration}} doesn't actually get used. We could update {{RemoteOutboundConnectionService#start}} so that "remote+http" is used as the default protocol instead of the "http-remoting" protocol when no protocol is set on {{AuthenticationConfiguration}} that is resolved for an Elytron remote outbound connection.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3103) Embedded server doesn't close open file handles
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3103?page=com.atlassian.jira.plugi... ]
Ken Wills commented on WFCORE-3103:
-----------------------------------
[~jbliznak] I've been looking at this on Windows 10. It appears that the reproducer doesn't find any handles from just running with wildfly-core (master). Am I misunderstanding the reproducer, that it should have test failures, or should they all pass?
> Embedded server doesn't close open file handles
> -----------------------------------------------
>
> Key: WFCORE-3103
> URL: https://issues.jboss.org/browse/WFCORE-3103
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Modules
> Reporter: Jan Blizňák
> Assignee: Ken Wills
>
> When embedded server is started programatically (eg. via CLI wrapper) with specified jboss home, JARs from that path are opened via classloader. But these open handles are never released even after embedded server is stopped.
> This causes problem in situation eg. when you want to delete that jboss home. This is exactly one of the scenarios used in EAP installer, you are not allowed to delete open files on Windows - see JBEAP-1404.
> I created a simple project that reproduce the issue with arbitrary EAP/WF distribution https://github.com/jbliznak/embedded-server-filelocking
> Run it with:
> mvn clean test "-Dwildfly.home=C:\dev\jboss-eap-7.1" "-Denforcer.skip" -Dtest=ModulesFileLockingTestCase
> Manual steps to reproduce in Java code:
> * start a CLI wrapper
> * start embed-server from given server path
> * stop embed-server
> * terminate CLI wrapper
> * try to delete given server path
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-3801) Wrong Transaction behaviour for EJBs if JTS is enabled
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3801?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3801:
-----------------------------------------------
Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1136054|https://bugzilla.redhat.com/show_bug.cgi?id=1136054] from ON_QA to VERIFIED
> Wrong Transaction behaviour for EJBs if JTS is enabled
> ------------------------------------------------------
>
> Key: WFLY-3801
> URL: https://issues.jboss.org/browse/WFLY-3801
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.1.0.Final
> Environment: standalone-full profile with JTS enabled
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
> Attachments: 456a624-withDestroy.log, 8d49872-error.log, enableJTS.cli, reproducer.zip, server.log
>
>
> If JTS is enabled the invocation of EJB's might show a arjuna warning for each method invocation:
> WARN [com.arjuna.ats.jts] (RequestProcessor-5) ARJUNA022261: ServerTopLevelAction detected that the transaction was inactive
> This is only the case if other resources are involved, i.e. a DB via JPA.
> If a simple bean is used (like ejb-remote quickstart) this warning is not shown.
> It looks like the transaction is local commited but in case of a SFSB @Remove method the result is a " WFLYEE0006: Failed to destroy component instance Instance of SFTestBean" and the lifecycle method @PreDestroy is not invoked.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9188) A StackOverflowError occurs when the server executes the "XA END" statement and the Oracle server exits abruptly
by Jarek Przygódzki (JIRA)
[ https://issues.jboss.org/browse/WFLY-9188?page=com.atlassian.jira.plugin.... ]
Jarek Przygódzki updated WFLY-9188:
-----------------------------------
Description:
A StackOverflowError occurs in the WildFly application server when the server executes the "XA END" statement and the Oracle server exits abruptly
JVM: OpenJDK Runtime Environment (build 1.8.0_121-b13)
OS: Red Hat Enterprise Linux Server release 7.3 (Maipo)
JDBC Driver version: 11.2.0.4
was:
A StackOverflowError occurs in the WildFly application server when the server executes the "XA END" statement and the Oracle server exits abruptly
JVM
OpenJDK Runtime Environment (build 1.8.0_121-b13)
OS
Red Hat Enterprise Linux Server release 7.3 (Maipo)
> A StackOverflowError occurs when the server executes the "XA END" statement and the Oracle server exits abruptly
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9188
> URL: https://issues.jboss.org/browse/WFLY-9188
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 10.1.0.Final
> Reporter: Jarek Przygódzki
> Assignee: Amos Feng
> Attachments: stacktrace.txt
>
>
> A StackOverflowError occurs in the WildFly application server when the server executes the "XA END" statement and the Oracle server exits abruptly
> JVM: OpenJDK Runtime Environment (build 1.8.0_121-b13)
> OS: Red Hat Enterprise Linux Server release 7.3 (Maipo)
> JDBC Driver version: 11.2.0.4
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9188) A StackOverflowError occurs when the server executes the "XA END" statement and the Oracle server exits abruptly
by Jarek Przygódzki (JIRA)
[ https://issues.jboss.org/browse/WFLY-9188?page=com.atlassian.jira.plugin.... ]
Jarek Przygódzki updated WFLY-9188:
-----------------------------------
Description:
A StackOverflowError occurs in the WildFly application server when the server executes the "XA END" statement and the Oracle server exits abruptly
JVM
OpenJDK Runtime Environment (build 1.8.0_121-b13)
OS
Red Hat Enterprise Linux Server release 7.3 (Maipo)
was:A StackOverflowError occurs in the WildFly application server when the server executes the "XA END" statement and the Oracle server exits abruptly
> A StackOverflowError occurs when the server executes the "XA END" statement and the Oracle server exits abruptly
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9188
> URL: https://issues.jboss.org/browse/WFLY-9188
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 10.1.0.Final
> Reporter: Jarek Przygódzki
> Assignee: Amos Feng
> Attachments: stacktrace.txt
>
>
> A StackOverflowError occurs in the WildFly application server when the server executes the "XA END" statement and the Oracle server exits abruptly
> JVM
> OpenJDK Runtime Environment (build 1.8.0_121-b13)
> OS
> Red Hat Enterprise Linux Server release 7.3 (Maipo)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months