We are getting a mustache play error in production (amazon linux EC2 AMI) but not in development (MACs) and we have tried upgrading the jvm, using the jdk instead, and changing from a tomcat deploy model to match our development environments as much as possible but nothing is working. Please any help would be greatly appreciated. We have lots of shared code in java and javascript using mustache and it would be a big deal to rewrite everything if we had to ditch mustache on the java side.
20:48:52,403 ERROR ~
#6al2dd0po
Internal Server Error (500) for request GET /mystuff/people
Execution exception (In {module:mustache-0.2}/app/play/modules/mustache/MustacheTags.java around line 32)
NullPointerException occured : null
play.exceptions.JavaExecutionException
at play.templates.BaseTemplate.throwException(BaseTemplate.java:90)
at play.templates.GroovyTemplate.internalRender(GroovyTemplate.java:257)
at play.templates.Template.render(Template.java:26)
at play.templates.GroovyTemplate.render(GroovyTemplate.java:187)
at play.mvc.results.RenderTemplate.<init>(RenderTemplate.java:24)
at play.mvc.Controller.renderTemplate(Controller.java:660)
at play.mvc.Controller.renderTemplate(Controller.java:640)
at play.mvc.Controller.render(Controller.java:695)
at controllers.MyStuff.people(MyStuff.java:183)
at play.mvc.ActionInvoker.invokeWithContinuation(ActionInvoker.java:548)
at play.mvc.ActionInvoker.invoke(ActionInvoker.java:502)
at play.mvc.ActionInvoker.invokeControllerMethod(ActionInvoker.java:478)
at play.mvc.ActionInvoker.invokeControllerMethod(ActionInvoker.java:473)
at play.mvc.ActionInvoker.invoke(ActionInvoker.java:161)
at Invocation.HTTP Request(Play!)
Caused by: java.lang.NullPointerException
at play.modules.mustache.MustacheTags._template(MustacheTags.java:32)
at play.modules.mustache.MustacheTags$_template.call(Unknown Source)
at /app/views/User/people.html.(line:22)
at play.templates.GroovyTemplate.internalRender(GroovyTemplate.java:232)
... 13 more
Seems the issue is with the threadlocal. In Prod as per my logs, the session gets initialized with the main thread.
[2012-06-30 18:35:38,102] INFO 10097[**main**] - Mustache module initialized
However, MustacheTag tries to access with various thread like this during request.
[2012-06-30 17:48:44,669] INFO 66048[**play-thread-1**] - [{module:mustache-0.2}/app/play/modules/mustache/MustacheTags.java:46] _meta() :: MustachePlugin.session():null
So I changed the implementation of MustachePlugin like this.Changed line commented out:
//private static ThreadLocal<MustacheSession> session_ = new ThreadLocal<MustacheSession>();
private static MustacheSession _session = null;
public static MustacheSession session(){
//return session_.get();
return _session;
}
public void onConfigurationRead(){
// some code
_session = new MustacheSession(compiler, root);
// some code
}
And it is working fine now in prod mode! I see no reason why it should have been in a ThreadLocal in the first place as the session gets initialized at startup!
your issue is difficult to reproduce so i'll give few pointers here. you have tried to eliminate of issue being env issue. so other possible issues could be
data issue: many times reason for production issue is usually difference in actual data and test data. check if its data issue which is casuing NPE.
code issue: Is there something at people.html.(line:22) causing issue. first try removing / altering that to check if thats causing issue. Or can you get source code of mustache (exact version which you are using) and see what object its trying to create and where its failing.
Properties file for different environments: do you have different proprties file for each env? If yes, have u missed on any property for prod env?
You have a NullPointerException on MustacheTags.java at line 32.
This means that you are probably calling a method of the Mustache library and passing a null value.
Try logging all the parameters you transfer to this method (MyStuff.java line 183?).
You can look at the source code of MustacheTags here, it might help you understand what values you are passing and what should be passed.
Related
I'm trying to get a basic Custom Vision image classifier working by following the tutorial in the Azure documentation found here: https://learn.microsoft.com/en-us/azure/cognitive-services/custom-vision-service/quickstarts/image-classification?pivots=programming-language-java
I have followed this tutorial word for word and have spent a couple days trying to work this out. The issue I am having is when running the code I am getting the following stack trace:
Parameter this.client.endpoint() is required and cannot be null.
java.lang.IllegalArgumentException: Parameter this.client.endpoint() is required and cannot be null.
at com.microsoft.azure.cognitiveservices.vision.customvision.training.implementation.TrainingsImpl.createProjectWithServiceResponseAsync(TrainingsImpl.java:2313)
at com.microsoft.azure.cognitiveservices.vision.customvision.training.implementation.TrainingsImpl$TrainingsCreateProjectParameters.execute(TrainingsImpl.java:2401)
at com.microsoft.azure.cognitiveservices.vision.customvision.samples.CustomVisionSamples.ImageClassification_Sample(CustomVisionSamples.java:67)
at com.microsoft.azure.cognitiveservices.vision.customvision.samples.CustomVisionSamples.runSample(CustomVisionSamples.java:46)
at com.microsoft.azure.cognitiveservices.vision.customvision.samples.CustomVisionSamples.main(CustomVisionSamples.java:374)
The endpoint is defined here and passed as a parameter
final String Endpoint = System.getenv("AZURE_CUSTOMVISION_ENDPOINT");
CustomVisionTrainingClient trainClient = CustomVisionTrainingManager.authenticate("https://{Endpoint}/customvision/v3.0/training/", CustomVisionTrainingClientKey).withEndpoint(Endpoint);
CustomVisionPredictionClient predictClient = CustomVisionPredictionManager.authenticate("https://{Endpoint}/customvision/v3.0/prediction/", predictionApiKey).withEndpoint(Endpoint);
While the tutorial doesn't explicitly state to do so I have tried to set the system environment variable AZURE_CUSTOMVISION_ENDPOINT manually with PowerShell and it doesn't work with or without this set.
Am I missing something? Any help would be greatly appreciated!
Fixed my own issue. The environment variables had not set correctly and were null pointers. I replaced the System.getenv call to the string in plain text and this is working correctly.
I've test my apps using elasticsearch with very simple line of code. Like this :
Node node = nodeBuilder()
.settings(Settings.settingsBuilder().put("cluster.name", "elasticsearch").put("clster.transport.sniff", true).put("path.home", "/home/kenny/Program/Java/elastic"$
.node();
But I got error like this :
Exception in thread "main" java.lang.NullPointerException
at java.io.Reader.<init>(Reader.java:78)
at java.io.InputStreamReader.<init>(InputStreamReader.java:113)
at org.elasticsearch.node.internal.InternalSettingsPreparer.randomNodeName(InternalSettingsPreparer.java:198)
at org.elasticsearch.node.internal.InternalSettingsPreparer.finalizeSettings(InternalSettingsPreparer.java:177)
at org.elasticsearch.node.internal.InternalSettingsPreparer.prepareEnvironment(InternalSettingsPreparer.java:101)
at org.elasticsearch.node.Node.<init>(Node.java:128)
at org.elasticsearch.node.NodeBuilder.build(NodeBuilder.java:145)
at org.elasticsearch.node.NodeBuilder.node(NodeBuilder.java:152)
at TryElastic.main(TryElastic.java:56)
I don't know how to solve this problem, I've try and looking for the solution. Line 56 at error log, refer to ".node()" method above. So, dou you have suggestion or there are something that I've to add in my code
Thanks.....
The only way this can happen is due to a misconfiguration of path.home.
When Elasticsearch tries to generate a random node name for your instance, it looks for a file at {path.home}/config/names.txt
If the file cannot be found, you'll get a (rather unfriendly and unhelpful) NullPointerException.
So the solution is to check that "/home/kenny/Program/Java/elastic" is really the top-level of an ES installation.
See here for docs on the correct directory layout.
My JDMK based application is getting intermittent IOExceptions at line 313 in com.sun.jdmk.comm.HttpSendSocket and I can't figure out why. All I know from the Javadoc about this is if an I/O error occurs while creating the input stream you'll get an IOException, but I don't know what kind of I/O error occurred or why one did. The code actually worked both before and after this error transpired.
Any tips on how to debug this intermittent problem would be appreciated.
I don't want to paste the source code here for HttpSendSocket since it belongs not to me, but I know it's doing an HttpURLConnection conn.getInputStream() when the IOException exception is thrown.
I thought about trying to create my own version of HttpSendSocket, and adding diagnostics in it, but couldn't figure out how since it's a package protected class.
Stack trace below:
com.sun.jdmk.comm.CommunicationException: java.io.IOException: HTTP request failed
at com.sun.jdmk.comm.HttpSendSocket.readNotify(HttpSendSocket.java:313)
at com.sun.jdmk.comm.HttpSendInputStream.read(HttpSendInputStream.java:95)
at java.io.FilterInputStream.read(FilterInputStream.java:94)
at java.io.PushbackInputStream.read(PushbackInputStream.java:150)
at com.sun.jdmk.comm.GenericHttpConnectorClient.sendHttp(GenericHttpConnectorClient.java:486)
at com.sun.jdmk.comm.GenericHttpConnectorClient.invokeRemoteOperation(GenericHttpConnectorClient.java:2234)
at com.sun.jdmk.comm.GenericHttpConnectorClient.invoke(GenericHttpConnectorClient.java:1366)
As I said, any helpful suggestions would be appreciated.
The communication Exception was caused by using ArrayList method subList. ArrayList is serializable but subList data IS NOT serializable, and therefore you cannot retrieve the data over an HttpConnector. The solution was to change:
List<UserProcessInfo> values = new ArrayList<UserProcessInfo>();
...
values.size() <= 1000 ? values : values.subList(0,1000);
to:
List<UserProcessInfo> values = new ArrayList<UserProcessInfo>();
...
return values.size() <= 1000 ? values : new ArrayList<UserProcessInfo>(values.subList(0,1000));
Attach the JDMK source to your IDE, then set a breakpoint in the HttpSendSocket and run it with debugging enabled. At least in IntelliJ you can attach the library source by trying to open the class from the stacktrace, then choosing to link source. Don't know how the process is for other IDE's but I would expect it to be possible.
I have used EMC Documentum Foundation Classes to perform some actions in documentum repository. The code was working fine. I exported the project as a runnable JAR and then tried to run it. However I got following error and I am not able to understand it.
And here is the code for DocMovementHandler.getSession()
Actually this is no new code but regular code for obtaining documentum session
public IDfSession getSession(String userName, String password)
{
DfClientX clientx = null;
IDfClient client = null;
IDfSession session = null;
try {
// create a client object using a factory method in DfClientX
clientx = new DfClientX();
client = clientx.getLocalClient(); //takes time
// call a factory method to create the session manager
IDfSessionManager sessionMgr = client.newSessionManager();
// create an IDfLoginInfo object and set its fields
IDfLoginInfo loginInfo = clientx.getLoginInfo();
loginInfo.setUser(userName);
loginInfo.setPassword(password);
// set single identity for all docbases
sessionMgr.setIdentity("xyz_repo", loginInfo);
session = sessionMgr.getSession("xyz_repo"); //takes time
//sessionMgr.beginTransaction();
System.out.println("Session obtaied.");
}
catch (DfServiceException dse)
{
DfLogger.debug(this, "Error while beginning transaction. ", null, dse);
dse.printStackTrace();
}
catch (Exception e)
{
DfLogger.debug(this, "Error while creating a new session. ", null, e);
e.printStackTrace();
}
return session;
}
And that line 38 is client = clientx.getLocalClient();
InvocationTargetException is a wrapper. It says, "an exception occurred behind this reflection call", and you use getCause() to get at the inner exception.
The stack trace contains the inner exception. It's an ExceptionInInitializerError. That's another wrapper. It says, "whatever you did caused a new class to be loaded, and that class's static initializer threw an exception".
The final exception in this chain is the NullPointerException. That's the one you need to solve. Which means you need to debug this com.documentum thing. As the comments pointed out, that's not going to be easy.
Here is the most likely problem:
The static initializer in one of the classes whose names you have struck is adding an entry with either a null key or a null value to a Hashtable, which does not allow null keys or values.
It is using the Hashtable as a place to store a bunch of persistent properties and all that, and my guess is that the value for one of the entries was the null (which is a perfectly reasonable way to indicate that some feature is unavailable or something like that).
The now deprecated Hashtable needs to be replaced with the more modern HashMap.
If it is a library, that you can't just modify, you should replace the whole library with an updated version.
Here are some clues may be helpful.
The NullPointerException is thrown by Hashtable#put, and this is normally because either the key or the value is null.
Hashtable#put is called by PreferenceManager.readPersistenceProperties, so most likely it's because something is missing in a properties file so the value is null.
This NPE caused the DfClient class could not be loaded.
DfPreferences is the class loading the DFC configuration file dfc.properties. There must be something wrong with it.
Ohkay I did not pin pointed the root cause, but found the solution that will definitely work everytime.
EMC provides a flavor of Eclipse called Documentum Composer to work with Documentum Projects. Since Eclipse variation we can create other types of projects like normal Java project, dynamic web project, web services in this. So I recreated my project in Documetnum Composer and exported it as JAR and whoaaaa it worked.
I tried this many times and this worked all time.
Some points to note:
You have to replace dfc.properties file in Composer installation folder with one in Content Server
The Export to JAR wizard in Composer is a bit different than one in Eclipse
This is usually caused by dfc.properties being incorrect.
Preferences are stored on the global registry repository and the connection details should be specified in dfc.properties. If not, this (or a similar error can occur).
Also, always try to clear cache and use the correct version of the dfc jar's (v6.7 content server requires 6.7 jars, etc...).
I create a map using
new MapMaker().softValues().maximumSize(cacheSize).makeMap();
This seemed to work fine, however, I sometimes get the following exception after accessing right after deploying on the server and putting new elements into the map:
java.lang.IllegalStateException: Can't overwrite cause
at java.lang.Throwable.initCause(Throwable.java:320)
at org.jboss.mx.loading.RepositoryClassLoader.findClass(RepositoryClassLoader.java:624)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:474)
at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:415)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at com.google.common.collect.CustomConcurrentHashMap$2.iterator(CustomConcurrentHashMap.java:828)
at java.util.AbstractCollection.remove(AbstractCollection.java:241)
at com.google.common.collect.CustomConcurrentHashMap$Segment.removeFromChain(CustomConcurrentHashMap.java:2599)
at com.google.common.collect.CustomConcurrentHashMap$Segment.processPendingCleanup(CustomConcurrentHashMap.java:2772)
at com.google.common.collect.CustomConcurrentHashMap$Segment.runLockedCleanup(CustomConcurrentHashMap.java:2860)
at com.google.common.collect.CustomConcurrentHashMap$Segment.preWriteCleanup(CustomConcurrentHashMap.java:2806)
at com.google.common.collect.CustomConcurrentHashMap$Segment.put(CustomConcurrentHashMap.java:2374)
at com.google.common.collect.CustomConcurrentHashMap.put(CustomConcurrentHashMap.java:3346)
at my.app.cache.CacheImplGoogleGuava.put(CacheImplGoogleGuava.java:36)
...
What could be the reason?
--- Updated:
JBoss version is 5.
Setting a breakpoint in Throwable.initCause revealed ClassNotFoundException with message:
Invalid use of destroyed classloader for com.google.common.collect.Iterators, UCL destroyed at:
and with Stacktrace
ClassNotFoundException(Throwable).initCause(Throwable):320
UnifiedClassLoader3(RepositoryClassLoader).findClass(String):628
...
UnifiedClassLoader3(ClassLoader).loadClass(String):248
CustomConcurrentHashMap$2.iterator():828
CustomConcurrentHashMap$2(AbstractCollection<E>).remove(Object):241
CustomConcurrentHashMap$Segment.enqueueCleanup(...):2738
CustomConcurrentHashMap$Segment.unsetValue(...):2662
CustomConcurrentHashMap<K, V>.reclaimValue(...)
CustomConcurrentHashMap$SoftValueReference<K, V>.finalizeReferent():1637
...
Method.invoke:574
Finalizer.claenUp:154
Finalizer.run:127
From the stacktrace, it seems as if an object in the map was finalized where in finalizeReferent the class com.google.common.collect.Iterators cannot be loaded.
Your problem seems to be unrelated to MapMaker or Guava in general.
You only see an exception that happens while handling another exception (unfortunately).
Throwable.initCause() throws an exception when it's called while there was already a cause specified for the current Throwable (either via the method or the constructor`.
The RepositoryClassLoader.findClass() method seems to be handling some exception that it expects not to have a cause, but in fact it already has a cause set, which triggers this exception.
Unfortunately the exception you see here hides the actual exception (which would probably be much more important for solving the problem).
Try to put a breakpoit at Throwable.initCause() at line 320 or at RepositoryClassLoader.findClass() (at line 624) and reproduce the problem to (hopefully) see the "real" exception in the local variables view of your IDE.
This seems to be a known JBoss bug that might have already been resolved in new versions of the platform. Here is at least one similar bug:
JBREM-552: cannot init cause of ClassCastException
You might try upgrading your version of JBoss (though this particular bug implies the fix was in 2006) or filing another bug if your version is up to date. It could be the fix was sloppy and only fixed the one case that the author of that bug reported, and not similar cases.