Currently, I am using Rhino engine to execute some big blocks of javascript code on the server side. However, sometimes, it takes so long(more than 10 minutes) and eat up all CPU usage (at least on my local development env, it is doing this right now).
So I am wondering that what I can do to improve the current system or I can try a new one there.
Any thoughts would be appreciated.
Thanks!
PLUS:
It throws the exception while the code is too big:
java.lang.Exception: No Context associated with current Thread
You can compile the script before running it and cache the compiled version
see http://download.oracle.com/docs/cd/E17409_01/javase/6/docs/api/javax/script/CompiledScript.html
(edit: ops... i don't know if that would work on sdk 1.4)
We first have to know how big are the Javascript blocks that you are executing? 10 lines? 50 lines? 1000 lines?
If its getting 50+, then perhaps compiling would help. Since you are using 1.4, you must be using the official Rhino distribution and not javax.script. In that case just use the rhino compiler.
First though, have you profiled your program? Perhaps its something else thats causing the issue.
Are you sure your algorithm is as efficient as possible?
Please consider these before blaming Rhino
You generate the whole javascript code dynamically from database? maybe you could consider writing a fix piece of code, and filling data into the code with functions like:
ScriptableObject.putProperty(scope, "out", out);
ScriptableObject.putProperty(scope, "script", script);
then you can compile it, and store the 'scope' somewhere and reuse it.
Use the latest release of Rhino, which always has a 'jdk1.4' jar in the release, use it, maybe it'll help.
Related
How is the java utility that begins the process of launching a class told to "spill its guts" on what it's doing as it tries to load classes?
In particular, what file paths is it TRYING to access, only to perhaps discover whatever it's looking for is not there, at least as it interprets the specification given? There was a way to get that information, but I can't find it now.
Note that this is Java version "1.8.0_333" on Windows 10.
I've tried every flag known to me, via the -h and -X flags, and I strongly suspect what I'm looking for is (was) an X flag that's been removed, just as the -X help output warns. And so, there must be an OS way to figure this out, I sure hope!
You might ask why? Whatever for? What are you trying to do? Well, that's the bulk of this question's text. To wit:
As one of the very early users of Java (I started with 1.1) way back in the '90s, I had an issue moving an application suite I'd written for my company on Linux to MS Windows and I got it working by using Cygwin. Along the way, this same sort of issue came up and I quite vividly recall having found a mechanism for getting the Java launcher to articulate just what file specifications - paths - it was actually using in searching for the appropriate class. And through using this, I found that the CLASSPATH was being specified incorrectly, and with some experimentation, I got it working reliably. Now I need to do that again!
This flag I'd used was immensely helpful in figuring out just what the file specification format CLASSPATH needed to be (we're not talking semicolons here) this combination of OS, Java, and Cygwin. After some hours of what I hope was reasonable hunting, I'm wondering if this capability has been removed at some point? Either that or "I'm looking for the wrong thing." Heck, since the source is available (I think!), maybe some brave soul has hacked the java utility to do such a thing?
It may help to understand that for this application I wrote for my company, it was a major goal to have the source work pretty much the same on all Windows and Linux / Unix systems (and at the time, macOS), and just use a configuration file to tell the code what's different. And that wasn't easy to figure out, but with this flag, it wasn't that hard, either.
But, unfortunately, I haven't needed this knowledge since I figured it all out all those years ago, and apparently, this little kernel of knowledge is very hard to find today. Or, it's no longer pertinent to the modern version(s).
I don't think this has anything much to do with the actual problem, but it may help in people's thinking if they understood the scenario: The current situation is that I have a fully functional installation of this software on Windows 7 to use as a comparison for how to configure things on Windows 10 (and hopefully younger). The Windows 7 is running a pretty modern Cygwin installation and very nearly the most modern Java - just a sub-version away from the new installation from last week on a Windows 10 box. (Everything's bright and shiny new on the new box.)
The required format for CLASSPATH on the nearly identical but fully functional Windows 7 system is:
CLASSPATH="C:/opt/OurInstallationDir/lib"
And that's it.
This value is picked up in several places as the code later needs to launch Java itself to do some unusual things. However, the java command that gets it all going is launched from a C program - not that that matters for this problem - but the C program (compiled under Cygwin, but perfectly runnable from any Windows environment) helps ensure that the Java environment is secured (policy file contents and so forth) before getting into Java, else it refuses. And this program on Windows 11 launches Java just fine, it's just giving it a CLASSPATH that isn't useful, apparently, even though the files are there where they should be, etc.
Configuring things as before just doesn't work, even from the command line. No version of specifying CLASSPATH seems to work if it's more than a dot; the only thing that works, is being in the /lib directory when starting and using "-cp ." ... But that's just not going to fly for so many reasons! To be a little more clear, I've tried reversing the slashes, using /cygdrive/c/, and whatever else I could think of. But, at least we know that if you're in the directory and use -cp, it will find and launch the program. So, there's nothing wrong with the Java, just pointing the java utility at it.
Again: How is the java utility that begins the process of launching a class told to "spill its guts" on what it's doing as it's trying to load classes?
You use this construct on the JVM:
java -XX:+TraceClassPaths -cp "C:\opt\SomeDirectory\lib" myClass
I was able to get confirmation of what Java was using, not only for my CLASSPATH, but "internally" by using the above.
The fact that it echoed back both what I was doing and what it was doing somehow gave me the insight to check everything about it. Java itself doesn't work (at all) if it's installed in a location that it thinks has a link in it, and it's own fetches go right back to the system disk specification.
From that I found that Java on Windows won't take a CLASSPATH that has a link in it!
Simply ensuring that the whole tree was specified "from the top" of the drive it's on works. If it's not, it won't.
It's now working happily using the syntax noted above.
This is quite different from every other application I've seen on Windows. But, well, it's Java!
This really came from a pointer from Mark Rotteveel who commented above about this article: How to track when class is loaded and destroyed in jvm? And therein I learned how to get the list of all the options the presently in-use JVM supports. All Java developers should be aware of this in my opinion, so thanks to Mark for that.
I'm currently making the move to Java 7 and I'm trying to convert all of my classes to use the new java.nio.file package. At one point, I try to check whether a file is readable and writable with what resembles the following code:
MyClass myObject = new MyClass();
Path path = Paths.get("testDir/sub1/sub2/test.txt");
myObject.setReadable(Files.isReadable(path));
myObject.setWritable(Files.isWritable(path));
When I test this with junit (on Windows 7), both isReadable(); and isWritable(); consistently hang for 25 seconds each before they return. This is quite unacceptable. Could this be a Windows limitation?
My application will eventually be running on unix but I have not had a chance to test on it yet. I think I should mention that each file I'm testing was created with the following code:
Files.createFile(Paths.get("testDir/sub1/sub2/test.txt"));
Is there anything I can do to help speed things up? Thanks!
Edit:
So it seems that path.toFile().canRead() returns instantly, same for canWrite(). If it comes to it, I can use those methods but I would really like to only use the java.nio.file package.
What version of JRE are you using?
To solve this issue, update the JRE to 1.7.0_40+
The issue causing this:
Checking file access on Windows is expensive because it requires
reading the DACL and computing the effective access to the file. To
bypass this, the checkAccess implementation on Windows has a fast path
for the check read case but unfortunately Files.isReadable isn't using
that fast path.
For more details please see: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7168172
I have a simple test case producing a sure ArrayOutOfBoundException in jzlib
1.0.7 depending on the data subsequently written to one and the same instance
of ZOutputStream.
Stacktrace:
java.lang.ArrayIndexOutOfBoundsException: 587
at com.jcraft.jzlib.Tree.d_code(Tree.java:149)
at com.jcraft.jzlib.Deflate.compress_block(Deflate.java:691)
at com.jcraft.jzlib.Deflate._tr_flush_block(Deflate.java:897)
at com.jcraft.jzlib.Deflate.flush_block_only(Deflate.java:772)
at com.jcraft.jzlib.Deflate.deflate_slow(Deflate.java:1195)
at com.jcraft.jzlib.Deflate.deflate(Deflate.java:1567)
at com.jcraft.jzlib.ZStream.deflate(ZStream.java:133)
at com.jcraft.jzlib.ZOutputStream.write(ZOutputStream.java:102)
at com.jcraft.jzlib.JZLibTestCase.main(JZLibTestCase.java:51)
at JZLibTestCase.main(JZLibTestCase.java:28)
The problem occurs very rarely and depends on the data subsequentially
written to an open ZOutputStream from jzlib.
Do you have a hint how to fix this? Have you ever heard of this?
Near as I can tell you might've found a bug with JZlib. While searching around I came across other places that have your post with attached source and data files. It does not appear that you're doing anything wrong. You should be able to stream any sequence of bytes to ZOutputStream.
Is there a particular reason you're using JZlib? The two main reasons I understand to use it are support for Z_PARTIAL_FLUSH mode and licensing. If you don't need that flush mode and you're using the Oracle JVM, you should be just fine with the included DeflaterOutputStream. Substituting it in your code for ZOuputStream works without an exception.
I haven't found a concrete reason for using jzlib asking my co-workers, but for sure there has been a bug using java.util.zip somewhen in JRE 1.4 on multi-processor systems, although no one has been able to tell me concretely which one. From that time on we have been using jzlib, which has worked good for many years. Most probably it is already fixed. Nevertheless, using java.util.zip works with my simple test data in the same manner jzlib failed with, that's true.
I have a system set up that's been happily running R from a java servlet, spawning processed & hooking into the process's stdin, stdout, and stderr streams, as in the second andwer to this question.
After a system upgrade (that included glibc), the input is no longer reaching the R process.*
Until now, 'R --vanilla --slave -f [file] ...' was working fine for me. I also have no swing dependencies right now, so I'm somewhat reluctant to add them. (I may actually not be able to add swing dependencies; am I right that using REngine automatically brings swing in? The examples import all of swing.)
Are there advantages to switching to JRI? What changes would I need to make to my R script? (It currently reads from stdin and writes to stdout). I'm not finding the provided examples terribly helpful for how to use JRI in this situation.
Thanks for your help & comments.
*I can't even tell if the problem is data being written too soon or too late, but that's a separate issue/question; if I move to JRI I'm hoping it all becomes moot.
My two cents:
I find working with JRI to be straight-forward. There are several examples provided with JRI that give a good demonstration of how to use it.
In general, you shouldn't have to make any major changes to your script because you can simply pass in an entire script as an expression with the eval() function and then handle the return value. The main advantage as I see it is that you're then handling the R process from within your Java code, so you can with exceptions properly without having to make any system calls. JRI also provides some R data type equivalents in Java such as RVector.
Is it possible to enter an infinite loop at compile time?
My program seems to enter an infinite loop when I attempt to compile it. I have a class with a class constructor that calls the method gameRun(). gameRun() calls itself at the end of its execution, but should have the appropriate checks to be able to break from it during run time... However when I attempt to compile the class, I actually seem to get an infinite loop then.
My understanding of compilation is that it does not actually execute the code... Which would mean it would be impossible to enter an infinite loop unless there is actually a serious bug in the compiler's source. Is this correct?
I am writing in Java, and am using BlueJ (a beginner's IDE which I am growing out of) as my IDE.
Thanks in advance.
.....................................
Thanks to you all for so many helpful responses. Just thought I'd post an update, as this seems to have perked some interest, and I am curious about it myself.
I have not done a whole lot with BlueJ or this error since I posted the original error, becuase I had taken the source files from the project, and was able to successfully compile and run them with eclipse. This suggests to me that it is a BlueJ (or related) problem. I have continued to work on this project with eclipse without any more problems of this nature. I will follow up with more detail on the problem when I am able to use the machine with the original project on it again. (Nothing should have been changed since)
.....................................
As an afterthought... Is there any way I can link this question to an account I have created and registered since this was posted? I can't find a way to do that, and it would make keeping track of this more convenient...
Some languages do allow the compiler to enter an infinite loop. Java isn't one of those languages. :-)
You're right, the compiler doesn't execute the code, and would only enter an infinite loop due to a bug. I'm confident that the javac compiler from Sun doesn't have such a bug.
I don't know what compiler BlueJ is using "under the covers", but I have seen a problem when Ant runs javac that makes it take a really long time to compile. Simply stated, there are some cases where Ant will direct the compiler to load every class under a given directory. If that directory contains hundreds of third-party libraries, it can take a while… or even run out of memory.
Does your compilation hang (loop) if you just use javac ?
I've never seen a compilation hang indefinitely whilst compiling Java and I'm wondering if BlueJ is having a problem instead.
It would be theoretically possible to do if, for example, to compile a file, the compiler first had to have finished compiling that file. (Ahhh... Recursion).
But I'd imagine checking for that kind of madness would be the first thing a real-world compiler would handle.
But I wouldn't think it would happen on a method/function, unless (postulating) the compiler was trying to resolve tail-recursion to an simpler implementation, and failing. But, again I can't imagine that would be an issue with a modern Java compiler, even if it exists at all. Certainly I'd imagine that the compiler would eventually give up and post an error rather than infinite looping.
It's far more likely to be the IDE than the compiler. At a guess, the IDE might be trying to trace a warning/error to its source in the code in order to highlight it and getting trapped. Does BlueJ have text-highlighting on compiler errors/warnings? You could try turning it off.
Although, as many others have already suggested, the first real test is to compile from the command line using
javac *.java
Or whatever files your code uses.
EDIT: Sorry I never got back to you. For future reference, to compile from the command line (I'm assuming Windows as your OS):
Open the command line by going to the start menu and select Run...
Type cmd into the Run dialogue, and click OK.
This should bring up a cmd.exe console.
From here, use the "cd" command to change directory to the directory containing your java files.
(cd "My Documents\Java\Monster Battle\core")
Once you're in the right directory, type "javac *.java". This will run the compiler without needing to deal with the IDE. It should pause while compiling, and when it's done, you get the command prompt back.
If you type "javac *.java -verbose" you get full output, in case you get your infinite loop.
If that works fine, it's an IDE bug. Send them a bug report. If it doesn't, congratulations! You've found something really interesting, that will probably tie up some poor Sun developer for a month.
If BlueJ does use its own compiler, you may have found a bug in it, or in BlueJ's build tools that surround it.
You might take a BinaryChop approach to this one: break your program into pieces, compile them individually, and see if the compiler-hanging behavior can be isolated to a small, specific testcase. At the end of the day, you'll either have an excellent bug report to show the BlueJ people, or you'll find that your program actually does compile (yet you'll be scratching your head).
AFAIK, Standard Java cannot be compiled infinitely.
Are you sure that the problem is at compilation rather than at some other feature that BlueJ provides? Many Eclipse-based IDEs perform multiple actions during a rebuild, and that compilation is just one of them. It is possible that something else does.
What exactly do you see? An unending Eclipse task?
Try to make the source code you are compiling as small as possible and still exhibit the behaviour you describe. The process of doing so, may help you identify what the problem is.