I have a Rails 3.2.13 application written in JRuby (1.7.12). I'm developing on Mac OS X 10.10 (though the problem was also evident on 10.9). I have both JDK 1.6 and 1.7 installed. I'm serving the application via torquebox 3.1.1.
If I start the application connecting to my local postgres database, I have no issues. But I need to debug a problem that requires connecting to Oracle. I then switch my adapter to oracle-enhanced and making sure I have ojdbc6.jar and ojdbc7.jar in $JRUBY_HOME/lib. When I start the application via torquebox, I get errors like this:
14:47:58,242 ERROR [org.torquebox.core.runtime] (pool-8-thread-1) Error during execution: ENV['RAILS_ROOT']=RACK_ROOT
ENV['RAILS_ENV']=RACK_ENV
require %q(org/torquebox/web/rails/boot)
: org.jruby.exceptions.RaiseException: (NoMethodError) undefined method `blame_file!' forjava.lang.StackOverflowError:Java::JavaLang::StackOverflowError
I realize the blame_file! error is a separate thing. The StackOverflowError that's the cause of that error is what I care about. It's getting into a failing loop when trying to load necessary files, like rails/boot in this case.
However! When I run "rails console" it works fine and I can load data from the database.
I'm convinced as a result of being able to load the console that this is a problem with torquebox somehow, but I don't know what, nor how to fix it.
Is there any helps anyone can give me? Has anyone seen something like this before? Thanks.
(Edit, I found a locally cached copy of ojdbc7.jar in the app, which explains my original errors with 1.6. I've edited this post to reflect the current situation.)
Try looking at https://github.com/jruby/jruby/issues/976 to work around the blame_file problem and then hopefully you'll get a more useful error message.
Maybe then you'll get something be able to diagnose something similar to:
Error while loading java Class in Jruby application
I got some help on irc.freenode.net/#torquebox. After some confusion about the stack output vs. my stack size, it was suggested that I scale that back some. I set it from 4096m (yes, I realize now that that's ridiculous) to 2048k, and it works.
We don't know why Java crapped out in this specific way, but the end result is that with a smaller stack size, it works now.
Related
I am getting an error in Weblogic. I am running Weblogic 14.1.1 with OpenJDK 11.0.2. I am running on Red Hat Linux Enterprise version 8.4. This is a required platform stack, so I can't update any of these.
The error I am receiving is "Could not check file size to determine chunk rotation". It shows up in the Weblogic log after about 7-10 days of running. And it just keeps printing out, filling up the log.
I found the error message in the following Java class in OpenJDK:
https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java
The class name is PlatformRecorder.java. And the error is on line 442 in method periodicTask().
try {
if (SecuritySupport.getFileSize(currentChunk.getUnfishedFile()) > Options.getMaxChunkSize()) {
rotateDisk();
}
} catch (IOException e) {
Logger.log(JFR_SYSTEM, WARN, "Could not check file size to determine chunk rotation");
}
As you can see, it is in a catch block for an IOException. Unfortunately, they do not print out the detail of the Exception in the log.
This seems to be part of Java Flight Recorder (JFR). I am not familiar with this, but my understanding is that it is not supposed to be enabled by default. But Weblogic/OpenJDK does appear to be running it (since I am getting that error).
Since this error doesn't show up until Weblogic has been running for about a week, it almost sounds like there is some resource that is unavailable or is being "used up" after a certain amount of time. I did check the disk space, and I saw nothing out of the ordinary. I also found some ".jfr" files under the Weblogic directory structure, but they were all empty.
I thought maybe I could replace the default implementation of this class with one of mine where I print out the exception detail to maybe give me a clue. But these seem to be in Java modules. And I'm uncertain how to replace a native Java class in a module with one of mine.
The other thought is maybe there is some profiling going on in Weblogic that is causing this to be started. But I'm not sure how to turn all profiling off (or if that would even be a good thing to do). But I obviously can't recycle Weblogic once a week in production because this error keeps showing up.
Does anybody have any ideas on what could be causing this error? Or maybe how to determine some more detail, like how to override a built-in class in a Java module, or some other idea? Has anybody else even seen this error? I could not find it mentioned anywhere else.
Thanks for any help in troubleshooting this issue.
Just wanted to follow up on this question. As Emannuel stated, Weblogic does not support OpenJDK. Because of licensing issues, we split the project into 2 parts. One part is OpenJDK, and the other part is Weblogic, which comes with the Oracle JDK license. So everything that runs inside Weblogic will use the Oracle JDK that comes with the Weblogic license. The rest of the project will use OpenJDK.
While it is not an ideal solution, using the Oracle JDK for the whole project was cost prohibitive, so splitting the project was the only solution acceptable for the client.
In our application we encounter very sporadic run time exceptions which crash our message processors (which are stand-alone java processes running on Java 8). The processors, at the time of this exception, generally try to execute a web service call.
The exception are
java.lang.Error: Failed to create new instance of com.sun.xml.internal.ws.api.streaming.XMLStreamWriterFactory$1
at com.sun.xml.internal.ws.api.streaming.ContextClassloaderLocal.createNewInstance(ContextClassloaderLocal.java:63)
..
Caused by: java.lang.IllegalArgumentException: Unable to access unsupported property javax.xml.stream.isRepairingNamespaces
at weblogic.xml.stax.ConfigurationContextBase.check(ConfigurationContextBase.java:90)
The strange thing is, the whole application is running without errors 99.9% of the time: the above exceptions happen quite infrequently (ca. every couple of days). After a crash, the processors are restarted automatically, and again operate perfectly fine, until the same exception occurs again after a seemingly random interval.
So far we could not correlate this with any misbehavior on the part of the JVM or the host the application is running on.
Does anyone have any pointers as to why such an unsupported property javax.xml.stream.isRepairingNamespaces exception could appear sporadically?
We're running jdk1.8.0_66 on Red Hat 4.8.5-4. Web service interfaces are generated using JAX-WS.
Edit:
I can't share the classpath (lots of internal info, sorry). We do have the Weblogic full client in there though: wlfullclient-12.1.3.jar. It defines an XML factory via ServiceLoader
META-INF/services/javax.xml.stream.XMLOutputFactory --> weblogic.xml.jaxp.RegistryXMLOutputFactory
Where as xml-apis-1.4.01.jar (also on classpath) contains javax/xml/stream/XMLOutputFactory.class (related to the exception thrown in ConfigurationContextBase).
Could this be part of the problem?
You have to change the class path order. At first point all the axis2 jars and then point the weblogic.jar in class path. Hope it will solve your issue.
I encountered this problem yesterday after making some significant changes to my code. This particular post is the ONLY information I can find by googling this particular error -- always a bad sign. After hours and hours of fruitless deep debugging, comparing the original working version of the code with the new non-working version, I decided to start backing out my code changes to see where/when the problem originated. Well, after backing out pretty much every single code change, the problem was still happening. I finally realized that this problem was perhaps external to the code. It turns out that at some point, I had added an extraneous library: wstx.jar to my lib directory. Once I removed that lib, everything worked great. So apparently it was utilizing the wrong classes to try to perform this operation.
Not sure if that is of any assistance to you, but even if not, I thought someone someday might stumble onto this and find it to be useful.
I have googled far and wide and not found any references to this issue, so any help would be much appreciated.
I can regularly generate an illegal access error when using the Java Less compiler (https://github.com/marceloverdijk/lesscss-java), but not on my development machine - only on Heroku (and dokku it seems - same issue there). The compiler calls compile on some javascript code, which goes through the optimiser, and fails with the following stack trace:
java.lang.IllegalAccessError: tried to access method org.mozilla.classfile.ClassFileWriter.getLabelPC(I)I from class org.mozilla.javascript.optimizer.BodyCodegen$ExceptionManager
at org.mozilla.javascript.optimizer.BodyCodegen$ExceptionManager.endCatch(Codegen.java:4051)
at org.mozilla.javascript.optimizer.BodyCodegen$ExceptionManager.removeHandler(Codegen.java:3952)
at org.mozilla.javascript.optimizer.BodyCodegen.visitTryCatchFinally(Codegen.java:3705)
at org.mozilla.javascript.optimizer.BodyCodegen.generateStatement(Codegen.java:1897)
at org.mozilla.javascript.optimizer.BodyCodegen.generateStatement(Codegen.java:1873)
at org.mozilla.javascript.optimizer.BodyCodegen.generateStatement(Codegen.java:1858)
at org.mozilla.javascript.optimizer.BodyCodegen.generateBodyCode(Codegen.java:1289)
at org.mozilla.javascript.optimizer.Codegen.generateCode(Codegen.java:306)
at org.mozilla.javascript.optimizer.Codegen.compileToClassFile(Codegen.java:166)
at org.mozilla.javascript.optimizer.Codegen.compile(Codegen.java:75)
at org.mozilla.javascript.Context.compileImpl(Context.java:2377)
at org.mozilla.javascript.Context.compileReader(Context.java:1296)
at org.lesscss.LessCompiler.init(LessCompiler.java:295)
at org.lesscss.LessCompiler.compile(LessCompiler.java:357)
at org.lesscss.LessCompiler.compile(LessCompiler.java:450)
This is particularly odd since the method it fails to call is public (https://github.com/mozilla/rhino/blob/master/src/org/mozilla/classfile/ClassFileWriter.java#L1260-L1268).
As mentioned, I think this has something to do with the Heroku environment, since I cannot replicate this on my development machine.
Any ideas would be gratefully received.
I resolved this by excluding the offending dependency from my build in project.clj, since it wasn't actually needed itself. I'm still not sure why this problem only manifested itself in some environments, but it is now resolved at least.
I have a jar package that I wrote using netbeans. This package is called from other java file. The jar calls a webservice and is supposed to do something with it. Now everything works fine locally. I compiled the files and locally and uploaded them to the server and when I run it, I get the "Service could not be initialized".I am not sure how to debug this. I am pretty new to java. What is the best approach here to solve the issue?
I would start by implementing logging (I like log4J) in your project so you can get some better details of what is actually going wrong. This will be very useful not only now but in the future as things go wrong (they inevitably will) you will be able to solve them based on how good of a job you did logging what is happening in your application. Right now it sounds like an error is bubbling up and you're not getting much detail about it. Logging should help you determine not only what went wrong but where it happened and what the application was doing at the time.
Try this short introduction to log4j to get started.
I'M NOT ASKING ABOUT THE CODE. I just want to know what are and all the steps involved in the connection other than coding. I'm using j2sdk1.4.0 and MySQL Server 4.1. Am very new to this area.
Thanks in advance
If your code cannot find the class, then that's always going to be an issue with your classpath (and this isn't specific to JDBC in any way). Make sure you have the MySQL JDBC JAR on your classpath at runtime (it's probably called mysql-connector-java-3.0.17-ga.jar; if you have an IDE, it can probably tell you where the class in question lives).
I maybe my advice will not be as useful as that from Vinegar, but to keep it simple you can always do it like this:
First download the'mysql-connector-java.jar' -- I suppose you already have this -- if you're in Linux a yum install mysql-connector-java will suffice.
Compile your code normally
Now when you need to run your app do something like this on the command line:
java -classpath .:“/someplace in your computer/mysql-connector-java.jar” your app
I hope this can help you get started. Good luck!