The Big Log ID Change: https://github.com/wildfly/wildfly/pull/5906
by David M. Lloyd
It's right there in the topic. James and I have carried out the change
discussed in [1] and elsewhere, and have split all the old "JBAS" codes
into specific "WFLYxxx" codes. The pull request is divided into one
commit per Maven module for easier review.
I request that every subsystem or component maintainer please review the
part of the commit that pertains to their piece, and please post
comments on the PR itself [2].
In addition, I want to discuss a few cases where modules are using
message bundles and loggers from neighboring modules. This is going to
become a problem when we do the distribution split-up.
Finally, one small matter I want to sort out is that we have several
modules which use a project-specific code for IllegalArugmentExceptions
that pertain specifically to null parameters, whereas some do not use a
code for this case and just throw the exception.
My feeling is we should either (a) don't use a code for this kind of
thing, or (b) come up with a "common" module or code space+project code
which every project can reuse, so we just have one code that universally
means "the parameter can't be null".
[1] http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000428.html
[2] https://github.com/wildfly/wildfly/pull/5906
--
- DML
10 years, 7 months
smaller footprints
by Bill Burke
On Resteasy list I have a few people "rolling their own app server"
using Netty, Weld, Resteasy and JPA. I asked one of them "I don't
understand why you are rolling your own app server" response:
"It's actually a lot more lightweight. The minimum I can run the
equivalent on AS7 on is ~ 180 mb in binaries, but throwing this
together is about 32 mb (and compresses further when its packaged).
I'm able to start the JVM on the bare minimum (~100mb on my linux VM)
but AS7 with all I need is about 756mb. When rolling out in the
cloud, where all of my REST APIs are stateless, running with this
configuration helps us get a lot more per node."
I'm not complaining :), just something to think about. It might be
really valuable to focus a bit in Wildfly 9 to make it easier to create
custom profiles or even different packaging options for the app server
instead of the exploded style we currently have.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 9 months
Gathering diagnostic data
by James Livingston
Hi,
I do support for JBoss at RH, especially lower level components like the
JVM and core server, and I've come to realise that we don't have
particularly good mechanisms for gathering diagnostic data. Obviously
there is logging, but for a number of problems it isn't enough. There is
also the JDR subsystem, but that has the serious limitation that the
server instance(s) have to be working correctly to use it.
One piece of data that I think can be useful for a common set of
problems are thread dumps. For standalone instances Oracle/OpenJDK's
'jstack' tool is useful, but for domain mode you need to manually go to
each machine and find the correct process ID to use it. Something that
could potentially be useful is to be able to tell Host Controllers to
take a thread dump from the servers it manages (or all of them), using
the same Attach/SA APIs as jstack.
A feature to allow HC-based extensions as mentioned in the thread about
the RHQ agent could be useful for implementing this too. Right now, I
believe it would need to be added to the HC code directly.
Is this something that might be possible or a good idea to do? I have
some ideas about other things that may be useful, like per-thread CPU
usage which RH support currently uses a pile of shell scripts for, but
starting with one thing may be simpler.
--
James "Doc" Livingston
JBoss Support Engineering Group
10 years, 9 months
Issue with HTTP upgrade for remote naming on OpenShit?
by Jeff Mesnil
Hi,
Now we have an OpenShift cartridge for WildFly 8.0.0.Final (hanks Farah!), I’m adding instructions to the JMS quickstarts to deploy them on OpenShift.
The helloworld-mdb is working fine but I have an issue with the helloworld-jms one[1].
In this quick start, the Java client makes a lookup to JNDI to retrieve the JMS resources.
The quickstart uses the “http-remoting://localhost:8080” as the JNDI provider URL for a local WildFly server.
When I host WildFly on OpenShift, that URL should translate to http-remoting://<app>-<namespace>.rhcloud.com:80 (in my case http-remoting://helloworldjms-jmesnil.rhcloud.com:80)
However this does not work:
$ mvn clean compile exec:java -Djava.naming.provider.url=http-remoting://helloworldjms-jmesnil.rhcloud.com:80
…
Feb 17, 2014 3:28:46 PM org.xnio.Xnio <clinit>
INFO: XNIO version 3.2.0.Final
Feb 17, 2014 3:28:46 PM org.xnio.nio.NioXnio <clinit>
INFO: XNIO NIO Implementation Version 3.2.0.Final
Feb 17, 2014 3:28:46 PM org.jboss.remoting3.EndpointImpl <clinit>
INFO: JBoss Remoting version 4.0.0.Final
Feb 17, 2014 3:28:46 PM org.jboss.as.quickstarts.jms.HelloWorldJMSClient main
INFO: Attempting to acquire connection factory "jms/RemoteConnectionFactory"
Feb 17, 2014 3:28:47 PM org.jboss.as.quickstarts.jms.HelloWorldJMSClient main
SEVERE: Failed to connect to any server. Servers tried: [http-remoting://helloworldjms-jmesnil.rhcloud.com:80 (java.io.IOException: Invalid response code 200)]
Remote naming is correctly complaining that the HTTP Upgrade handshake responded with a 200 OK instead of a 100 Continue.
Indeed, the deployed WildFly server does not upgrade my connection. You can check by hand using curl:
$ curl -v http://helloworldjms-jmesnil.rhcloud.com -H 'Connection:upgrade' -H 'Upgrade:jboss-remoting' -H 'Sec-JbossRemoting-Key: Xj8ZjttC3aixB1bAZ9w39A=='
...
* Connected to helloworldjms-jmesnil.rhcloud.com (50.17.25.239) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.30.0
> Host: helloworldjms-jmesnil.rhcloud.com
> Accept: */*
> Connection:upgrade
> Upgrade:jboss-remoting
> Sec-JbossRemoting-Key: Xj8ZjttC3aixB1bAZ9w39A==
>
< HTTP/1.1 200 OK
< Date: Mon, 17 Feb 2014 14:23:37 GMT
* Server Wildfly 8 is not blacklisted
< Server: Wildfly 8
< Last-Modified: Mon, 17 Feb 2014 14:20:22 GMT
< X-Powered-By: Undertow 1
< Content-Type: text/html
< Content-Length: 41708
< Vary: Accept-Encoding
…
[Home Page content follows]
The undertow’s http-listener is the default one;
<http-listener name="default" socket-binding="http" proxy-address-forwarding="true”/>
I tried removing the proxy-address-forwarding attribute but that did not change anything.
Has someone managed to use remote naming with WildFly on OpenShift?
Am I missing something obvious to make it run?
jeff
[1] https://github.com/jmesnil/quickstart/blob/helloworld-jms-openshift/hello...
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
10 years, 9 months
Undeployment printing null
by David Salter
Hi,
I'm looking at contributing a fix to WildFly.
I'm looking at bug WFLY-2205 that prints a deployment's name as null when it's deployed and undeployed.
For deploment:21:16:30,975 INFO [org.jboss.as.server.deployment] (MSC service thread 1-9) JBAS015876: Starting deployment of "EnterpriseApplication1.ear" (runtime-name: "EnterpriseApplication1.ear")21:16:31,041 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015876: Starting deployment of "null" (runtime-name: "EnterpriseApplication1-war.war")21:16:31,146 INFO [org.wildfly.extension.undertow] (MSC service thread 1-15) JBAS017534: Registered web context: /EnterpriseApplication1-war21:16:31,377 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "EnterpriseApplication1.ear" (runtime-name : "EnterpriseApplication1.ear")
For undeployment:21:16:00,660 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015877: Stopped deployment null (runtime-name: EnterpriseApplication1-war.war) in 58ms21:16:00,669 INFO [org.jboss.as.server.deployment] (MSC service thread 1-12) JBAS015877: Stopped deployment EnterpriseApplication1.ear (runtime-name: EnterpriseApplication1.ear) in 69ms21:16:00,886 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018558: Undeployed "EnterpriseApplication1.ear" (runtime-name: "EnterpriseApplication1.ear")
I've traced the bug to the SubDeploymentUnitService not having a MANAGEMENT_NAME like the RootDeploymentUnitService has (hence the correct message is displayed when deploying an .ear file, but not on it's enclosed .war file).
My question is what should be done to fix this? Should it log just the runtime name and if there is no management name log an empty string instead of null?
Thanks,
David.
10 years, 9 months
Need Your Help! (WF8 Post Release Work)
by Jason Greene
Hi Everyone,
Thanks again for all of your efforts on 8, the release appears to be well received. I know some of you are already looking at 9, but as I mentioned before the release, I’m hoping we can all focus on helping the community and fixing 8 issues.
Here is some things you can do to help WF8 be a success:
1. Help our users on the forums, and translate to JIRA as necessary - We have more activity now that more people are kicking the tires. Let’s keep them engaged and make sure they feel welcome!
2. Fix the popular bugs - It would be fantastic if we can clean up any discovered problems in a short time frame, by getting those fixes into 8.0.1.
3. Blog - Helping our new users get familiar with some of the new capabilities is a great way to build interest. If you like, we can also post your blog entry on WildFly.ORG. All it takes a PR, but if you need help get the content written and ping me.
4. Docs/Wikis - If everyone could double check our current docs in their area of expertise, and make sure they are helpful and up to date that would be awesome. If you see frequent common questions on the forums, creating an informative wiki would be a great aid
5. JUG talks - A number of you have already done this, but in case some of you aren’t aware, Arun is organizing WildFly overview talks with various JUGs that have expressed interest. There is a presentation ready to go (that you can customize), and its all virtual (over Google Hangout). Ping him if you are interested in this.
6. Encourage contributors - Sometimes our users are willing or interested in contributing, but don’t really know how to do it, or maybe just need to know their expertise is desired. If you see someone digging into things deeply, ask if they are interested in fixing it and offer to help them through the process.
Here are some major things that we noticed after 8 that need looking into:
1. Our default configuration has some less optimal values. This is mostly because we specify way too much up-front. One of our original yet not fully realized goals, is that any parameter which varied according to system capacity would have an auto-set intelligent default. Things like thread pool sizes should be a ratio of the number of available processors. Memory based limits should be calculated based on available max memory. Also we should avoid specifying things that we may later want to change. As an example we might set an explicit path in our config file, and there really is no reason why we want to do this other than to inform users the option exists. Ideally that should be a default, which can be changed after a patch, and any specified value would actually be the intention of the user.
2. Console needs slimming. The recent thread on that was a very useful discussion, and I think 8.0.1 is a great place to introduce the slimmed console.
3. OpenShift. We should double check there are no open shift issues we need to address before 8.0.1. There was a thread about JMS configuration issues, and I think we should revisit those.
If anyone has any other items to raise, now is the time.
Thanks!
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
10 years, 9 months
Trimming console size
by Tomaž Cerar
Hey guys,
I was just discussing with Harald could get distro size down by 25+MB if we
would trim our console a bit.
Currently we compile console with 40 permutations, six browsers
(ie6,ie8,ie9,gecko1_8,safari) and eight languages
(en,de,es,fr,pt_BR,zh_Hans,ja,ko).
I think we could drop support for ie6 and get rid of extra localization
with support only EN.
IE6 market share is so low this days that it really does not make sense to
support it in upstream anymore.
Also we don't ship localization of logging messages/exceptions in WildFy
anyway, so why have just one part localized.
This way we would get down to 4 permutations and our console distro would
be 6.8Mb instead of current 32,3Mb
Also if people want extra localization, they could always just download
full console release and replace that with jar we ship.
So what do you guys think?
--
tomaz
10 years, 9 months
Wildfly Quickstarts
by Eduardo Martins
I have been updating Wildfly Quickstarts, for now mostly reworking Maven POMs to use the updated dependencies, but it’s a long way to go, there are a lot of quickstarts, and no way all of these will be ready for primetime when WFLY 8 is out. So I was thinking in changing my strategy, and define a list with quickstarts of highest priority to be ready very soon.
The quickstarts list can be seen at http://www.jboss.org/jdf/quickstarts/get-started/
May a person related to each Java EE spec/technology go through that list and help my build the priority list? My guess is that first priority is to have the ones that show off Java EE and Wildfly 8 features only, leaving the ones that show integration with other JBoss projects for a second release, but still this will be a big list so I definitely need help.
Also, we will need new Batch quickstart(s).
Thanks in advance.
—E
10 years, 9 months
