I am new to this project and still figuring many things out. Been an experienced web developer for many years now.
My QA people came to me and said, "We're having an issue. We used to be able to turn off hibernate caching on our QA boxes to run queries outside of the app and then see the results in the app, but it's not working any more."
So I look into the problem and they we adding the following line to setenv.bat (Tomcat 7 running on Windows Server 2012 R2 Standard),
set JAVA_OPTS=%JAVA_OPTS% -Dnet.sf.ehcache.disabled=true
and this, according to them used to work, but now it doesn't.
So, problem one, is that we don't run the app in the same way on our dev boxes than on QA and in production. (I know, I know.) We run maven scripts to start everything and I can get the java opts thing to work just fine.
Funnily, I've been doing this for years and I didn't know anything about setenv.bat. I did some reading here: https://tomcat.apache.org/tomcat-7.0-doc/RUNNING.txt and it says that setenv.bat doesn't work when running tomcat as a service.
So, I log onto the QA box and dig and find out, sure enough, tomcat is running as a service. The service starts tomcat7.exe //RS//Tomcat7. (Not sure what the tomcat7.exe is.)
So according to the above doc, I set CATALINA_OPTS=-Dnet.sf.ehcache.disabled=true and restart the server.
In the meantime, I've written a handy little servlet that dumps all of the system properties, so I can know immediately what effect my changes have. I run it and it says net.sf.ehcache.disabled=false. Clearly, something is overriding my change.
So I do some reading here: https://tomcat.apache.org/tomcat-7.0-doc/windows-service-howto.html and set an environment variable to be PR_JvmOptions=-Dnet.sf.ehcache.disabled=true and restart the server. Run my little servlet and:
net.sf.ehcache.disabled=false
So, clearly, something is overriding my settings no matter what I do. The docs say it is ignoring setenv.bat and I don't know where else to look to find this override.
Related
i have noticed that signed applets are loaded much slower with the latest plugin (included in java 8u31 and 7u75). I have debugged the situation quite a lot and i found out that the problem is directly related to the size of the jar files that are referenced in the jnlp file. The problem is that each time the applet starts, there is some 're-indexing' of the cached jar files that takes time.
To reproduce the issue i did this:
I created a minimal applet and in the jnlp file i used to deploy it, I added several irrelevant .jar files (that are not even referenced, so the classloader does not load them) of considerable size (e.g. 30MB). Of course i am using versioning in the jnlp and capture all http traffic to make sure that the delays are not because of traffic (either re-downloading or certificate revocation checks, etc). I run the applet with the trace enabled and then went through the xml trace log file and found out where the delays come: they are always from the JarSigningVerifier ....
Has anyone else seen something like that?
It is very easy to see and reproduce this behavior and i wonder if there is something i am overlooking. Having worked on applets for the past years extensively, i am totally lost at what can be happening. I can verify that reverting to the previous version of the plugin (and every other version before) works as expected.
I have submitted a bug report with oracle, but i haven't heard back still. Any info or idea will help,
TIA
Same here. I thought already I'm getting crazy. Thanks for sharing this.
We are using Java Web Start, but it's sharing the same problem of re-indexing all jar files (in our case it's an app with quite some jars, so starting takes ages).
Aside from the fact that Oracle suddenly decided to check the certificate of the deploy TLS, which caused some hickup on Linux and Macs (we used a StartSSL certificate there, which isn't included in the Java keystore - on Windows it works as it uses the platforms root certs, too).
And, to make it even worse, on Windows x86 the 8u31 silently dies if -XX:+DoEscapeAnalysis or -XX:+OptimizeStringConcat is present in the JVM arguments, though both parameters are standard in Java 8 (but not in 7, that's why they've been included, still). The 64bit engine doesn't have that problem.
The next thing they changed is they now overwrite the start icons if they've been changed (we changed them to put the 64bit engine's path in there), so it stubbornly changes the path back to the 32bit engine every time.
The behaviour of Oracle is not helpful at all, as they didn't announce any of these changes in their changelogs, let alone announcing the certs changes a few days ahead.
I would like to hear from anyone who's sharing the problems and possible workarounds.
Patric
Have you been able to solve this issue? Have you had a reaction from Oracle?
UPDATE START
I've tried everything I can think of and haven't managed to solve the
issue, so I posted my own question on this issue.
A similar bug report can be found here and is backported to at
least Java 8u51 which I tested. Yet again they managed to increase
startup time for our application.
END UPDATE
We are using Java Web Start for an Eclipse RCP-based application with jars that are all signed.
Startup time is 8s within the IDE, Java version doesn't seem to matter here. With web start the story is different. It becomes (much) worse with every Java update:
7u?? (<60): +2s (10s)
7u60: +5s (13s)
7u75: +15s (23s)
8u31: +12s (20s)
8u40: +21s (29s)
8u51: +23s (31s)
Have you tried your jnlp without versioning? In my experience Java jnlp is very buggy specially if you change the jnlp default values. Versioning support is disabled by support, so try it without versioning and see if it still slow?
For me, I noticed some bugs when I used update="background" value, so I no longer change the default update method. My theory is that Oracle only tests jnlp against default values before they release new Java versions.
I've recently had my app moved from Websphere Application Server 6.1 to WAS 7.5, due to end-of-life for 6.1. Consequently, I needed to update my debugging server. I found this to be an opportune time to move my application from an IBM RAD IDE to Eclipse (already had Indigo installed). Or so I thought.
Anyway, the powers that be, here, have recommended taking my debugger all the way to WAS 8.5, since I'm only using it to debug.
But the issue that I'm encountering is that I cannot get the debugger to stop on my breakpoints. I've got approx. 10 breakpoints in my opening page, all in JSP/Java code.
I'm running Java 1.6.0_32 and Java SE Runtime Environment build 1.6.0_32-b05. I really don't know how to check which JDK I've got loaded. I've seen recommendations to "go back" to JDK 1.5, but I can't be certain that's not what I'm running.
And to cover a few other bases, I have JUST started my system for the day, opened the IDE, started the server in debug (says "Debugging, Synchronized"), put focus on the opening page of the application and clicked "Debug on server". The front page opens without stopping at any of the breakpoints.
Does anyone have ideas or suggestions?
If you use eclipse's debugger and running the application outside eclipse environment , we have to configure it as remote java application.
Also check if the code deployed in server is in sync with the one present in workspace.
anything wrong of the ecplise's site.
Run->Skip all breakpoints
Well, I had recently faced this problem, where the code did not use to stop at breakpoints while I was in debugging mode and was sure that the particular piece of code is executing. In order to solve the problem, I did a clean-build-republish but it did not work, recreated the profile and readded the server with new profile, still did not work then finally re-installed RAD and web-sphere but It still did not work. Then I found the below article
https://www-304.ibm.com/support/docview.wss?uid=swg21240896
and realized it could be a problem due to some other OS process interfering with debug process/port so I performed a system restore. After restore when I deployed the application, debugger started working properly.
I'd like to say I found the answer to this, but I never did. I ended up dropping RAD and moving to debugging on Jetty. My local testing isn't EXACTLY as it would be on the test server, but it works. Not sure if this should be flagged as "answered" or not.
UPDATE: I have left this project but before I did, the entire development platform was moved to IDEA and debugging was no longer an issue. I don't know if I should find a way to mark this question as inactive or closed or whatever so that it's not just sitting out here getting views and responses when it's no longer an issue for me.
I've taken a job where years ago their webmaster setup an intranet using Tomcat on a linux server. The users can create something in the test environment and then click "make live" and the Linux/Tomcat moves the file to a Linux/live PHP web setup.
I'm clueless how they're moving the files. What would be a common tool to do this in Tomcat and Java?
I realize this is vague, but any help would be appreciated. Let me know what other info would be needed.
Also there is a duplicate MySQL database in both servers. I'm guessing the Tomcat setup is writing duplicate info to both databases, but I don't see how the files are getting moved.
This sounds like the website content is completely stored in the database and written over to the other server.
Theoretically you could also have a rsync shell script and call that from php to actually synchronize files over to the other server.
If the "Make Live" is on click and happens immediately its either a direct db access or some script based synchronization.
If it takes a while it could be a cron-job. Maybe you should just check this anway crontab -l will work.
There are several options, you actually open the *.php which the user can edit the content and see where the make live button brings you e.g. "Post Form to *.php" and than you check what that script is doing or you show us the package (what i would like to see but not suggest if you are working on a companies site).
Get back here with some more information, so i can expand the answer for you. Maybe you should also clarify why you are clueless, state what you have checked already, the info i would require is the actual site which has the make live button on it, it will lead to the next site or a script which will probably show what the site is doing.
So, nothing has changed with my setup over the past week. I have recently upgraded to Lion, but I have run this application several times since I have done that.
Today, I click the "Run Main Project" arrow in NetBeans 6.8, and I get a dialog box I have never seen before...
I have absolutely no idea what to do. I can find no reference to this error in Google.
Steps I have taken:
Reviewed the logs (nothing unusual up to the point where NetBeans freaks out.
Reverted to a backup Netbeans installation (no change in behavior)
Attempted to change the username/login information to the administrative Glassfish panel (no change in behavior)
Removed the .netbeans directory from my home, and restored to a known good offsite backup.
I have absolutely no idea what "8228 8228 8228" means.
One thing important to note is that Glassfish is running and the creds that I have supplied to NetBeans do work. I can log into the running Glassfish admin panel with them.
Any suggestions at all?
Leaving this here for anyone who happens to run into the same problem.
I would wager that this affects all versions of NetBeans.
I am not entirely sure what caused the original issue, but it appears that NetBeans attempted to "auto-discover" a proxy that I had installed on my system. (GlimmerBlocker, for blocking ads, among other things)
When it did this, Glimmerblocker did not report its IP address correctly (or NetBeans interpreted it incorrectly), resulting in something that looked like:
127.0.0.1
127.0.0.1:8228
8228
8228
Well, needless to say, when the Java NumberFormatter got a hold of that, it didn't like it one bit.
Setting NetBeans to "No Proxy" in it's settings, and restoring from backup again (to undo all the troubleshooting damage I had done) took care of the problem.
Again, leaving this only in the hopes that it helps at least one other problem who may run into something similar.
This is really driving me crazy. No matter what I do, it seems that Mirth (1.8.2) is running an older version of my JAR file; I know because of various signs, like:
I can't call any functions
Information logged is not showing up in the logs
Changed log messages are not changed in the log files
Files that were once created and written to in code, but no longer touched by code, are still being created and written
I've tried everything I can think of to make this work. It was working at one point, but now it seems like it's no longer being updated. My process to integrate my changes into Mirth are:
Run an ant script to build the JAR file
Copy the JAR file to \lib\custom
Restart the Mirth service (via Mirth administrator)
I've tried restarting (Mirth service via Services, Java, computer) -- to no avail. I know my JAR file is correct, because I've decompiled it (to make sure it has the latest code) and hashed it (to compare to the hash of the ant-built JAR) -- it is correct and the code is there; it's just not being run.
I'm at wit's end; this occurs infrequently but completely blocks me from developing.
Edit: I also know that my code is correct, because when I run unit tests, it generates the right files and calls the right functions and logs the right information. Only Mirth seems to "not get it."
And my classes are very simple; simple one-argument constructors and a few public methods that return various data. Nothing complex, no nested classes/JARs/dependencies.
Edit: I even deleted my custom JAR file and restarted Mirth, and it's still running my code. Awesome :/ I've added a bounty for this question. I suspect the JAR is cached somewhere (even though they deny it on the Mirth forums) and that cache needs to be cleaned out somehow (although why restarting the Mirth service and my PC doesn't do it is beyond me).
I've also killed all instances of Java (and rebooted my computer), so that makes it highly unlikely that the JVM is caching the JAR somewhere.
I tried reinstalling Mirth. For some reason, it had my custom channel when I booted the administrator for the first time; and infuriatingly, it's still running the old JAR, even though I've updated it with the new one in lib\custom.
I ended up solving this with a combination of actions:
Uninstalling Mirth and Java, and then reinstalling.
I also removed all Java installations except one (one JDK and one JRE).
I stopped Mirth when you copying my JAR. Stop Mirth, copy, and restart; don't try to copy on a live installation. It may or may not pick up your updated JAR depending on if it's loaded into a JVM or not.
This combination of steps seemed to work. Prior to this, I had 3-4 JREs installed (and two JDKs) and I was copying (successfully, according to Windows 7) the JARs while Mirth was running. It's working now!
Mirth is a J2EE application running on a plain old JVM; you have options for debugging it.
You could follow the instructions here for running Mirth Connect via Eclipse. You could then see the JVM classpath, you could set breakpoints and use the debugger.
Mirth is based on the Mule ESB. Mule has its own way of class-loading. You could research it.
If Mirth is really using an old version of your JAR, maybe it's got a cached version around somewhere. Or maybe you made some configuration changes you've forgotten about - perhaps you added a new directory for jars. (Not sure how you do that.)
Mule pays attention to an environment variable named MULE_LIB; maybe that's relevant.
It looks like Mirth Connect 1.8 and Mirth Connect 2.0 have different places for jars (lib/custom and custom-lib, respectively). Which version are you using?