Graceful shutdown
by Stuart Douglas
Hi all,
The first graceful shutdown code has now gone into Wildfly upstream, and
it should be possible to now start implementing this for all endpoints
(at the moment it is only implemented for Undertow and remote EJB).
Basically a server can be suspended by executing the :suspend operation
in the CLI, and resumed using the :resume operation (there are
corresponding options in domain mode as well that can be executed at
domain, server group and server level). Servers can also be suspended by
doing a graceful shutdown, which basically involves passing a timeout
parameter to the :shutdown command (so :shutdown(timeout=60) will
suspend the server, wait up to 60 seconds for all current requests to
finish, then shut down).
From a code point of view there are two main constructs,
org.jboss.as.server.suspend.SuspendController, which is notified of
suspend events, and
org.wildfly.extension.requestcontroller.RequestController, which deals
with the common case of tracking active requests (and also allows a
global request limit to be put in place as a form of overload protection).
Subsystems that wish to use the SuspendController directly do this by
registering ServerActivity callbacks, these callbacks notify the
subsystem when the server is being suspended and resumed, and allow the
subsystem to notify the server when the subsystem has suspended. This
happens in two stages:
- preSuspend() this is called first, and allows things like mod_cluster
to notify the load balancer that the server is being suspended. During
this phase the server processes requests normally.
- suspend() this is called once the preSuspend() phase has completed,
once suspend has started the subsystem should stop accepting requests,
and notify the server once it considers itself fully suspended.
Subsystems that wish to use RequestController do this by getting access
to a ControlPoint, which is identified by (top level) deployment name +
entry point name. When an external request starts the code calls
beginRequest() and checks the return value to see if the request is
allowed to proceed. If it is allowed then the code must call
requestComplete() when it is finished.
Note that this can only be used for external requests, or it can break
already running code (e.g. @PreDestroy calls that are running when the
server is suspended).
Because the request controller tracks the deployment and entry point we
may eventually use this information to also provide:
- deployment level suspend (so we can do 'graceful undeploy')
- entry point level suspend (e.g. suspend all web requests)
- statistics on active requests by deployment/entry point
Note that RequstController is a subsystem, and the request tracking does
add a small amount of overhead. If the subsystem is removed then this
overhead will disappear, however graceful shutdown will then not track
active requests.
All questions/comments are welcome, now that the core is in place I am
going to start creating JIRA's for all the subsystem level integration work.
Stuart
9 years, 8 months
Handling non-HTTP based request
by Andrei Tchijov
Hi,
Can some one advice on implementation of non HTTP based request handler inside wildfly? I am trying to avoid to deploy separate server to handle Flash Socket Policy File requests. Ideally, I would like to have some kind of "socket connection filter" - which will test if the request is for Socket Policy File and serve it. if request is NOT for the policy file, it would pass processing to "default" handler
Cheers,
Andrei Tchijov
9 years, 8 months
blocking JPA issue with resources getting de-listed from transaction too early on WildFly 8.x + master...
by Scott Marlow
To address a leak with some resource adapters, WildFly is de-listing
resources during the (IronJacamar) Synchronization.beforeCompletion
time, however this can happen before all of the persistence providers
have saved their changes to the database. This is likely to be the case
for applications that have more than one persistence unit used per
transaction. The impact is that only the first referenced persistence
provider, is part of the transaction. The other database changes will
run as local database changes. This was reported recently via [1] + [2]
+ [3]. Discussion about how to best address is ongoing (would be nice
to have both the resource leak fix and a way to run the IronJacamar
Synchronization.beforeCompletion last).
This is a blocking issue for any jiras that we create to handle this.
This problem is not in earlier application server versions (only in
WildFly 8.0 and higher).
Workaround:
Using a single persistence unit per transaction should workaround this
but a code fix will be better.
Scott
[1] WF user forum description of problem
https://community.jboss.org/message/901613
[2] Narayana dev mailing list post about sync ordering
https://community.jboss.org/message/901880
[3] original jira that reported this issue that I rejected
https://issues.jboss.org/browse/WFLY-3619
9 years, 8 months
Early Access build for JDK 9 b27 is available on java.net
by Rory O'Donnell Oracle, Dublin Ireland
Hi Guys,
Early Access build for JDK 9 b27 <https://jdk9.java.net/download/> is
available on java.net, summary of changes here
<http://www.java.net/download/jdk9/changes/jdk9-b27.html>
I'd also like to use this opportunity to point you to ongoing work in
OpenJDK on Project Jigsaw.
- JDK 9's source code is now modular:
http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-August/001220.html
- Mark Reinhold's post providing some context is available on his
blog: http://mreinhold.org/blog/jigsaw-phase-two
- The first two Project Jigsaw JEPs have been posted at
http://openjdk.java.net/jeps/200 & http://openjdk.java.net/jeps/201 .
You can also track the progress on the JEPs in the JDK Bug System now -
the corresponding JBS issue for JEP 201 is
https://bugs.openjdk.java.net/browse/JDK-8051619 , for example.
Comments, questions, and suggestions are welcome on the jigsaw-dev
mailing list. (If you haven’t already subscribed to that list then
please do so first, otherwise your message will be discarded as spam.)
Rgds,Rory
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
9 years, 8 months
Compilation error for wildfly-core 1.0.0.Alpha5
by Jürgen Zimmermann
>From https://github.com/wildfly/wildfly-core/tree/1.0.0.Alpha5 I cloned
wildfly-core and tried to compile, but failed (see below). On a windows 8.1
box with JDK 1.8.0_11 I used the command mvn clean install. I also tried
to add -Dskip-enforce. Any hint is appreciated.
The maven output:
[INFO] WildFly: Core Feature Pack ......................... SUCCESS [ 3.355
s]
[INFO] WildFly: Build Core ................................ FAILURE [ 2.109
s]
[INFO] WildFly Core: Distribution ......................... SKIPPED
[INFO] WildFly: Core Model Test Controller Optional ....... SKIPPED
[INFO] WildFly: Core Model Tests .......................... SKIPPED
[INFO] WildFly: IO Subsystem tests ........................ SKIPPED
[INFO] WildFly: Remoting Subsystem Test ................... SKIPPED
[INFO] WildFly: Subsystem Test Framework Tests ............ SKIPPED
[INFO] WildFly Core Test Suite: Shared .................... SKIPPED
[INFO] WildFly: Test Runner ............................... SKIPPED
[INFO] WildFly core Test Suite: Aggregator ................ SKIPPED
[INFO] WildFly Core Test Suite: Standalone Integration Tests SKIPPED
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 01:44 min
[INFO] Finished at: 2014-08-20T14:59:38+02:00
[INFO] Final Memory: 113M/752M
[INFO]
------------------------------------------------------------------------
[ERROR] Failed to execute goal
org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha1:buil
d (server-provisioning) on project wildfly-core-build: Execution
server-provisioning of goal
org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha1:buil
d failed: java.lang.RuntimeException: java.lang.IllegalStateException: Could
not resolve '[subsystem=logging.xml, supplement=null] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the
command
[ERROR] mvn <goals> -rf :wildfly-core-build
9 years, 8 months
Default boolean parameters to true
by Darran Lofthouse
Not talking about changing any other defaults but I have been thinking
would it make sense where boolean parameters are being passed in an
operation that we assume they are true if no value is specified.
As an example I regularly execute the following two commands: -
:read-resource(recursive=true)
:whoami(verbose=true)
In both cases the value feels redundant and it would be more natural to
just use: -
:read-resource(recursive)
:whoami(verbose)
Regards,
Darran Lofthouse.
9 years, 8 months
Component versions difference between Wildfly and Wildfly-Core
by Chao Wang
Hi, I noticed that component versions are sometimes different (newer or
older) between Wildfly and Wildfly-Core pom.xml, for instance,
version.org.apache.httpcomponents.httpclient is 4.2.6 in Wildfly and
4.2.1 in Wildfly-Core
/<
<version.org.apache.httpcomponents.httpclient>4.2.6</version.org.apache.httpcomponents.httpclient>//
//<
<version.org.apache.httpcomponents.httpcore>4.2.5</version.org.apache.httpcomponents.httpcore>//
//<
<version.org.apache.james.apache-mime4j>0.6</version.org.apache.james.apache-mime4j>//
//---//
//>
<version.org.apache.httpcomponents.httpclient>4.2.1</version.org.apache.httpcomponents.httpclient>//
//54,62d10/
version.org.jboss.modules.jboss-modules is 1.3.3.Final in Wildfly and
1.3.4.Final in Wildfly-Core:
/<
<version.org.jboss.modules.jboss-modules>1.3.3.Final</version.org.jboss.modules.jboss-modules>//
//---//
//>
<version.org.jboss.modules.jboss-modules>1.3.4.Final</version.org.jboss.modules.jboss-modules>//
//113,114d31/
As the core is split from previous whole Wildfly, in this case, do they
both need to be coherent in a shared component upgrade?
Chao
9 years, 8 months
arquillian config to test new server element (Question)
by Rebecca Searls
In Wfly 9 the JBossWS team has added a new server element in jboss-as-webservices_1_3.xsd
and added the corresponding code in wfly/webservices. I have added a corresponding
test in org.jboss.as.test.manualmode.ws.WSAttributesChangesTestCase.
Does arquillian need to be changed in some way to access this new feature?
My new code in WSAttributesChangesTestCase always fails because it can not find
the new server element. I've tried running the test as follows. Both fails the
same way.
integration-tests.sh install -Dtest=org/jboss/as/test/manualmode/ws/*TestCase* -Dts.manualmode -Dts.noSmoke
integration-tests.sh install -Dtest=org/jboss/as/test/manualmode/ws/*TestCase* -Dts.manualmode -Dts.noSmoke -Djboss.dist=$WILDFLY_HOME/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT
9 years, 8 months
