Download Wildfly 24

[Carri Seargent]

Himy colleagues and I got a problem with wildfly 10. We developed several web-applications that run without any problems on wildfly 9. But since we patched our servers to version 10.1.0 (happens also with 10.0.0) firefox has problems with loading resources from wildfly. no problems in chrome or internet explorer. But this problem does only occur with wildfly 10. Not with tomcat, not with glassfish and not with wildfly 8 or 9.

In some cases the css-files won't be loaded and in other cases some image-files. And the problem does always occur with different files. it also occurs pretty randomly so you cannot predict when it happens. But up to now I never had to reload the page more than 6 times to run into the problem. This problem is more or less resolved if we disable the cache in firefox.

There is also a problem with loading pdf-files in firefox when it comes from wildfly 10. In some cases bold-text parts become blank in the pdf file. Does not occur in chrome and not with wildfly 9. So if I publish my application on wildfly 9 firefox has really no problems at all... we also tested different versions of firefox the current version I am using is 50.1.0 .

Looking at those images, it looks like your request URLs for those images are essentially a .xhtml. Is there any JSF/servlet involved on the server side for rendering these images? What does that code look like and are you sure you aren't setting any response headers (especially things like Content-Length) while serving these from your application?

yep, it is jsf with primefaces. But I am using the standard servlet configured with web.xml and I do not change any headers at all. And it is not just the images. In some cases even jsf itself does not get loaded. In these cases the whole site is a blank white sheet. And in other cases only my own css files will not be loaded and the components have no styling anymore. It is totally random. I just picked an example where the problem can obviously be observed with the missing images.

Looking at that attachments again - it looks to me that the server is responding back with 304 response code which essentially translates to "the content represented by this URL hasn't changed and me (as a server) will not send back any content and the client is responsible for rendering with whatever content it has for this resource". Can you add some details about what the request headers look like for some of these resources? Is this WildFly server fronted by some other server like Apache HTTPD? What does its configs look like?

I am also aware that this problem should normally be with firefox... but it is still odd that this problem happens only with wildfly 10. I have this error up to now at least after every 3rd reload of the page. And it never happens if I use wildfly 9 or 8.

Looking at that screenshot, I see that the request contains the (standard) "If-Modified-Since" header which tells the server to respond with a "not modified since" response so that the client can serve a cached content. The time being sent in this header value is what will be used by the server to decide how to respond. In this case, it's being sent as 9th Feb 2017, 07:48:29 GMT. What you have to verify is, whether the system time on the server side is correct and whether the client where this browser is running has the right system time. If both of this seems to be fine, then we need to see if there indeed is some bug in handling this header in Undertow.

Also, to me it's a bit odd that a request with URI *.xhtml path is being considered for caching in first place. I would have expected it to have a "no-cache" Cache-Control policy applied by the server when it first responded to that request path, assuming that xhtml path is mapped to a (server side) JSF servlet.

This error also happens if I start wildfly 10 on localhost. So unfortuantely it is not the system-time. Here is another example in which the modified-since header is still in 2013 and the server is not sending a response. (my system time is correct.) :-)

I read up on those request header semantics a bit more and apparently the "If-None-Match" header takes precedence over the "If-Modified-Since" header [1]. Looking at the Undertow code, it does indeed appear to be the case.

The "If-None-Match" header value sent in by your browser states that it has cached the content locally (identified by a resource tag) for that resource represented by that URL. The server then compares that tag value with the resource at the URL and since they match, it says, serve your local content (via the 304 header). Which is all expected and good.

The mysterious bit is - why has Firefox stored a 0 byte content against that specific resource URL (and some others)? So essentially we need to figure out why was 0 byte content delivered (as a 2xx response) the first time this resource URL was accessed. If you are able to somehow get hold of that details, then we will be closer to solving this.

I think there is still a little misunderstanding. What I think is that you think taht these files are always missing in the browser if it happens the first time. but this is not the case a simple reload-action "F5" is in most cases enough to get the resources into the browser again. But if I then press "F5" a few more times another resources are not getting displayed by firefox. E.g. the image in the upper most left. If I deploy the application and load the page the resource is correctly loaded in most cases. If I then click some links in the application at some point the image is gone as it is displayed in the screenshot of my last post.

disabling the cache is fixing the issue. But you surely agree that this is a bad fix :-) but seems that this problem should be on the firefox side, correct? But it is still odd that this problem does not occur with wildfly 9...

Very similar problem happening over here. Wildfly 10 running an application with JSF 2.1.29-01. Works fine on Chrome and keeps hanging on Firefox due to very similar reasons (broken responses regarding javascript and css files and sometimes even java.nio.channels.ClosedChannelException).

Probably, I will also follow what santos.zatarain.vera suggested on another related post (Re: Problem with java.nio.channels.ClosedChannelException, increase CPU usage and server goes down ) and upgrade the libraries regarding undertow in order to maintain a reasonable CPU activity. Thanks for that.

OK, I'll admit I'm fairly new to using this combination of tools and libraries, so I could be making a silly mistake, there could be an issue with any single component, or the combination may not work period.

BUT, I also have an slf4j log message in that method, and it doesn't send anything out to the log console. I've tried for a few hours this evening, to try and get this to work, but with no luck. Without (at this stage) getting into my posting lots of config files, etc, can anybody point me to an idiots guide that spells out how to get slf4j log messages out of my web app?

I tried adding slf4j to my pom file, included it as a manifest dependency in the war plugin, added jboss-deploymentment-structure files to META-INF (which doesn't feel correct) to exlude default logging modules, and set the 'add-logging-api-dependencies' to false in the wildfly cli gui. Nothing seems to show the faintest hope of working.

I have a project where some components use SLF4J and did not need jboss-deployment-structure.xml or a Manifest dependency. You should add the SLF4J API to your POM with provided scope, as Dirk noted, and also make sure that you do NOT have any implementations in your deployment. So no Logback, no redirect to Log4j, etc. WildFly will supply an implementation of SLF4J that bridges it into the JBoss Logging system. Finally, you might double check your logging configuration to make sure the log category and console handler have the right log levels set. With the default configuration, your log statement would have to be at INFO level or above.

What I hadn't stated originally was that my 'simple' project was copied from somewhere else. That project had a lot of dependencies (despite there not being much code in it), and buried away inside an 'uber' jar (created with the maven shade plugin - I told you a lot of this was new to me!) were the slf4j classes.

So what appears to have stopped slf4j working was the duplicate inclusion of slf4j libraries in my deployment. Minus that, just referencing the slf4j API in my POM would otherwise appear to be enough to get the logging 'working'.

I say 'appears', but I haven't yet tried this out on the original project. But I'm confident that you've helped me isolate the problem. I'll have to see if I can get slf4j excluded from that 'uber' jar, as I think I'm still going to need it for my 'real' app.

Glad to be of help. You should be able to use jboss-deployment-structure.xml to filter out those unwanted shaded classes, if all else fails. Check out the example deployment structure at Class Loading in WildFly - WildFly 8 - Project Documentation Editor. Part of the example filters out classes from a library included in the deployment.

I'm reading through that page now, and it look's like it could be a lot of trial-and-error pain coming my way, if I go down that route. But ... I guess it's probably the simplist (if I can get it to work) solution to my problem.

I'm guessing the resource-root is wrong. The warning says it's looking for jboss-forge-html5.war/shared-1.1-SNAPSHOT.jar, but if you include a library in Maven, it goes in the WAR's WEB-INF/lib. So you probably just need to change the resource-root path to "WEB-INF/lib/shared-1.1-SNAPSHOT.jar".

Yes, it looks like you are correct. Although I still had some WARN messages in my Wildfly log output that led me to belive that it wasn't working, I did end up seeing SLF4J log messages in my console output. So thanks again.

3a8082e126