Java threading issue with handler message data being overwritten by next message

Question

I have a thread reading data from a bluetooth stream that sends the data to a handler on the main UIThread as it comes in (based on the Bluetooth Chat Sample).

I've discovered a threading problem that pops up quite frequently. First, some code for reference.

BluetoothService.java (Just the part that reads the incomming data stream. It has been set up correctly before this code runs).

public void run() {
     DebugLog.i("BluetoothService", "BEGIN mConnectedThread");
     byte[] buffer = new byte[1024];
     int bytes;
         // Keep listening to the InputStream while connected
     while (true) {
          try {
             // Read from the InputStream
             bytes = mmInStream.read(buffer);

             DebugLog.d("BluetoothService", new String(buffer, 0, bytes));
             // Send the obtained bytes to the UI Activity
             mHandler.obtainMessage(MESSAGE_READ, bytes, -1, buffer)
                          .sendToTarget();
          } catch (IOException e) {
                DebugLog.e(TAG, "disconnected", e);
                connectionLost();
                break;
          }
     }
}

Handler defined in my main activity (partial):

// The Handler that gets information back from the BluetoothService
private final Handler mHandler = new Handler() {
    @Override
    public void handleMessage(Message msg) {
        switch (msg.what) {
          case BluetoothService.MESSAGE_READ:
            byte[] readBuf = (byte[]) msg.obj;
            // construct a string from the valid bytes in the buffer
       String readMessage = new String(readBuf, 0, msg.arg1);
       DebugLog.d("BluetoothHandler", readMessage);
       mConversationArrayAdapter.add(mConnectedDeviceName+":  " + readMessage);
                 break;

        }
    }
};

My problem comes when a small, continuous stream of data comes into the mmInStream. For example, 'abcd'. If 'abcd' is read all at once, this code functions normally and the log reads:

BluetoothService: BEGIN mConnectedThread
BluetoothService: abcd
BluetoothHandler: abcd

But if that continous block of data gets read in 2 parts, the second set of data overwrites the first set of data by the time it gets to the handler. Here's some example logs that I've seen.

BluetoothService: BEGIN mConnectedThread
BluetoothService: a
BluetoothService: bcd
BluetoothHandler: b
BluetoothHandler: bcd

Or:

BluetoothService: BEGIN mConnectedThread
BluetoothService: abc
BluetoothService: d
BluetoothHandler: dbc
BluetoothHandler: d

Or:

BluetoothService: BEGIN mConnectedThread
BluetoothService: ab
BluetoothService: cde
BluetoothHandler: cd
BluetoothHandler: cde

Notice that the second message that gets sent always overwrites the first message's data and only up to the shortest message's length. Also, both messages are always sent before the first message has been processed by mHandler.

I am guessing that I'm a common buffer somewhere is getting overwritten before the the first message is fully processed, but I don't see where. Any suggestions?

Answer 1

Is it possible that you have to use a second byte buffer when creating the message object?

mHandler.obtainMessage(MESSAGE_READ, bytes, -1, copyOfBuffer)

I have a suspicion that mHandler (although I don't know what it is) is keeping a reference to that byte array you send him.

Answer 2

I realize this is an OLD thread, but for posterity...

I just ran across this same issue. Coincidentally, it was also in code based on the google Bluetooth chat sample. My code also talks to a bluetooth device whose data appears in 'snippets' in the mmInStream.read(), resulting in many small messages sent to the handler.

Like the original poster, I found that the messages were being overwritten. I believe this is due to the android implementation of message handling as a light weight messaging mechanism. Specifically, .obtainMessage() allocates from a global pool of message structures to avoid runtime allocations. In keeping with this requirement, they DO NOT COPY THE DATA (/OBJECT) contained within the message, but simply maintain a pointer to the original data. Each message object contains the count of bytes in msg.arg1. In the sample code, if the data within the byte array ('buffer') is changed before the receiving handler has processed the message, the handler still has the original size of the message (contained in msg.arg1), but the buffer data has been updated (/overwritten).

I can see three ways to address this issue: 1. Use the android recommended mechanism (create a bundle of data, and use .setdata() to attach this to the message). I've not tried this, but I expect the bundle creation will result in the data being copied out of the buffer byte array. 2. use new memory for message data. This can be by run-time allocating (but that conflicts with the 'light weight' intention of messaging), or by using multiple statically allocated buffers, and cycling between them. Either approach has issues. 3. perform collection in the low-level thread 'run()', and only send a message for completed Bluetooth messages.

I opted for the third method. In my case, bluetooth messages contain terminated strings, so I use a string builder to collect bytes returned by mmInStream.read(), and only send a message to the handler when the end of line is detected.

Answer 3

A different way is to check if there is already any message with the same name in the Handler's queue with .hasMessages(). Example:

public void run() {
     DebugLog.i("BluetoothService", "BEGIN mConnectedThread");
     byte[] buffer = new byte[1024];
     int bytes;
         // Keep listening to the InputStream while connected
     while (true) {
          //Check if there is no pending similar message on the queue
          if (!mHandler.hasMessages(Constants.MESSAGE_READ)) {
              try {
                // Read from the InputStream
                bytes = mmInStream.read(buffer);

                DebugLog.d("BluetoothService", new String(buffer, 0, bytes));
                 // Send the obtained bytes to the UI Activity
                 mHandler.obtainMessage(MESSAGE_READ, bytes, -1, buffer)
                          .sendToTarget();
              } catch (IOException e) {
                    DebugLog.e(TAG, "disconnected", e);
                    connectionLost();
                    break;
              }
          }
     }
}