Problem with multiple HttpConnections EHS6 | Telit Cinterion IoT Developer Community
August 5, 2015 - 8:49am, 3799 views
Hello,
I am using a EHS6 USB terminal to act as a platform for a Internet of Things client. This involves sending measurement data to IoT server in regular intervals.
My problem is that after exactly 8 ***** of opening and closing an HttpConnection, the next Connector.open() throws an IOException: IOError in socket::open: -137.
Any ideas what might be causing this? I'm thinking it might be something related to Java security and MIDlet restrictions (preventing them from racking up your phone bill) but so far I've found no solutions. Restarting the MIDlet works, but as far as I know there's no way to automatically restart unless the MIDlet shuts down ungracefully due to an unhandled exception.
Hello,
How often do you open and close the connections? How many connection are used at a time? Do you have a server on the module or only connect as a client?
The number of sockets that can be used simultaneously should be kept low due to resources and performance reasons.
According to the documentation it may take 60 seconds to cleanup after the closed connection.
Maybe you don't close the connections properly.
If the measurements are sent very frequently maybe it would be better to keep the connection open instead of closing it and opening for each measurement.
I don't think that restarting the MIDlet is a good solution but it should be possible - you would need to restart the whole module.
Please also send the ATI1 and AT^SCFG? replies.
Best regards,
Bartłomiej
There's only one connection used at any time. It is opened, configured, posted (HTTP POST) and closed right after receiving the response. Input/output streams are also closed before closing the HttpConnection.
A http request-response transaction is used for sending the measurement data because that's the way our IoT server handles them, so I don't think keeping an open connection is possible.
ATI1:
ati1
Cinterion
EHS6
REVISION 02.000
A-REVISION 00.000.15
OK
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/HSIC","rsv"
^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","EHS6"
^SCFG: "MEopMode/SoR","off"
^SCFG: "MEShutdown/Fso","0"
^SCFG: "Radio/Band","511"
^SCFG: "Radio/OutputPowerReduction","4"
^SCFG: "Serial/Interface/Allocation","1","1"
^SCFG: "Serial/USB/DDD","0","0","0409","1E2D","0058","Cinterion Wireless Modules","EHx",""
^SCFG: "Tcp/IRT","30"
^SCFG: "Tcp/MR","10"
^SCFG: "Tcp/OT","10"
^SCFG: "Tcp/WithURCs","on"
^SCFG: "Trace/Syslog/Otap","0"
^SCFG: "Userware/Autostart","0"
^SCFG: "Userware/Autostart/Delay","60"
^SCFG: "Userware/DebugInterface","192.168.244.1","192.168.244.2","0"
^SCFG: "Userware/DebugMode","on"
^SCFG: "Userware/Passwd",
^SCFG: "Userware/Stdout","usb1",,,,"off"
^SCFG: "Userware/Watchdog","0"
OK
Could you also write about the frequency of opening and closing the connections?
There's an update for your firmware but I don't think that this could matter here.
I can see in the AT^SCFG? output that global autostart setting is deactivated. This should not be done without purpose because in such a case the factory JRC MIDlet will also not be started automatically. And this MIDlet implements some of the module's functionalities, so the module may not work correctly.
There's a Thread.sleep between connections in which I have tried values between 1000-60000 (1-60 seconds) but it always stops at the 9th Connector.open() and throws the exception I mentioned in my first post.
I've turned off the autostart manually in order to prevent my MIDlet from starting for now because I wanted to test it without the emulator. Nothing changed, though.
Hello,
So it seems that this is not the resources problem.
Could you write how long is the connection established before closing. And what happens after this problem occurs - is the application still working (are any other threads working fine) or does the app hang? Is the application trying to establish another connections?
Please also try to add 100ms sleep before you close the streams and connection.
Regards,
Bartłomiej
Hello Bartłomiej,
The connection usually lasted around 2-5 seconds. After the exception was thrown, the program exited gracefully (I had caught the exception). It's a very simple program so there is only one thread running at a time.
I added a 100ms sleep before closing the streams and connection and it works like a charm now. Thank you for your help.
I wonder what caused this.
Hello,
Great! I'm happy that it's working now!
So the connections are really short.
I've found the records for similar problem. This solution was found then and tested to be helpful.
Best regards,
Bartłomiej