Dissem/Abit

Having multiple issues while sending a message

Closed this issue · 5 comments

I cloned Abit and used Jabit from the develop branch in it because I needed the channel functionality. So, when I try to send message from this app on full node I basically end on one of these scenarios:

  1. The app get stuck at "Doing Proof of Work(1 queued)" with no further development with message not received to the recipient. I had to manually stop this proof of work because the device was burning up and there was no sign of it ever completing. Sometimes the count of proof of work increases like "Doing Proof of Work(4 queued)".
  2. The proof of completes but the message is never received on the recepient.
  3. App crashes with runtime exception. (Sorry, I don't have the stacktrace at the moment, but I will make it available to you if this happens again). The exception is thrown at Line 72:AndroidProofOfWorkRepository.java

I have tried to reduce the complexity of the proof of work by TTL.msg(UnixTime.HOUR) with no effect. I also tried to check if the device is able to receive messages and there was no problem there. The proof of work required to send the public key was completed rather quickly and the message was received successfully. The public key TTL was set to 2 days through pubkeyTTL(2 * UnixTime.DAY).

I quickly looked into the code, and although it makes sense in regard of this error, I don't see how this line could cause an exception. Hopefully a stack trace will help me get to the bottom of this.

I just pushed a commit that might help you (albeit not on this specific issue), as it adds chan support to the AndroidAddressRepository

As I mentioned, I will make stacktrace available to you if another same exception is thrown again. Also, I had already added the code for the AndroidAddressRepository which you incorporated in your latest commit. In the meantime any ideas on the issues I mentioned in the first two points? I have also attached an image which showcase this issue. I forgot to add it in my previous post.
screenshot_20160424-192743

Ok, So here's the stacktrace for the exception. Hope this is helpful.

FATAL EXCEPTION: Thread-2187
      Process: ch.dissem.apps.abit, PID: 5464
      java.lang.RuntimeException: Object requested that we don't have. Initial hash: 75d718c5128b486f5f3018b8b3aba113c8180a1ef777bef014abc4d87782161edfb95f4751bb11442987c33984a295f30963421ae28c9f85e6ecc7e889fce255
      at ch.dissem.apps.abit.repository.AndroidProofOfWorkRepository.getItem(AndroidProofOfWorkRepository.java:72)
      at ch.dissem.bitmessage.ProofOfWorkService.onNonceCalculated(ProofOfWorkService.java:64)
      at ch.dissem.apps.abit.service.ProofOfWorkService$1.onNonceCalculated(ProofOfWorkService.java:87)
      at ch.dissem.bitmessage.ports.MultiThreadedPOWEngine$CallbackWrapper.onNonceCalculated(MultiThreadedPOWEngine.java:137)
      at ch.dissem.bitmessage.ports.MultiThreadedPOWEngine$Worker.run(MultiThreadedPOWEngine.java:110)

From the error and your description of the behaviour I expect the following to happen:

  • POW for the same message gets calculated over and over, resulting in the above error after the second run.
  • The POW request either doesn't get removed from the queue (during poll) or added again.

Unfortunately I couldn't reproduce the problem and couldn't find out why this might happen. Unfortunately the notification showed "1 queued" both when 1 POW item was queued and when only one was being processed, without any queued items. This is now fixed.

I fear the whole POW mechanism could use some improvements - for example the semaphore thing is overly complicated and therefore error prone. I think that's what I will look at next, maybe I'll discover something that helps with this issue.

I changed the MultiThreadedPOWEngine to be simpler and therefore less error prone. A quick test suggests that POW might be more reliable, but I'm not sure if it really fixes your problem.

The updated version is available as a snapshot build on maven central, but please note that updating snapshot dependencies within Android Studio are a bit tricky. I got the most reliable results by deleting the corresponding caches (~/.gradle/caches/modules-2/ files & metadata*/descriptors ch.dissem.jabit), refreshing gradle projects and then still restarting Android Studio.