Paho:Mqttv3 1.2.0: EOF Exception Connection lost

Below is the issue being faced,
Testing Scenario
Checking for continuous connection from our application to mqtt broker by pinging every 5 sec.
Keep alive is set to 5 sec.
Two scenarios where i am facing the issue
1) Ping response is failed and i get the Connection lost when there is a token null or wakelock held and there is Failure message Below is the log

**Sending Ping at: 1529422551514
Failure. Release lock(MqttService.client.paho26505181302488):1529422551588org.eclipse.paho.client.mqttv3.MqttToken@937985d
Unregister alarmreceiver to MqttServicepaho26505181302488
MqttConnection:connectionLostTimed out waiting for a response from the server
Schedule next alarm at 1529422551738
Alarm scheule using setExactAndAllowWhileIdle while dosing 100
if autoreconnect
Connection lost to :Timed out waiting for a response from the server (32000)**

I understand the the above scenario that didnt get a response from server at correct time

2) There is Connection lost even when there is token recieved from the server and there is success message . Please see log below
****Sending Ping at: 1529305957809
Schedule next alarm at 1529305962819
Alarm scheule using setExactAndAllowWhileIdle while dosing 5000
Success. Release lock(MqttService.client.paho6333640400389):1529305957965
Unregister alarmreceiver to MqttServicepaho6333640400389
Schedule next alarm at 1529305966103
Alarm scheule using setExactAndAllowWhileIdle while dosing 100
Connection lost to :Connection lost (32109) - java.io.EOFException
Register alarmreceiver to MqttServiceMqttService.pingSender.paho6333640400389****

I am not able to understand reason for unregistering the alarmreciever even after success
Been working on it for past 7 weeks
Please help
Thanks,
Mamatha

Start by reproducing the reported keep-alive scenario with a five-second interval and compare the two log sequences. Trace the MqttService alarm receiver and ping sender around the successful token release and the subsequent EOFException. Done means the cause of the unexpected connection loss and alarm unregistering is established with a reliable reproduction.

Written by the indexing model from the issue text.