[
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)
