Re: [wildfly-dev] [infinispan-dev] WFLYTX0013 in the Infinispan Openshift Template
by Sebastian Laskawiec
Adding +WildFly Dev <wildfly-dev(a)lists.jboss.org> to the loop
Thanks for the explanation Rado.
TL;DR: A while ago Sanne pointed out that we do not set `node-identifier`
in transaction subsystem by default. The default value for the
`node-identifier` attribute it `1`. Not setting this attribute might cause
problems in transaction recovery. Perhaps we could follow Rado's idea and
set it to node name by default?
Some more comments inlined.
Thanks,
Sebastian
On Fri, Apr 13, 2018 at 7:07 PM Radoslav Husar <rhusar(a)redhat.com> wrote:
> Hi Sebastian,
>
> On Wed, Apr 11, 2018 at 2:31 PM, Sebastian Laskawiec
> <slaskawi(a)redhat.com> wrote:
> > Hey Rado, Paul,
> >
> > I started looking into this issue and it turned out that WF subsystem
> > template doesn't provide `node-identifier` attribute [1].
>
> I assume you mean that the default WildFly server profiles do not
> explicitly define the attribute. Right – thus the value defaults in
> the model to "1"
>
> https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java...
> which sole intention seems to be to log a warning on boot if the value
> is unchanged.
> Why they decided on a constant that will be inherently not unique as
> opposed to defaulting to the node name (which we already require to be
> unique) as clustering node name or undertow instance-id does, is
> unclear to me.
> Some context is on https://issues.jboss.org/browse/WFLY-1119.
>
In OpenShift environment we could set it to `hostname`. This is guaranteed
to be unique in whole OpenShift cluster.
>
> > I'm not sure if you guys are the right people to ask, but is it safe to
> > leave it set to default? Or shall I override our Infinispan templates and
> > add this parameter (as I mentioned before, in OpenShift this I wanted to
> set
> > it as Pod name trimmed to the last 23 chars since this is the limit).
>
> It is not safe to leave it set to "1" as that results in inconsistent
> processing of transaction recovery.
> IIUC we already set it to the node name for both EAP and JDG
>
> https://github.com/jboss-openshift/cct_module/blob/master/os-eap70-opensh...
>
> https://github.com/jboss-openshift/cct_module/blob/master/os-jdg7-conffil...
> which in turn defaults to the pod name – so which profiles are we
> talking about here?
>
Granted, we set it by default in CCT Modules. However in Infinispan we just
grab provided transaction subsystem when rendering full configuration from
featurepacks:
https://github.com/infinispan/infinispan/blob/master/server/integration/f...
The default configuration XML doesn't contain the `node-identifier`
attribute. I can add it manually in the cloud.xml but I believe the right
approach is to modify the transaction subsystem.
> Rado
>
> > Thanks,
> > Seb
> >
> > [1] usually set to node-identifier="${jboss.node.name}"
> >
> >
> > On Mon, Apr 9, 2018 at 10:39 AM Sanne Grinovero <sanne(a)infinispan.org>
> > wrote:
> >>
> >> On 9 April 2018 at 09:26, Sebastian Laskawiec <slaskawi(a)redhat.com>
> wrote:
> >> > Thanks for looking into it Sanne. Of course, we should add it (it can
> be
> >> > set
> >> > to the same name as hostname since those are unique in Kubernetes).
> >> >
> >> > Created https://issues.jboss.org/browse/ISPN-9051 for it.
> >> >
> >> > Thanks again!
> >> > Seb
> >>
> >> Thanks Sebastian!
> >>
> >> >
> >> > On Fri, Apr 6, 2018 at 8:53 PM Sanne Grinovero <sanne(a)infinispan.org>
> >> > wrote:
> >> >>
> >> >> Hi all,
> >> >>
> >> >> I've started to use the Infinispan Openshift Template and was
> browsing
> >> >> through the errors and warnings this produces.
> >> >>
> >> >> In particular I noticed "WFLYTX0013: Node identifier property is set
> >> >> to the default value. Please make sure it is unique." being produced
> >> >> by the transaction system.
> >> >>
> >> >> The node id is usually not needed for developer's convenience and
> >> >> assuming there's a single node in "dev mode", yet clearly the
> >> >> Infinispan template is meant to work with multiple nodes running so
> >> >> this warning seems concerning.
> >> >>
> >> >> I'm not sure what the impact is on the transaction manager so I asked
> >> >> on the Narayana forums; Tom pointed me to some thourough design
> >> >> documents and also suggested the EAP image does set the node
> >> >> identifier:
> >> >> - https://developer.jboss.org/message/981702#981702
> >> >>
> >> >> WDYT? we probably want the Infinispan template to set this as well,
> or
> >> >> silence the warning?
> >> >>
> >> >> Thanks,
> >> >> Sanne
> >> >> _______________________________________________
> >> >> infinispan-dev mailing list
> >> >> infinispan-dev(a)lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >> >
> >> >
> >> > _______________________________________________
> >> > infinispan-dev mailing list
> >> > infinispan-dev(a)lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
6 years, 5 months
Is there a single maven BOM artifact I can use to get/build the entire wildfly ee server?
by Eric B
I'm trying to debug some code, and I am often hitting classes in
Wildfly/Undertow/etc in my stack that I don't have the source code for.
I'd love to be able to add a dependency in my pom.xml so that Eclipse will
automatically d/l the sources from maven central for me and add them to my
debugger. I'm looking for an artifact that I'd be able to list something
like:
<dependency>
<artifactId>wildfly</artifactId>
<groupId>org.wildfly</groupId>
<version>10.1.0</version>
<scope>provided</scope>
<type>pom</type>
</dependency>
That would then download all the sources for me, and I'd be in business.
Is there something like this BOM available for wildfly?
Thanks,
Eric
6 years, 8 months
Apache CXF pretty logging
by Alexander Curvers
Hello peers,
what would be the easiest way to set the Apache CXF to pretty log the XML
in and outbound WS messages.
I enabled logging
<system-properties>
<property name="org.apache.cxf.logging.enabled" value="true"/>
</system-properties>
I know the default log handler of CXF can be set to pretty Log messages,
but how to set the option?
Thanks in advance.
Regards Alexander
6 years, 8 months
Rename of JIRA "Domain Management" component to "Management"
by Brian Stansberry
FYI, I've renamed the "Domain Management" component to simply "Management"
in the WFLY and WFCORE JIRA projects. The old name was misleading as it
implied the component is about domain mode, which has never been true.
Probably less than a quarter of work in the component over the years has
been about domain mode, and that percentage is decreasing as we focus more
on cloud use cases.
This has been on my todo list for years now and I'm cleaning off my desk a
bit. :)
In case it's helpful, here's what's covered by this component:
1) The functionality associated with all the WildFly 'kernel' management
resources, i.e. the many resources that are not part of an
extension/subsystem.
2) The Extension API that subsystem authors code against, including the
many helper/base classes they can use.
3) The server boot and shutdown logic. (This could be considered 'Server'
component but in practice it's easier to lump this in with Management.)
4) The basic management client API and the support code for JBoss
Remoting-based remote communication from a client.
5) Domain mode.
Management-related things that are not in this component but which should
be tracked via other component:
A) Client-side issues with the CLI: use the CLI component. (OTOH just
because you used the CLI to produce an issue on the server doesn't mean
it's a CLI issue.)
B) Client-side issues with the web console: use the Web Console component.
C) JMX issues: use the JMX component.
D) Management issues for a particular subsystem: use the subsystem's JIRA
component. If you think there may be a general issue, add Management as
well, but don't skip the subsystem's component.
Best regards,
Brian
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
6 years, 8 months
HAL.next / replace console in WildFly 13
by Harald Pehl
The development of HAL.next [1] has reached a point where we can replace the
existing console with HAL.next. We'd like to make this transition for
WildFly 13.
HAL.next ships with everything which is available in the current console.
In addition there are plenty new and enhanced features. I'm currently
preparing a website which will include basic user documentation and a list
of new and enhanced features.
Although we believe the new console is stable enough, we could add an
additional endpoint in WildFly 13 for the old console. This would enable
users to switch back and forth between the new and old console.
What do you think?
.: Harald
[1] https://github.com/hal/hal.next
6 years, 8 months
Tests for incomplete bugs
by Stuart Douglas
Hi Everyone,
Historically we have been ok with pull requests being submitted that add
tests for things that are not yet complete.
In practice this has been kinda problematic for reviewers, as these pull
requests can hang around for a long time, and this ends up wasting a lot of
reviewer time as we have to continually check the status of the PR. You
basically end up with multiple reviewers continually polling the issue to
check if it is ready, instead of a single person just submitting it when it
is complete.
I think that there is no real benefit to having the tests as a seperate PR
that gets opened before the fix. Instead I propose that tests that do not
pass yet are linked/co-ordinated under the relevant JIRA, and when the fix
is submitted the tests can be submitted as part of the same PR.
Does anyone have any objections to this?
Stuart
6 years, 8 months
What's new in JBoss Modules 1.8
by David Lloyd
JBoss Modules 1.8 is now part of WildFly Core, and it includes a few
major new features that you may want to be aware of:
• JDK module dependencies (MODULES-254, MODULES-314)
◦ This also works on Java 1.8, as initially discussed here:
http://lists.jboss.org/pipermail/wildfly-dev/2017-December/006180.html
◦ This also means that the following modules have been deprecated:
▪ "javax.api", in favor of various standard modules including
the now-implicit "java.base"
▪ "javax.xml.stream.api" and the JAXP portion of "javax.api"
in favor of "java.xml"
▪ "javax.sql.api" in favor of "java.sql"
▪ "sun.jdk" and "ibm.jdk" in favor of multiple standard modules
◦ For more information, see:
▪ https://github.com/wildfly/wildfly-proposals/pull/39
• Improved JAXP redirection strategy (MODULES-339)
◦ No longer uses system properties to establish the default implementation
◦ Implemented by way of adding additional services to the end of
each module's resource list
◦ This means the default implementation is local to the module
system class loaders and does not "leak out" to embedding environments
In addition, the following minor improvements are present:
• Automatic version detection (MODULES-343)
◦ If no version attribute is given in module.xml, the version is
detected via the JAR file manifest
◦ Versions are only advisory (for diagnostics) and do not play a
role in linkage or resolution
• Service declarations in module.xml (MODULES-349)
◦ Allows existing JARs to be supplemented with additional service
definitions
◦ Service definitions are treated as an additional (last) resource
root containing only service files
• Support for "data:" URLs (MODULES-340)
◦ See https://tools.ietf.org/html/rfc2397
◦ Can be returned by resource loaders for dynamic resource generation
• Functional class transformation API (MODULES-346)
◦ A new buffer-based functional interface is added and preferred
◦ Can be used to avoid a dependency on the "java.instrument"
module in the future
◦ A compatibility adapter class is also introduced
◦ APIs which accept the java.lang.instrument.ClassFileTransformer
interface are deprecated
• Ability to add security providers from the command line (MODULES-344)
◦ The "-add-provider" switch is introduced which accepts module or
module/class
• Add API to run any accessible "main" class within a module (MODULES-342)
The following deprecations were introduced:
• APIs which accept java.lang.instrument.ClassFileTransformer are
deprecated in favor of org.jboss.modules.ClassTransformer
(MODULES-346)
• Module index related command line switches and operations are
deprecated (MODULES-345)
• Resource root names are deprecated and are no longer used or
supported (though the APIs and XML attributes remain for
compatibility) (MODULES-352)
• "system" dependencies are deprecated (MODULES-254, MODULES-314)
--
- DML
6 years, 8 months
JDK 11 Early Access build 8 available
by Rory O'Donnell
Hi Jason/Tomaz,
**JDK 11 EA build 8, *****under both the GPL and Oracle EA licenses, is
now available at **http://jdk.java.net/11**. **
*
* Newly approved Schedule, status & features
o http://openjdk.java.net/projects/jdk/11/
* Release Notes:
o http://jdk.java.net/11/release-notes
* Summary of changes
o https://download.java.net/java/early_access/jdk11/8/jdk-11+8.html
*Notable changes in JDK 11 EA builds since last email:*
* Build 8:
o If you have a library that uses the Selector API heavily then
now would be a good time to test it out. [1]
* Build 7
o The VM option "-XX:+AggressiveOpts" is deprecated in JDK 11 and
will be removed in a future release.
* Build 6:
o JDK-8193033 : remove terminally deprecated
sun.misc.Unsafe.defineClass. Users should use the public
replacement `java.lang.invoke.MethodHandles.Lookup.defineClass`
which was added in Java SE 9. [2]
**
*SURVEY: The HotSpot Serviceability Agent (SA) *[3]
* If you have used, or have (support) processes that utilize the
Serviceability Agent or related APIs, then we would definitely
appreciate if you would complete this survey:
https://www.surveymonkey.com/r/CF3MYDL
Regards,
Rory
[1] http://mail.openjdk.java.net/pipermail/nio-dev/2018-April/004964.html
[2]
https://docs.oracle.com/javase/9/docs/api/java/lang/invoke/MethodHandles....
[3] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001052.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
6 years, 8 months
Detailed statistics
by Daniel Glöckner
Hi,
I was wondering about best practices for monitoring the inner parts of WildFly (thread pools, connection pools, queues, buffers…).
The more the merrier ;)
JMX would be the preferred option but I’m open for other suggestions. The idea is to poll at a regular interval and persist the statistics.
Kind regards,
Daniel
6 years, 8 months
JSF and JSP activation
by Stuart Douglas
Hi Everyone,
At the moment JSP and JSF are being activated for all web deployments,
which is relatively expensive as this involves quite a bit of class loading
and TLD parsing.
To give an idea about how much time this is actually taking I did a test
with a large number of small servlet only deployments both with and without
JSF, and JSF was accounting for 20% of total deployment time even though it
was not actually used by any of the deployments.
It also had a significant effect on memory usage, as the parsed TLD's are
retained, and are quite large.
The root of this issue is that the spec does not define clear activation
criteria for these technologies. I am proposing that we formalise some
activation criteria, so that we can avoid activating them if they are not
required.
JSP:
For JSP I think we can use the following criteria (if either one is
satisfied JSP is activated):
- The presence of a JSP file mapping in web.xml
- The presence of JSP files inside the deployment
- The presence of JSF
One thing that does concern me is that searching for JSP files in this way
may be expensive in large deployments with lots of web resources. An
alternate approach may be to try and make JSP lazy, so class loading and
TLD passing does not happen until a request for a JSP file arrives.
JSF:
This is much less clear. I think we can use the presence of one of the
following:
- faces-config.xml
- The faces servlet in web.xml
- Something else?
I am not really sure what effect this will have on backwards compatibility
though. If this is a compatibility problem we could add an attribute to the
JSF subsystem to restore the old mode.
Does this sound reasonable?
Stuart
6 years, 8 months
