I have a Java remote Thing (Thingworx Java SDK version 6.0.2 367 Build).
This remote thing is connected and functions as expected. The remote thing client portion is built off of the sample code that was provided with the SDK download.
There is a mashup the runs the service defined in the Java code.
I also have a subscription that is triggered off of a Scheduler Thing.
The subscription runs a local service that calls the remote service and continues based off of the successful completion of the remote service.
This set up will run for months, sometimes weeks without issue. When it gets stuck I get this error:
JavaException: com.thingworx.dsl.exceptions.DSLRequestProcessingException: Execution error in service script [Type.Thing:Entity.ThingName.Scheduler:Event.ScheduledEvent] :: Wrapped com.thingworx.common.exceptions.GenericHTTPException (GenerateAll#18)
When it happens, I shut down the Remote thing and restart it and it goes back to working.
Has anyone come across this error before? Any ideas on what could be causing this issue?
Not sure if this was solved in an update. But wanted to check before reworking my program.
I have not seen this error before previously but would be interested in seeing the service code of the service that is mentioned in the error along with the ApplicationLog and ErrorLog following reproduction of the issue. To gather further diagnostics please check off "Enable Stack Tracing" on the Configuration tab of the LoggingSubsystem entity from within Composer. This will output the complete error stack within the ErrorLog.
I have attached the Thingworx service that makes the call to the remote service.
When the error comes up, it always shows line #18 is the issue. Which is the line that calls the remote service.
I do have logging set up for the remote thing and I get the error:
But like I said before, once I restart the remote thing and run the same example. It works fine.
As for the stack trace, I'm not sure how to handle that, since I imagine that would grow fairly large. Since I can't pin down when it does happen, I wouldn't want to leave that on there too long. Is there another suggestion for that?
We may need to move this into a Technical Support case but before we proceed with that we should gather the necessary ErrorLog with Stack Tracing enabled.
Having Stack Tracing enabled in the ErrorLog should not to be confused with generating thread dumps from the ThingWorx Platform. Checking the "Enable Stack Tracing" checkbox simply prints out the full error stack into the ErrorLog.log when an error is encountered on the system. This will not add much bulk to your ErrorLog unless the system is constantly throwing errors of some kind.