Re: [DISCUSSION] Creating new repository for node.js client

👍 On Sat, Mar 2, 2019 at 9:39 AM Nozomi Kurihara wrote: > > But the project doesn't seem to be a normal Github repo (e.g. there is > no issues tracker). I am wondering if we need to ask INFRA to enable them. > > > IMO JIRA integration is not mandatory at least for now. > > https://reference.apac

Build failed in Jenkins: pulsar-website-build #576

See Changes: [mmerli] Revert "Remove broker mode to handle persistent/non-persistent topics [mmerli] Use python 3.5 runtime and pulsar client (#3723) [mmerli] fix pulsar_message_set_replication_clusters (#37

Re: [DISCUSSION] Creating new repository for node.js client

Hi Nozomi, I meant Github Issues. I think both Issues and Wikis are disabled in the Github repo. I created an INFRA ticket to ask INFRA team to enable it - https://issues.apache.org/jira/browse/INFRA-17939 - Sijie On Sat, Mar 2, 2019 at 9:39 AM Nozomi Kurihara wrote: > > But the project doesn

Re: PIP-31: Add support for transactional messaging

Kafka's implementation is interleaving committed messages with uncommitted messages at storage. Personally I think it is a very ugly design and implementation. Pulsar is a segment centric system, where we have a shared segment storage - bookkeeper. I think a better direction is to leverage the seg

Re: PIP-31: Add support for transactional messaging

I agree we many want to review pravega's past efforts in this area also. https://github.com/pravega/pravega/blob/master/documentation/src/docs/transactions.md https://github.com/pravega/pravega/blob/master/client/src/main/java/io/pravega/client/stream/Transaction.java -Ali On Sat, Mar 2, 2019 at

Re: PIP-31: Add support for transactional messaging

Pravega's model is a better model than Kafka - it addressed the interleaving problems. However Pravega's model is based on a giant replicated log and rewrite the data to a second tiered storage for persistence, which basically re-implemented bookkeeper's logic in broker. A fundamental drawback of P

Re: [DISCUSSION] Creating new repository for node.js client

FYI. The Github Issues are enabled: https://github.com/apache/pulsar-client-node/issues - Sijie On Sat, Mar 2, 2019 at 5:18 PM Sijie Guo wrote: > Hi Nozomi, > > I meant Github Issues. I think both Issues and Wikis are disabled in the > Github repo. > > I created an INFRA ticket to ask INFRA te

Re: [DISCUSSION] Delayed message delivery

I am trying to draw a conclusion on this email thread. > Maybe some way to plug to the broker some logic without interfering with its core? > In our business fixed delay at consumer level regardless of any producer > configuration is a big win due to easy implementation and usage. Based on Ezequ

Re: [DISCUSSION] Delayed message delivery

Seems like we are implementing per message timers. Not aware of any log pub sub that does that expect rocketmq , not sure how performant that is. https://github.com/apache/rocketmq/blob/2b692c912d18c0f9889fd73358581bcccf37bbbe/store/src/main/java/org/apache/rocketmq/store/schedule/ScheduleMessageS

Re: PIP-31: Add support for transactional messaging

Hi - Is this a case where a Pulsar function base class for transactions would help? Regards, Dave Sent from my iPhone > On Mar 2, 2019, at 2:39 AM, Sijie Guo wrote: > > Pravega's model is a better model than Kafka - it addressed the > interleaving problems. However Pravega's model is based on

Re: PIP-31: Add support for transactional messaging

Dave, You mean implementing the transactions in pulsar function? - Sijie On Sun, Mar 3, 2019 at 1:52 AM Dave Fisher wrote: > Hi - > > Is this a case where a Pulsar function base class for transactions would > help? > > Regards, > Dave > > Sent from my iPhone > > > On Mar 2, 2019, at 2:39 AM, S

Re: PIP-31: Add support for transactional messaging

Once there's support for transactions in messaging API, there will be no need for a base class for functions. Rather a config option will allow to enable transactional mode. -- Matteo Merli On Sat, Mar 2, 2019 at 6:39 PM Sijie Guo wrote: > > Dave, > > You mean implementing the transactions in pu

Re: PIP-31: Add support for transactional messaging

Hi - > On Mar 2, 2019, at 6:39 PM, Sijie Guo wrote: > > Dave, > > You mean implementing the transactions in pulsar function? Yes, that way there is no additional broker overhead and whatever happens when a commit happens is under the control of those making the transaction. I’m not sure if i

Re: PIP-31: Add support for transactional messaging

Matteo, Dave, I think you are talking about different things. My comments to both: > Once there's support for transactions in messaging API, there will be > no need for a base class for functions. Rather a config option will > allow to enable transactional mode. Matteo, If I understand your comm