Start Up Scripts
by James R. Perkins
While taking a look at a change to the start up scripts I'm reminded on
what a PITA it is to get consistent behavior across platforms. There are
4 scripts, not including daemon style scripts, to launch WildFly. In
addition to the 4 scripts there are 4 I guess extension scripts. Any
change needed is likely needed in 4 of the files.
I've created an API to launch WildFly [1]. I'm proposing we could use
the API to launch WildFly. We could nix the *.conf and *.conf.bat files
and go to two properties files; a standalone.properties and a
domain.properties. The normal start up scripts would remain, but be
reduced to only setup essential environment variables and invoke a main
class in the launcher API[2]. Note this is by no means complete, just an
example of how it could be done.
If has any opinions on this let me know. It would allow making changes a
lot easier.
[1]: https://github.com/wildfly/wildfly-core/pull/28
[2]: https://gist.github.com/jamezp/2033be603da4737ac571
--
James R. Perkins
JBoss by Red Hat
9 years, 9 months
WildFly Schedule & Goals Update
by Jason Greene
Hello Everyone,
I just wanted to relay some updated timeline and goals information:
- 8.2.0 is still waiting on an EE7 TCK update which includes CDI 1.2. Last we heard
we should be getting this in the summer, so expect it sometime in August.
- 9.0.0.Beta1 is slated for September 9, 2014
- 9.0.0.CR1 is slated for October 10, 2014
- 9.0.0.Final is slated for November 11, 2014
Note that WildFly Core is now versioned separately and is currently at 1.0.0.Alpha5. Once we are happy with the split it will be released Final. The core releases will move at a faster pace. More info on that to come.
WildFly 9 will focus on the following major features:
- Core/Servlet/Full Split
- Graceful shutdown
- Elytron (Security improvments)
- Switching to the JDK ORB from JacORB
- Undertow as a mod_cluster frontend
- Subsystem Capabilities and Requirements
- EAP 6.4 RFEs (TBA)
If you have any questions or concerns, let me know!
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
9 years, 9 months
Design Proposal: Server suspend/resume (AKA Graceful Shutdown)
by Stuart Douglas
Server suspend and resume is a feature that allows a running server to
gracefully finish of all running requests. The most common use case for
this is graceful shutdown, where you would like a server to complete all
running requests, reject any new ones, and then shut down, however there
are also plenty of other valid use cases (e.g. suspend the server,
modify a data source or some other config, then resume).
User View:
For the users point of view two new operations will be added to the server:
suspend(timeout)
resume()
A runtime only attribute suspend-state (is this a good name?) will also
be added, that can take one of three possible values, RUNNING,
SUSPENDING, SUSPENDED.
A timeout attribute will also be added to the shutdown operation. If
this is present then the server will first be suspended, and the server
will not shut down until either the suspend is successful or the timeout
occurs. If no timeout parameter is passed to the operation then a normal
non-graceful shutdown will take place.
In domain mode these operations will be added to both individual server
and a complete server group.
Implementation Details
Suspend/resume operates on entry points to the server. Any request that
is currently running must not be affected by the suspend state, however
any new request should be rejected. In general subsystems will track the
number of outstanding requests, and when this hits zero they are
considered suspended.
We will introduce the notion of a global SuspendController, that manages
the servers suspend state. All subsystems that wish to do a graceful
shutdown register callback handlers with this controller.
When the suspend() operation is invoked the controller will invoke all
these callbacks, letting the subsystem know that the server is suspend,
and providing the subsystem with a SuspendContext object that the
subsystem can then use to notify the controller that the suspend is
complete.
What the subsystem does when it receives a suspend command, and when it
considers itself suspended will vary, but in the common case it will
immediatly start rejecting external requests (e.g. Undertow will start
responding with a 503 to all new requests). The subsystem will also
track the number of outstanding requests, and when this hits zero then
the subsystem will notify the controller that is has successfully
suspended.
Some subsystems will obviously want to do other actions on suspend, e.g.
clustering will likely want to fail over, mod_cluster will notify the
load balancer that the node is no longer available etc. In some cases we
may want to make this configurable to an extent (e.g. Undertow could be
configured to allow requests with an existing session, and not consider
itself timed out until all sessions have either timed out or been
invalidated, although this will obviously take a while).
If anyone has any feedback let me know. In terms of implementation my
basic plan is to get the core functionality and the Undertow
implementation into Wildfly, and then work with subsystem authors to
implement subsystem specific functionality once the core is in place.
Stuart
The
A timeout attribute will also be added to the shutdown command,
9 years, 9 months
Proposal to read boot errors via WildFly Management APIs
by Emmanuel Hugonnet
# Ability to read boot errors via WildFly Management APIs
Tracked by https://issues.jboss.org/browse/WFLY-543
Use Cases
---------
If a server starts but reported errors during boot, there is no way to access the error data via the Management API and users are reduced to
searching the logs.
This information needs to be captured and stored for later reporting.
If some problem happens that gets logged at boot but somehow doesn't become visible to the management layer, that's out of scope. A problem
getting logged but not becoming visible would basically mean some runtime service logged an error but the error didn't prevent the start of
the service.
Implementation
--------------
Create a new sub resource of core-service=service-container because it has the ability to dump services, thus having all the services boot
errors and missing dependencies near seems like a good place.
thus we would have :
core-service => service-container {
boot-errors => {
failures => {
service-name => stackTrace;
....
}
missing-deps => {
... list of missing dependencies as String
}
}
}
This structure is based on the structure of the failure description returned during verification when starting a service.
All these informations should be collected in the ModelControllerImpl.
This resource would have restricted access of course.
What do you think?
Emmanuel
9 years, 9 months
Hibernate + Log4J2 Performance Problem
by Petar Tahchiev
Hi guys,
I'm reposting this from hibernate-dev following the advice I was given
there.
-----------------------------------------------------------------------------------------------------------
So here's my question. I'm reading this issue:
https://issues.jboss.org/browse/JBLOGGING-95
and I'm trying to make my hibernate use log4j2. So far I had
<dependency>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging-log4j</artifactId>
<version>${jboss.logging.version}</version>
</dependency>
and I have log4j -> log4j2 routed. Unfortunately now my hibernate creates a
log4j.log file and log4j prints the messages to the command line (still no
log4j2) :(
So I got rid of this dependency and I added the jboss-logging. So now
here's my set of jars:
hibernate-core
hibernate-entitymanager
hibernate-c3p0
hibernate-validator
log4j2
org.jboss.logging:jboss-logging:jar:3.2.0.Beta1
then I run my task and I get performance of:
[INFO]
------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 3:12.951s
[INFO] Finished at: Fri Jul 11 12:50:41 EEST 2014
[INFO] Final Memory: 128M/508M
[INFO]
------------------------------------------------------------------------
3 minutes and 12 seconds. Performance is quite good. However I use the
maven enforcer plugin and maven did warn me I have duplicate classes:
Duplicate classes found:
Found in:
org.jboss.logging:jboss-logging:jar:3.1.3.GA:compile
org.jboss.logging:jboss-logging:jar:3.2.0.Beta1:compile
Duplicate classes:
org/jboss/logging/Field.class
org/jboss/logging/LoggerProvider.class
org/jboss/logging/Log4jLoggerProvider.class
org/jboss/logging/NDC.class
org/jboss/logging/MessageBundle.class
org/jboss/logging/AbstractMdcLoggerProvider.class
org/jboss/logging/Log4jLogger$1.class
org/jboss/logging/Messages$1.class
org/jboss/logging/JDKLevel.class
org/jboss/logging/DelegatingBasicLogger.class
org/jboss/logging/JDKLoggerProvider.class
org/jboss/logging/Slf4jLoggerProvider.class
org/jboss/logging/LoggingClass.class
org/jboss/logging/Messages.class
org/jboss/logging/AbstractLoggerProvider.class
org/jboss/logging/Property.class
org/jboss/logging/JBossLogRecord.class
org/jboss/logging/SerializedLogger.class
org/jboss/logging/Message.class
org/jboss/logging/MDC.class
org/jboss/logging/Message$Format.class
org/jboss/logging/JBossLogManagerProvider$1.class
org/jboss/logging/Cause.class
org/jboss/logging/Param.class
org/jboss/logging/JDKLogger$1.class
org/jboss/logging/JBossLogManagerLogger.class
org/jboss/logging/Slf4jLogger.class
org/jboss/logging/JBossLogManagerProvider.class
org/jboss/logging/FormatWith.class
org/jboss/logging/Slf4jLocationAwareLogger$1.class
org/jboss/logging/Logger$Level.class
org/jboss/logging/BasicLogger.class
org/jboss/logging/Logger$1.class
org/jboss/logging/JDKLogger.class
org/jboss/logging/JBossLogManagerLogger$1.class
org/jboss/logging/MessageLogger.class
org/jboss/logging/ParameterConverter.class
org/jboss/logging/Logger.class
org/jboss/logging/Slf4jLocationAwareLogger.class
org/jboss/logging/Log4jLogger.class
org/jboss/logging/LoggerProviders$1.class
org/jboss/logging/Slf4jLogger$1.class
org/jboss/logging/AbstractLoggerProvider$Entry.class
org/jboss/logging/LogMessage.class
org/jboss/logging/LoggerProviders.class
I excluded the jboss-logging from all hibernate dependencies like this:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-validator</artifactId>
<version>${hibernate.validator.version}</version>
<exclusions>
<exclusion>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
No more duplicate classes :) . I run the same task again and here's the
performance:
[INFO]
------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 1:30:04.829s
[INFO] Finished at: Fri Jul 11 12:28:08 EEST 2014
[INFO] Final Memory: 118M/512M
[INFO]
------------------------------------------------------------------------
1 hour and 30 minutes and 4 seconds!!!!!! OMG :X How could this be??? And
on top of this no Log4j messages are coming through :(
This is probably a bug or I'm clearly missing how to setup Hibernate and
LOG4J2. Can you please help me, or at least point me to a forum or mailing
list where I can post this.
---------------------------------------------------------------------------------------------------------
--
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
9 years, 9 months
Legacy subsystem tests
by Kabir Khan
I’ve pulled out the legacy test controllers for subsystem-test and core-model-test to a separate repository at https://github.com/wildfly/wildfly-legacy-test.
Once https://github.com/wildfly/wildfly-core/pull/25 has been merged and released in the next wildfly-core release this means that you will be able to test your 7.1.x controllers again.
By default only 7.2.0 (EAP 6.1.x transformations get run). To run the 7.1.x tests you will need to pass in:
-Djboss.test.transformers.subsystem.old - for subsystem tests
-Djboss.test.transformers.core.old - for core model tests
-Djboss.test.transformers.eap - is used to enable EAP tests as before
The -Djboss.test.transformers.subsystem.old and -Djboss.test.transformers.core.old will presently also enable testing against WildFly 8, although there is no controller for that at present in https://github.com/wildfly/wildfly-legacy-test. We will look at adding that next week.
One thing which should make everybody’s lives a bit easier it that once this is merged there well no longer be old versions of wildfly-core classes on the classpath, so you will now only get one copy of e.g. ModelControllerImpl when searching in your IDE.
9 years, 9 months
Module references in wildfly9 (after build upstream)
by Wolf-Dieter Fink
Hi,
I noticed that the module.xml contains no jar file but a reference
<resources>
<artifact name="org.wildfly:wildfly-ejb3:9.0.0.Alpha1-SNAPSHOT"/>
I wonder how that works as after the build a copy of the target/wildfly
directory will use the update, but I don't see an updated jar in my
maven repo.
My question is how can I have a full snapshot with the full jars, i.e.
to compare with an older version?
And how does that work if we create a release ? Do the zip provide all
the jar files as before?
maybe a already documented issue, but I don't found any
- Wolf
9 years, 9 months
Core and subsystem capabilities and requirements
by Brian Stansberry
As we continue with our work splitting the WildFly code base into a core
repo and then separate repos related to sets of features that we need to
solidify the contracts between the various features and between features
and the core.
I've taken a crack at an initial design document on this: see [1]. We
also need to do the practical work of identifying the various
dependencies between our existing subsystems, see [2] for a start on that.
I'd love to get feedback on this thread regarding the proposed design,
as well as get direct edits on the [2] doc to flesh out the existing
relationships.
Short version:
A capability is a set of functionality that becomes available when a
user triggers it by including some configuration resource or attribute
in the management model.
We'll identify capabilities via two strings: the name of the providing
subsystem and then a capability name. A null subsystem name means a core
capability; a null capability name means the base capability of the
subsystem.
Capabilities will also declare the identifiers of any other capabilities
they require.
There are two use cases for this capability/requirement data:
provisioning (hopefully) and runtime.
Hopefully this information can be used by provisioning tooling when
building up a configuration document for the server/domain it is
provisioning. So instead of always including a stock configuration for a
subsystem, allow the user to tailor it a bit by declaring what
capabilities are required.
At runtime, when the configuration model is updated in such a way that a
capability is now required, the OSH that handles that update will
register the capability with the management layer in the MODEL stage. At
the end of the MODEL stage the management layer will resolve all
provided and required capabilities, failing the op if anything required
is unavailable.
Thereafter, in the RUNTIME stage an OSH that needs a capability from
another subsystem or the core can request an object implementing the API
for that capability from the OperationContext.
I've thought a lot more about the runtime use case than I have about the
provisioning use case.
[1] https://community.jboss.org/docs/DOC-52712
[2] https://community.jboss.org/docs/DOC-52700
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
9 years, 9 months
Elytron Subsystem
by Darran Lofthouse
For anyone looking for information on a complete subsystem for Elytron
we are not quite there yet, this e-mail is just to describe the location
of an empty subsystem.
I have just added the subsystem to it's own git repo here: -
https://github.com/wildfly-security/elytron-subsystem
If we need to track issues we can just use github for now.
Regarding names I have just literally made up the names as I went along,
any objects to names or the hierarchy ping me, send a pull request or
raise an issue in the project.
I have taken the decision to add support for creating a WildFly
distribution that includes the Elytron subsystem in it's own repo - the
distribution creation I expect only to be temporary until Elytron is
included by default whilst the subsystem could live on in it's own repo
long term. The repo that contains the build to assemble the
distribution is here: -
https://github.com/wildfly-security/elytron-distribution
Note: For the moment the module definitions live in the distribution
project and not the subsystem project, if in the future the build
plug-in supports pulling in module definitions hopefully we can move
them to the subsystem project.
As the work on the WildFly core split continues these projects will also
evolve further.
SNAPSHOT dependencies are in place between these two project and the
core wildfly-elytron project however I have deployed snapshots to nexus
for each of them and will keep nexus up to date as additional changes
are merged.
Regards,
Darran Lofthouse.
9 years, 9 months
