Error codes for the MIDP implementation used by Gemalto | Thales IoT Developer Community
April 16, 2018 - 3:29pm, 5561 views
Hi,
I've been using a BGS5 for a while now. Overall, the GSM/GPRS connection capabilities are operating fine, using javax.microedition.io.Connector.open(). Occassionaly, I would get an error such as the following (where the APN has not changed, and the connection was previously operating correctly):
javax.microedition.io.ConnectionNotFoundException-ConnectionNotFound error in socket::open : error = 10012
I was wondering if there is a resource out there that documents what the meaning behind the codes for connection errors are. I have not just encountered 10012 but also others (-121, -143).
Kind regards,
Martijn
Hi,
10012 error is caused by socket:: write operation fail, one typical reason is send buff is full caused by out of memory.
121 Software caused connection abort.
143 Protocol not supported.
Regards
ALopez
Somewhere over the rainbow!!! Looking for the Oz Land!!!
Interesting, I also see the 10012 error for socket :: open (as indicated in the initial message I sent). The 10012 error for socket:: open is indeed preceeded by a socket :: write command that has the same error. After that, the 10012-error keeps occurring for about 25 minutes, while the application keeps trying to open the connection again every 15 seconds. Only after 25 minutes does it actually succeed in opening.
Is there anything I can do to prevent the error from surfacing during socket::open and/or socket::write from the java-end of the things?
Hi,
Have you implemented the gc() call to clean the not used object and compact the memory?
Regards
ALopez
Somewhere over the rainbow!!! Looking for the Oz Land!!!
I haven't but would think a gc call would not be required in typical usage scenarios. Plus, there is a lot of other stuff going along concurrently with the writing to the outputstream of the Connection object. Those threads would also be affected by this memory related problem, if it would be a 'true' memory related problem.
Note that I am taking care of calling close() on all related items, the SocketConnection, InputStream and OutputStream every time a connection related Exception occurs.
Not really sure on what to do here. Is it possible to take a look at the J2ME/CLDC/MIDP implementation that is used by the BGS5 module?
Hi,
Are you able to reproduce this issue with the simple MIDlet, e.g. connectong several ***** to the server, without doing any more activities in the background, so we could also reproduce that with this code?
Best regards,
Michał
Sadly enough, this only happens when the devices are with customers. I am not able to reproduce this on the bench..
I Will check whether we can get any more info about this "10012" internally. Will get back to you.
Best regards,
Michał
Hi Martijn,
I have found that 121 error may be often related with the poor network condition, or because of unknown reason network could not realize the connection.
About 10012 I have found only one report so far. It was related with connecting to http and driving GPIO at the same moment. It may sound strange, but it seems there might be some unintended influence between them. Are you using GPIO in your app? Perhaps this could be a good workaround for the moment to synchronize the GPIO usage with the tcp usage? Unfortunately mentioned report was a very specific scenario and reported only once, so I don't expect the deep analyse on that soon. It has rather low priority.
Btw. Which FW do you use? Have you try to take the latest one and see if the issue will appear again?
Best regards,
Michał
Thanks for doing the search!
The BGS5 I am using is maintained by a seperate company that provides additional hardware services (CAN, GPS, OneWire, I2C, etc), and has their own firmware build on top of the BGS5. I have strong suspicions they are using GPIO ports. I will relay the question to them. They are also aware of which Gemalto firmware is in the device. I only know which version of their firmware I am using.
Note that I am not using HTTP, but have some heavy use of TCP.