eolivelli commented on issue #13490: URL: https://github.com/apache/pulsar/issues/13490#issuecomment-1018354788
we talked in the Community meeting about this PIP. The main concern from @merlimat is the exposing a "put" operation will give a false illusion that you have something like a Map, but actually every "write" operation will be "slow" because we need to acquire the Producer lock. @merlimat suggested to split this into two distinct interfaces: a API for readers and one for writers, possibly extending the work done on PIP-104 TableViews (https://github.com/apache/pulsar/issues/12356). I am fine with extending PIP-104 in that direction (to add a writer side of the TableView), but I believe that the API proposed here is going to give a API to achieve the goal of having a generic "Java object" as share state, by letting the developer of the Shared State Object deal with the internal representation. Using the TableView API will forces users to represent their Java object as a set of properties or a single object with one fixed key. It is feasible, but not straightforward from my point of view. I really would like to mimic Pravega.io StateSynchronizer support, that does not force you to see your topic as a "table". @merlimat I will work in parallel on extending the TableView API to add writer support, I am sure it will bring a big value to the users. But I still thing that we should add this "Recipe" to the Pulsar Adapters repository @merlimat WDTY ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
