A throwReadOnlyException is seen when attempting to modify a read-only tuple in a Custom Java Operator that uses code like the following:

public void processTuple(int inputPort, Tuple tuple) throws StreamBaseException {
String latencyTag = tagging.getTagAsString();
tuple.setString(latencyTagField, latencyTag); // pass through input tuple to single output port
sendOutput(0, tuple);
}

The resulting exception is:

java.lang.UnsupportedOperationException: attempting to modify a read-only tuple
at com.streambase.sb.ReadOnlyTuple.throwReadOnlyException
at com.streambase.sb.ReadOnlyTuple.setStringImpl
...

 

To facilitate platform performance improvements it is no longer guaranteed that the tuple coming into a Custom Operator is writeable. Instead, use this pattern:

public void processTuple(int inputPort, Tuple tuple) throws StreamBaseException {
Tuple outputTuple = null;
try {
outputTuple = tuple.clone();
String latencyTag = tagging.getTagAsString();
outputTuple.setString(latencyTagField, latencyTag);
sendOutput(0, outputTuple);
} catch (CloneNotSupportedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}

This matches our Engineering practice and will work in all contexts. 

In addition to new methods for the Long and Blob data types, and new methods for copy-free data access, the Tuple data type has new methods isReadOnly() and createWriteableTuple(). When dequeuing from StreamBase, the resulting tuples will be read-only, which allows a more efficient representation of tuple data. If a writable version of a tuple is required, createWritableTuple must be called. In addition, Tuple.clone() has new guarantees about copying all potentially-shared data when cloning. This is relevant to users of the new setBlobBuffer and setStringBuffer API methods.

In practice, in some contexts the tuples would remain writeable, but these contexts have become the exception.

A throwReadOnlyException is seen when attempting to modify a read-only tuple in a Custom Java Operator