Allow share continuation after a server restart

[licaon-kter]

Hauk at ccf8503 (will try to update asap)

Right now the Android client will say "server not accessible" after a server restart. While the link will say "session expired".

Server side web server log shows that the client retries: "POST /api/post.php HTTP/1.1" 200 50 "-" "Hauk/1.6.1 Dalvik/2.1.0 (Linux; U; Android ; Device)" "-"

But on Android side, logcat says:

.http.ConnectionThread.doInBackground(ConnectionThread.java:91): [seq:2006177437] Setting connection parameters
.http.ConnectionThread.doInBackground(ConnectionThread.java:100): [seq:2006177437] Writing data to socket
.http.ConnectionThread.doInBackground(ConnectionThread.java:108): [seq:2006177437] Response code for request is 200
.http.ConnectionThread.doInBackground(ConnectionThread.java:117): [seq:2006177437] resp += "Session expired!"
.http.ConnectionThread.doInBackground(ConnectionThread.java:121): [seq:2006177437] Returning success response
.http.Packet$1.run(Packet.java:84): Received as response to packet Response{ex=null,data=[Sesiune expirată!],ver=1.6.1}
.service.LocationPushService$LocationUpdatePacketImpl.onSuccess(LocationPushService.java:319): Connection to the backend was restored.
.notify.HaukNotification.create(HaukNotification.java:86): Creating notification
.notify.SharingNotification.build(SharingNotification.java:58): Building sharing notification
.notify.HaukNotification.create(HaukNotification.java:95): Android version O+ detected; setting notification channel
.service.LocationPushService$LocationUpdatePacketImpl.onFailure(LocationPushService.java:327): Failed to push location update to server
info.varden.hauk.http.ServerException: Session expired!
     at info.varden.hauk.http.LocationUpdatePacket.onSuccess(LocationUpdatePacket.java:113)
     at info.varden.hauk.service.LocationPushService$LocationUpdatePacketImpl.onSuccess(LocationPushService.java:322)
     at info.varden.hauk.http.Packet$1.run(Packet.java:91)
     at info.varden.hauk.http.ConnectionThread.onPostExecute(ConnectionThread.java:143)
     at info.varden.hauk.http.ConnectionThread.onPostExecute(ConnectionThread.java:40)
     at android.os.AsyncTask.finish(AsyncTask.java:771)
     at android.os.AsyncTask.access$900(AsyncTask.java:199)
     at android.os.AsyncTask$InternalHandler.handleMessage(AsyncTask.java:788)
     at android.os.Handler.dispatchMessage(Handler.java:106)
     at android.os.Looper.loop(Looper.java:223)
     at android.app.ActivityThread.main(ActivityThread.java:7656)
     at java.lang.reflect.Method.invoke(Native Method)
     at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)
.service.LocationPushService$LocationUpdatePacketImpl.onFailure(LocationPushService.java:331): Connection to the backend was lost.

...so it's either "session expired" or "server not accessible"?

This is about memcache/redis being in memory only so once memcache is stopped the data is lost?

Ok so maybe https://github.com/meabed/memcached-php-backup-restore might help? Won't help if the restart is not controlled (eg. Power cut off)

But, this sounds rather odd, why is the client getting "session expired" when the client creates the sessions?

Is it expired? Great... then create it... isn't that what allow_link_req allows if TRUE?

Or maybe I should make a reserved_link instead?

[licaon-kter]

reserved_link does not help :(

[dereckson]

Ok so maybe https://github.com/meabed/memcached-php-backup-restore might help? Won't help if the restart is not controlled (eg. Power cut off)

You handle geolocation data, sensible from a privacy point of view. The privacy policy for the client explains "the Hauk backend will retain your location for as long as your location sharing session is active".

That would be false with your method: the file will persist data as long as it exists: if the service fails, and you don't debug it right now, one year later you still have retention of those location points.

For our instance, in the records of processing activities we explicitly note "Cache. The sensible geolocalisation part is never stored on disk, only on RAM through [...] memcached, configured to disable swap. Cache isn't exposed directly on Internet. Any deployment is automated and restart the services, destroying currently stored information."

Your feature would be convenient but a hell to manage from a privacy point of view.

Instead, what you can probably do is to switch the configuration to Redis, which allows persistence, and address the retention questions.

[licaon-kter]

@dereckson will try, this (and no autoreshare on device reboot) make usage a pain and users need to re-share if "conditions are not perfect"... and they never are...