We are facing one funny and interesting issue with our JBoss app server.
The problem is we are running the JBoss in Linux server which is running in different time zone (say, America/Chicago).
Also with the same timezone we are starting the JBoss server by setting -Duser.timezone=xxx JVM parameter.
Although it's running fine as per the configuration for 5 or 6 days.
After that the JBoss app server's time zone is getting changed automatically to some other time zone say (Asia/Kolkata). For this we have analyzed lot but we are not able to figure it out and as of now restart of JBoss is required to get things normal.
So I wanted to know, is there any way to restrict this or to reset to old timezone without restarting JBoss?
Do you want to change the timezone of the server?
You can do it with tzselect command. I had a similar issue recently and I had documented it. You can refer if you want. its here
Related
We use Wildfly 10.1.0.Final here and over the last few days some curious behavior has manifested. First it was one user, but now over the course of the last few days, it's up to four users.
In house, we typically run Wildfly through standalone.bat on Windows (although I use mine as a service, and on Ubuntu).
The behavior is that after about an hour, a second instance of Wildfly attempts to start. These users do not have it installed as a service; it's run purely through the script. Sometimes it takes about two hours, but it's typically one. What we'll see in the log is that the Configured system properties: line prints in the log, followed by the usual startup information. There is no previous shutdown, no restart; the existing Java process controlling Wildfly is still running. A second whole Java process is being started. It gets about 1 second into the startup process, at which point Undertow sees the 8080 port is already in use, and then stops. What happens though, is that the two instances seem to start stepping all over each other and the end result is that both Java processes are still running, and our application is undeployed, with accompanying .undeployed file.
I have searched around but have turned up nothing. Are there any facilities in Wildfly to try and troubleshoot this? Is there a way to determine why Wildfly was started (to try and see why the second instance is popping up)? I think it's unlikely to be anything in our code that makes a whole new second Java process pop up, because we don't have any such thing coded in, but I'm open to possibilities.
EDIT: To add a detail, I just noticed that when this happens, while the original process was started by the logged in user (as shown in Windows Task Manager), the second process was started by the SYSTEM user. Keep in mind that Wildfly was not installed as a service (i.e. it's not erroneous service startup).
We have an (Eclipse RCP) application of 90MB with 139 self-signed jars which starts in 8s without Web Start and in 10s in an older version of Java 7. We configured Java to not use the browser proxy, i.e. deployment.proxy.type=0.
With each update of Oracle's Java startup performance drops. It takes more and more time to fully start up:
7u60/7u65/8u25: 13s (starts after 5s of web start processing)
7u75: 23s
8u31: 20s
8u40: 29s
8u51/8u60ea: 32s
What can I do to solve this issue?
From the trace/logs I can see that it is very probable that this slowdown is completely due to validating the cached jars taking much more time. Note that this question is similar but doesn't provide the following details:
Diagnosis:
When cached, the update check runs in only 0.5s (server returns "304 Not
Modified"), but even with a full download it takes only a few seconds on the gigabit network.
After the update check, for each jar XXX there is a log entry:
validating cached jar XXX.jar
When this is done, com.sun.javaws.Main is started after which the same validation seems to happen again and takes about the same amount of time, then the application starts.
The time spent in validating the cached jars seems to correspond to
the extra time required before the application starts.
The web start splash screen always shows for about 2 seconds corresponding to the update check and is then hidden. Then after almost 20 seconds the Java console finally appears and my application actually starts.
During the delay, jp2launcher.exe uses about 16% processor time on a quad core with hyperthreading (8 logical cores). So it looks like it is fully using one of the logical processors.
What I have already tried but did not make any difference:
clearing web start cache (countless times)
configure deployment.properties to disable certificate revocation check (as well as blacklist.check and validation.ocsp, validation.crl)
running offline
using the version download protocol
add to site exceptions list
check web server logs for problems. None found, update check runs in about 500ms for all 138 jars.
use another web server
checked certificate expiration date 17 feb 2016
validated my jnlp with JaNela and found no serious issues
create a deployment rule set to allow the application to run unsigned in order to speed up validation. This should be possible and looks like a promising way to solve this, but I could not get it working. See also my answer on this post.
configured Java to "do not start the console"
Detail: some weird behavior on 7u60
In 7u60 the application is started after about 5 seconds, after which the Java console APPEARS to be doing the jar validation in the background while the application is already started. HOWEVER the .log file reports that the application gets started AFTER all the validations are done. It reports this as 25 seconds and then shows the first System.out of my application which actually happened after only 5 seconds or so. It also shows the jar update check with the server taking 10 times as long as reported by the server. So I guess this is an issue with the logging framework lagging behind! Haven't seen this on 8u51.
Not an answer per se (yet), but I found that Java 8u25 when tracing is enabled, only generate a single trace file. 8u51 generates two files, one from the JVM used to update the application and other to run it. This is new (two JVM startups) and I think is related to the new setting for using native Windows sandbox capabilities. The problem is that it shouldn't have to validate the signatures again on the second JVM. The separation on two JVM instances always happen no matter if the setting for using native sandbox is disabled (the default).
I reported a regression bug, will edit the answer if I get an answer from Oracle.
Note: Java 8u31 still runs everything on one JVM but have the same doubled startup time the question stated.
I maintain a Java app that runs on Heroku and I need to reboot it every 24 hours at around midnight. I've been doing this off my laptop and need to switch to using the Heroku scheduler. How to do it? I asked Heroku support and got this answer:
What you probably want to do is setup a script that runs via the Heroku Scheduler. The script can use our Platform API to restart your dynos. You should be able to find a Java wrapper for the API if you do some searching (we don't provide an official Java wrapper client).
Note that the Heroku Scheduler doesn't guarantee execution (there are some conditions where one might get skipped due to backend maintenance or other issues), so you probably would want to design your script to track whether a restart happened in the last 24 hours and have it run more frequently than once per day so if it's missed once it'll happen on the next run.
This "best effort" is fine for my needs. My Java is rusty; how would I write this wrapper for the Heroku API and how would it be deployed?
Here are some related articles I found:
Restart my heroku application automatically
http://engineering.korrelate.com/2013/08/21/restart-heroku-dynos-on-your-terms/
https://devcenter.heroku.com/articles/scheduler
I've installed weblogic 10.3.3, configured simple domain with default configuration. And after starting weblogic I cannot use it via admin console because it is starting too slow (~10 mins). It seems that admin console application is being deployed incorrectly. Even when I enable 'staging' mode in AdminConsole deployment options, it does not help. Does anybody have a solution for this problem? It really bugs me out.
Configuration properties:
Server: Dell PowerEdge r410 server (Six-core Intel® Xeon® x64 CPU, 8GB RAM)
OS: Ubuntu Maverick 10.10 x86_64
Weblogic: 10.3.3 x64 (used wls1033_generic.jar file for installation)
Java: 1.6.0_17_i586 (tried with different jdk's including x64, but it does not work either)
Turns out weblogic uses random number generator during startup. Because of the bug in java it reads random bits from /dev/random. There are almost no problems with /dev/random except that it is extremely slow. It takes sometimes 10 minutes or more to generate one number. Simple solution exists – using /dev/urandom instead. It is not that good as /dev/random, but at least it is instant.
Java somehow maps /dev/urandom file to /dev/random. That’s why default settings in $JAVA_HOME/jre/lib/security/java.security are useless, they just do not make any sense.
Problem fix is very simple – adding string export JAVA_OPTIONS="-Djava.security.egd=file:/dev/./urandom" to the /etc/bash.bashrc file. Usage of /dev/./urandom instead of simple /dev/urandom is another hack. JVM does not understand the option value otherwise.
Be aware of this problem if you try to setup weblogic under UNIX-based OS.
Without looking at the startup logs we could only speculate. Weblogic typically is a beast. It typically takes anywhere fromo 6-8 minutes to start up for me on my development machines, but that seems like a nice server for it to take 10 minutes for you.
The Admin Console should not be this slow, nor should it take 6-8 minute to start a server or deploy the Admin Console. The deployment of the admin console on my machine takes less than 30 seconds, and startup is under 60 seconds. Startup time for WebLogic is a common complaint, but chances are that something is misconfigured if there is a very long startup or admin console deployment time.
I am starting an application with remote debug and suspend on start turned on.
When I connect remotely to the process, I getting stopped in an uncaught FileNotFoundException in ZoneInfo.getTimeZone()
It is cause by the line: new PatternLayout("[%d{HH:mm:ss}] %-5p: %m%n").
apparently java is not finding timezone for Israel in jre/lib/zi directory.
I appreciate if you know how to fix it.
Thanks.
Edit: It appears the problem is that time zone is defined as "Israel" and Java only have "Asia/Jerusalem" time zone.
How can It be changed on linux machine?
Israeli time zone should be Asia/Jerusalem. I see it under my jre/lib/zi.
I believe that there can be 2 reasons for failure of your program:
this file does not exist on your system.
something is wrong in definition of time zone on your computer.
So,
Check if the file Jerusalem is there
Check what is the default time zone returned by TimeZone.getDefault() and what is configured on control panel.
From what I found so far this is an inconsistency between suse 10 os and java. the os calls the time zone "(GMT+2:00) Israel" while java expects "(GMT+2:00) Jerusalem".
There is a workaround - starting java with the flag -Duser.timezone=Asia/Jerusalem or -Duser.timezone=GMT+2. the second option is not good for daylight savings. more details on this blog.