BGS5T Exception in thread | Telit Cinterion IoT Developer Community
February 10, 2015 - 3:27pm, 10946 views
While running my midlet I get exception which isn't caught by my try-catch block but by debuger. It says:Exception in thread "Object Server Connection - Handle JMX Notification Thread" java.util.ConcurrentModificationException
Problem is that midlet sometimes runs fine for 1 hour and sometimes I get this exception in few minutes of running. Is this fault of midlet or some module settings? My scfg is:
at^scfg?
at^scfg?
^SCFG: "Call/ECC","0"
^SCFG: "Gpio/mode/ASC1","std"
^SCFG: "Gpio/mode/DAI","gpio"
^SCFG: "Gpio/mode/DCD0","std"
^SCFG: "Gpio/mode/DSR0","std"
^SCFG: "Gpio/mode/DTR0","std"
^SCFG: "Gpio/mode/FSR","gpio"
^SCFG: "Gpio/mode/PULSE","gpio"
^SCFG: "Gpio/mode/PWM","gpio"
^SCFG: "Gpio/mode/RING0","std"
^SCFG: "Gpio/mode/SPI","rsv"
^SCFG: "Gpio/mode/SYNC","std"
^SCFG: "GPRS/AutoAttach","enabled"
^SCFG: "Ident/Manufacturer","Cinterion"
^SCFG: "Ident/Product","BGS5"
^SCFG: "MEopMode/SoR","on"
^SCFG: "MEShutdown/Fso","0"
^SCFG: "Radio/OutputPowerReduction","4"
^SCFG: "Serial/Interface/Allocation","1","1"
^SCFG: "Serial/USB/DDD","0","0","0409","1E2D","0059","Cinterion Wireless Modules","Cinterion BGx USB Com Port",""
^SCFG: "Tcp/IRT","3"
^SCFG: "Tcp/MR","10"
^SCFG: "Tcp/OT","6000"
^SCFG: "Tcp/WithURCs","on"
^SCFG: "Trace/Syslog/Otap","0"
^SCFG: "Userware/Autostart","1"
^SCFG: "Userware/Autostart/Delay","600"
^SCFG: "Userware/Passwd",
^SCFG: "Userware/Stdout","null",,,,"off"
^SCFG: "Userware/Watchdog","0"
^SCFG: "Radio/Band","15"
Once I also caught SCTM_B -1 event with this:
else if(Event.indexOf("^SCTM_B") == -1)
{
sendSMS("Temperature is " + temperature + " and is reaching it's minimal limits.");
destroyApp(true);
}
Which is weird because there is no way that temperature would be at 0 C.
No I got SMS from device again, that temperature is reaching it's minimal limits, but temperature was 34 C.
Hello,
The exception is rather not connected with the module configuration.
It suggests problem with your application - it's possible that two threads are modifying the same object at the same time which is not allowed for this particular object.
I'd also try to run the MIDlet manually without the debugger and check if this exception also occurs.
Please also check the condition for catching temperature URC's.
It seems that in the condition "Event.indexOf("^SCTM_B") == -1" you check if the event does not contain "^SCTM_B" string and then send SMS.
Best regards,
Bartłomiej
I can seend you my midlet privately, but there is quite a lot of code.
This should be the only middlet running, besides "a:/JRC-1.50.1.jad","Java Remote Control MIDlet Suite","Cinterion","1.50.1","1"
I tryed running midlet manualy without debuger and yestrday it worked from 4pm to 9am, but then affter the SCTM_B event problems apeared. After that module while running midlet woulden't detect any new SMS, and after not reciving sms and sending message trough RS232 it would crash. But after some offline time module would be working normal again.
"Object Server Connection - Handle JMX Notification Thread" - could be because of some problem with usb port. But I can't explain the other problem with ^SCTM_B event.
Here is my ATEvent listener:
private class Listener implements ATCommandListener {
public void ATEvent(String Event) {
System.out.println("ATEvent " + Event);
// search for SMS related URCs
if (Event.indexOf("+CMTI") > 0)
{ //oznaka za prejet SMS
smsRecived = Event;
}
else if(Event.indexOf("^SCTM_B") == 1)
{
sendSMS("Temperature is " + temperature + " and is reaching it's upper limits");
}
else if(Event.indexOf("^SCTM_B") == 2)
{
sendSMS("Temperature is " + temperature + " and above it's limits. Module will shutdown.");
destroyApp(true);
}
else if(Event.indexOf("^SCTM_B") == -1)
{
sendSMS("Temperature is " + temperature + " and is reaching it's minimal limits.");
destroyApp(true);
}
else if(Event.indexOf("^SCTM_B") == -2)
{
sendSMS("Temperature is " + temperature + " and below it's limits. Module will shutdown.");
destroyApp(true);
}
else if(Event.indexOf("^SCTM_B") == 0)
{
sendSMS("Temperature is " + temperature + " and is back to it's limit");
destroyApp(true);
}
}
public void RINGChanged(boolean SignalState) {
System.out.println("RINGChanged " + SignalState);
}
public void DCDChanged(boolean SignalState) {
System.out.println("DCDChanged " + SignalState);
}
public void DSRChanged(boolean SignalState) {
System.out.println("DSRChanged " + SignalState);
}
public void CONNChanged(boolean SignalState) {
System.out.println("CONNChanged " + SignalState);
}
}
If you want I can seend you my whole project but there is more then 1000 lines.
Regards
Jure
I had same program on 2 BGS5T from yesterday 4pm to today 8am. Number 1 was in the box where it will turn on and off compressor and fan, Number 2 was on the proto board. They started running almost at the same time and they both had the same program, regime and received each SMS orders.
From number 1, I got last feedback at 16.48 and at 17.48 it already didn't respond. Number 2 still works.
I have setting that it should restart to 3 ***** if program crashes, but this didn't happen. State on the GPIO was like it was in last iteration of program. So the compressor that was turning on and off every 25 seconds was working whole night.
Most of the program is inside try-catch which reports SMS errors but this didn’t happen. I also have SMS after 2 min that module is online, but I also didn’t receive that, so it looks like that it never got restarted.
Hello Jure,
It's hard to guess where this "Object Server Connection - Handle JMX Notification Thread" comes from. Do you use any additional API's?
Regarding the problem with SMS'es and crashes - maybe there is some dead lock while accessing the AT interface by more than one thread.
Make sure that you always add '\r' while sending AT commands. Also check if your application is deleting the received SMS'es to make the room for the new ones.
I can also see the problem in the Listener class - the received String Event is checked with indexOf() method if it equals from -2 to 2. This method returns the index of the first character of the first such substring if it is found or -1 if not.
So for instance in this part:
else if(Event.indexOf("^SCTM_B") == -1)
{
sendSMS("Temperature is " + temperature + " and is reaching it's minimal limits.");
destroyApp(true);
}
if the substring "^SCTM_B" is not a part of the received Event the SMS is sent and the application is destroyed.
Do you have any log from your application?
I think that it would be good to add some system.out's to trace on the console what the application is doing if you haven't done it already.
You can send me your project - maybe I'll be able to send you some hints.
Regards,
Bartłomiej
"Object Server Connection - Handle JMX Notification Thread" is probably from bad USB Port, not 100% sure.
But the biggest problem are crashes and SMS'es not beeing delivered.
I delete all SMS'es that i recive. I found one of the problems for that and made a new thread so that is a little bit more organized. When program crashed in yestrday testing trough the night, I didn't get any SMS so it wasn't URC that caused it. I will send you my project trough mail.
I was using system.out to debuger, but I have seen nothing special. I will try to write it to file.
What would be correct way to listen for SCTM_B URC's?
Regards,
Jure
Made another test trough the night with 2 modules. First they were in garage where 1 module had about 10 C temperature. I started getting some weird errors, to see what is wrong I moved them to my room, where they started working normaly.
Error report is in attachemnt:
Regards Jure
EDIT: I forgot to add to report, that few ***** I got this:
MIDlet:Main exited
Hello Jure,
I've seen your application. I didn't try to build and run it, just went through the code.
I've got a few hints. Hope that would be helpful.
I think you should not send SMS in every catch block. In some error situations it can even not be possible. Especially in the sms sending method where it can cause the endless loop. The application may be sending big amount of messages and you have not guarantee that all will be successfully sent and received.
Instead you should add printStackTrace() method and some descriptive debug information that would help you to diagnose the problem.
Maybe I'd also add more debug prints in the code that would help you to analyse what the application was doing before the problem occured.
It would be easier to read, develop and maintain your application if you create more specialized classes dedicated for certain functionalities eg. time management, hardware interactions, gpio, serial, sms etc.
I can see in your log that in most cases the application is throwing java.lang.NullPointerException, java.lang.StringIndexOutOfBoundsException and java.lang.NullPointerException which are all unchecked exceptions which means that the API doesn't force you to catch them and normally you should not do that because they are a result of a programming problem, and as such, the application code cannot reasonably be expected to recover from them or to handle them in any way.
So to not get NullPointerException your code must ensure that all references are initialized and check (where it's needed) if the reference is not null just not to call some object's method on the null reference.
You get NullPointerException probably when you convert a String to number, possibly the AT command response or some value received on RS connection. The application should be ready that the AT command may return ERROR or some other unexpected reply.
There is probably the similar reason for StringIndexOutOfBoundsException - you parse some string which is probably different the the application expects.
I have found one more thing in the log: IllegalStateException: openATCommand: no channel available. This can be thrown when no more AT channel is available. There are limited number of ATCommand instances you can create. When your MIDlet crashes or is stopped without releasing the used ATCommand instances and is restarted without module reboot the amount of available instances decreases. But I can see that you are releasing of used instance in the destroyApp() method. Maybe the app was crashing and restarting too fast.
As for SCTM URC's the condition Event.indexOf("^SCTM_B") > -1 will provide you the information if this "^SCTM_B" string is a part of Event String. And if so you should parse it to get the number. You can try something like this:
Event.substring(Event.indexOf("^SCTM_B:") + "^SCTM_B:".length()).trim();
The "MIDlet:Main exited" string is printed when the application exits - there are many calls to destroyApp() inside your application.
Best regards,
Bartłomiej
Hello Bartłomiej,
thank your for your detailed response. I already added system.out where I had SMS for reporting problems and changed that once application goes to destroyApp() that restarts modem so that can't get stuck in loop.
I have SMS at every catch block because user ***** to be notified if something goes wrong. Even if most of them don't even get called. I will add printStackTrace() and added more debug messages.
This is my first gemalto application and in the beginning I thought that it will be much shorter. So I totally agree that I should split code in to more classes.
I have solved the java.lang.NumberFormatException. Don't know why it started showing yesterday, because I didn't change any code part in that area, but I had to change that function and while doing that I solved that problem.
openATCommand: no channel available was because application didn't closed like intended, but that is also fixed now.
With you telling me problem in sctm_B and disabling it that doesn't appear anymore. I will implement this event back later. Solving SMS UCR in other thread, I know only have to find why whole thing freezes sometimes. I will add more debug msg's and printStackTrace() and hopefully I will catch the problem.
Thank you again for all your answers.
Best reagards
Jure
I ran it through the weekend, unfortunately I didn't catch anything because computer restarted because of windows update.
But what is weird to me is that it looks like module hangs or freezes. GPIO weren't changing, if programs crashes and restarts they would change. RS232 commands were unresponsive and when I connected with USB and tried AT commands I didn't get any response and as I understand they should work since they work separately from Java code.
I will try again to catch in the logs what actuality happens or where does it stops.
Best regards
Jure
Pages