Re: [DISCUSSION] Delayed message delivery

> So rather than specifying the absolute timestamp that the message > should appear to the user, the dispatcher can specify the relative > delay after dispatch that it should appear to the user. As matteo said the worst case would be that the applied delay to be higher for some of the messages, if

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

See Changes: [guosijie] Java Client - Prevent printing authentication data in INFO logs. (#3377) -- [...truncated 990.64 KB...] Extracting: '/website/translated_docs/

Re: [DISCUSSION] Delayed message delivery

Hi All! and sorry for delay :) Probably I'm going to say some things already said, so sorry beforehand. The two main needed features I think are the proposed: A. Producer delay PIP-26. B. Consumers delay PR #3155 Of course PIP-26 would result in consumers receiving delayed messages but the impor

Re: [DISCUSSION] Delayed message delivery

Trying to group and compress responses here. > If consumer control the delayed message specific execution time we must trust clock of consumer, this can cause delayed message process ahead of time, some applications cannot tolerate this condition. This is a problem that cannot be solved. Even ass

Re: [DISCUSSION] Delayed message delivery

On Sat, Jan 19, 2019 at 9:45 AM Matteo Merli wrote: > Trying to group and compress responses here. > > > If consumer control the delayed message specific execution time we must > trust clock of consumer, this can cause delayed message process ahead of > time, some applications cannot tolerate thi

Re: [DISCUSSION] Delayed message delivery

Just a quick correction: > And I don’t see anyone have a clear explanation on why a broker approach is less scalable than the client side approach. I haven't said it less or more scalable. I was meaning that it's "easier" to scale, in that we don't have to do lots of fancy stuff and add more and