[ https://issues.apache.org/jira/browse/APEXCORE-668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pramod Immaneni reassigned APEXCORE-668: ---------------------------------------- Assignee: Pramod Immaneni > Remove CustomControlTuple type from Buffer Server > ------------------------------------------------- > > Key: APEXCORE-668 > URL: https://issues.apache.org/jira/browse/APEXCORE-668 > Project: Apache Apex Core > Issue Type: Improvement > Reporter: Bhupesh Chawda > Assignee: Pramod Immaneni > > Following argument made in favour of removing CustomControlTuple type from > Buffer server: > Regarding creating custom control tuple as a separate type in bufferserver: I > don't think that should be the case since currently this tuple is a > passthrough for bufferserver just like any data tuple and there is no action > bufferserver takes for this tuple. So why should it be a special type for > bufferserver? Window markers are different because bufferserver uses that > knowledge. As far as bufferserver is concerned this is just data and the > differentiation should be left to the payload. > This might mean adding a byte to the data payload to differentiate between > regular data or control tuple which either side, publisher and subscriber > understand, but bufferserver doesn't really care about it. > There is a performance argument to be made that an extra byte can be saved by > overloading the buffer server message type, but then we should support it > more explicitly. For example, you could say that the data tuple type has a > message type range from 0xf0-0xff, where the first four bits being all 1's > denotes it's a data tuple and the last four bits can be configured by the > publisher/subscriber to sub-differentiate the data type. This is just an > example, you could go with lesser number of bits. But the point is buffer > server will only check the first four bits in this case to determine it is a > data tuple and deal with it accordingly, there will be no control tuple > definition as far as bufferserver is concerned. -- This message was sent by Atlassian JIRA (v6.3.15#6346)