Question about problem running traccar en Amazon Ec2

Hello Anton,
I am trying to run traccar in an Amazon Ec2 instance (a plain Ubuntu Server 14.04) and I am having some problems, which maybe you can give me a hand.
I built and install the version from master and started normally. Then I changed the ip in the gps device (the one which worked on my local machine), and after a bit it connects to the server. Something like this:

2015-07-21 20:53:37 DEBUG: [C51DB510: 5001 < 200.81.38.23] HEX: 23232c696d65693a3335393731303034353933333536322c413b
2015-07-21 20:53:37 DEBUG: [C51DB510: 5001 > 200.81.38.23] HEX: 4c4f4144

oddly enough, the device never sends the second part of the handshake.

Then it happens that I get multiple instance of that kind of log:

2015-07-21 20:45:39  INFO: [AE0568E2] connected
2015-07-21 20:45:39 DEBUG: [AE0568E2: 5001 < 200.81.38.246] HEX: 23232c696d65693a3335393731303034353933333536322c413b
2015-07-21 20:45:39 DEBUG: [AE0568E2: 5001 > 200.81.38.246] HEX: 4c4f4144
2015-07-21 20:46:17  INFO: [0432AE5F] connected
2015-07-21 20:46:17 DEBUG: [0432AE5F: 5001 < 200.81.38.246] HEX: 23232c696d65693a3335393731303034353933333536322c413b
2015-07-21 20:46:17 DEBUG: [0432AE5F: 5001 > 200.81.38.246] HEX: 4c4f4144
2015-07-21 20:46:35  INFO: [3BCFB17B] connected
2015-07-21 20:46:35 DEBUG: [3BCFB17B: 5001 < 200.81.44.243] HEX: 23232c696d65693a3335393731303034353933333536322c413b
2015-07-21 20:46:35 DEBUG: [3BCFB17B: 5001 > 200.81.44.243] HEX: 4c4f4144

and from time to time I get "Connection timed out" error, with this stacktrace:

java.io.IOException: Connection timed out
    at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
    at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
    at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:218)
    at sun.nio.ch.IOUtil.read(IOUtil.java:186)
    at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:359)
    at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:64)
    at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:108)
    at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
    at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89)
    at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
    at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
    at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
    at java.lang.Thread.run(Thread.java:722)

or an error with "Connection reset by peer" with the same stacktrace as before.

Do you have any idea of what could be the problem? It seems the ports are correctly opened since the gps device can connect. It is the same port as I tested here (the default), so since it worked before I am guessing the network carrier is not blocking or idling the connection on that port.
So I am running out of ideas hehe

Any help is appreciated, thanks!

You might want to read following page (especially point 1):

https://www.traccar.org/ports-for-tk-gt-and-other-gps-devices/

As for connection timeout, where do you get this error? In the log file? Which one?

I did tried re sending the fix sms command but it didn't changed anything. It does try to restart the handshake around the interval I set in the fix command (some 30 seconds).
I am also pretty sure the imei is correct as it is the same gps device I used in the local tests. Also the protocol is gps103 (port 5001) which is the one working in the local tests.

I get the stacktrace in the logs/tracker-server.log . To get the stacktrace I added in MainEventHandler.exceptionCaught the line:

Log.getLogger().error("Exception", e.getCause());

Because the current log there only said "[channel] error caught". It was a quick hack in the hope that the stacktrace could give me more information.

The other strange thing I found is that even though the BaseProtocolDecoder.identify method is executed, when I try to send a command I always get an error with "The device is not registered on the server".

Well, I correct myself about the send command api, I was mistyping a new parameter.

I have one question, once a connection is stablished, shouldn't it always come from the same channel? Because the logs suggests that the channel always has a different id, is this expected or the gps device is always starting a new connection, and hence never finishing anything?

It should be the same id. If it's different, it means device re-connects all the time.

It turned out that the problem was on that direction (thanks!). Basically the problem was that the GPS device went crazy and reconnected all the time. It needed a harder reconfiguration than just the fix command (nofix, changed to SMS mode, back to GPRS mode, fix again). Probably because the GPS device is a cheap one :)

---

A little digression:

I think, and hope, that the GPS device went crazy because it was a couple of weeks trying to connect to a server which was not there.
But this makes me think that I might need to have some sort automatic check to see if any device has stopped reporting its position. So then it can try to fix it or at least let some human know that something must be done (like an alarm or something).

Maybe this should be something that runs inside traccar (since it will work with the position history). Is this something that you are interested in having inside traccar? Or perhaps traccar should have some sort of plugin API so it can be extended without modifying traccar but will allow developers to stay close to the current version of traccar without forking and coupling to anything.

What are your thoughts in this idea?

Thanks again for the help!

I have plans to implement notifications in one of the future versions. I agree that it's a good idea to have notification if device goes offline and stops sending data.