Re: A question about checkpointing
Hi Yi, I got it now, thanks for your help! Qi Shu > 在 2017年5月18日，05:22，Yi Pan 写道： > > Hi, Qi, > > This would depend on the following two factors: > # whether the send() is async or sync > # how do you handle the send failure > > If the send() is sync, you will always receive an exception in your > process() method when MessageCollector.send() is invoked. Hence, if your > code does not handle the exception, it would be thrown out to the RunLoop > and the whole container will fail. If your code captures the exception, it > is then up to your application logic to deal with the send failure (i.e. > user will need to choose either ignore the send failure and proceed, or > fail and stop). If you choose to not ignore the send failures, then in this > case, the checkpoint will not proceed beyond the input that caused the send > failures, and the container will restart with the previous checkpoint, > which does not cause data loss. > > If the send() is async, the commit procedure in RunLoop will make sure to > flush all pending sends before checkpointing. If the flush fails, the > exception will be thrown out and the container will fail. Hence, when > restarted, the container will repeat from the previous checkpoint (i.e. at > least once delivery still holds and no data loss). > > Hope the above answers your question. > > Thanks! > > -Yi > > On Thu, May 11, 2017 at 12:43 AM, 舒琦 wrote: > >> Hi Jagadish, >> >>I may not express my questions clearly. >> >>Here is what I want to know. When MessageCollector.send is called >> in process method, if sending fail and fail again, under this situation is >> it possible to cause data loss ( continue to fetch and process messages, >> but can’t send them out, at the same time offset is still forwarding and >> checkpointing ). >> >>Thanks very much. >> >> >> Qi Shu >> >>> 在 2017年5月11日，15:35，Jagadish Venkatraman 写道： >>> >>> Hi Qi, >>> > If one record can’t be sent out all the time, then the consumer >>> will still fetch messages or not, and what about the offset >> checkpointing? >>> >>> Polling / fetching messages from the consumer (in case of Kafka) happens >> in >>> a separate thread. >>> >>> Samza offers an at-least once processing guarantee with zero data loss. >>> >>> I'm not sure I understand your specific question about checkpointing? >>> >>> >>> On Thu, May 11, 2017 at 12:28 AM, 舒琦 wrote: >>> Hi, Below is the description about checkpointing. 『Checkpointing is guaranteed to only cover events that are fully processed. It happens only when there are no pending process()/processAsync() or WindowableTask.window() invocations. All preceding invocations happen-before checkpointing and checkpointing happens-before all subsequent invocations.』 If one record can’t be sent out all the time, then the consumer will still fetch messages or not, and what about the offset >> checkpointing? Thanks! Qi Shu >>> >>> >>> >>> >>> -- >>> Jagadish V, >>> Graduate Student, >>> Department of Computer Science, >>> Stanford University >> >>
[GitHub] samza pull request #194: SAMZA-1221, SAMZA-1101: Internal cleanup for High-L...
GitHub user prateekm opened a pull request: https://github.com/apache/samza/pull/194 SAMZA-1221, SAMZA-1101: Internal cleanup for High-Level API implementation. SAMZA-1221: Separated the OperatorSpec and MessageStream DAGs so that they're now duals of each other. Users interact with and construct the MessageStream DAG; we create and use the OperatorSpec DAG internally. Moved common OperatorSpec functionality (getId, getOpCode, getOpName etc.) to the OperatorSpec abstract base class. Added a new JoinOperatorSpec and PartialJoinOperatorImpls which are created from JoinOperatorSpec in OperatorGraphImpl. Added a new InputOperatorSpec and InputOperatorImpl (previously RootOperatorImpl). InputOperatorSpec is created when StreamGraph#getInputStream is called. SAMZA-1101: Added a new OutputOperatorSpec and OutputOperatorImpl for partitionBy and sendTo. These are Separate from SinkOperatorSpec for and SinkOperatorImpl for sink. We don't need to create a sinkFn for partitionBy and sendTo anymore. Updated most unit tests to use the new classes and avoid reflection. You can merge this pull request into a Git repository by running: $ git pull https://github.com/prateekm/samza internal-cleanup Alternatively you can review and apply these changes as the patch at: https://github.com/apache/samza/pull/194.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #194 commit 58ea09f21d3810b05acdea4c55cf254885e0e324 Author: Prateek Maheshwari Date: 2017-05-17T22:58:28Z Internal cleanup for High-Level API implementation. Separated the OperatorSpec and MessageStream DAGs so that they're now duals of each other. Users interact with and construct the MessageStream DAG; we create and use the OperatorSpec DAG internally. Moved common OperatorSpec functionality (getId, getOpCode, getOpName etc.) to the OperatorSpec abstract base class. New JoinOperatorSpec and PartialJoinOperatorImpls created from JoinOperatorSpec in OperatorGraphImpl. New InputOperatorSpec and InputOperatorImpl (previously RootOperatorImpl) created when StreamGraph#getInputStream is called. New OutputOperatorSpec and OutputOperatorImpl for partionBy and sendTo. These are Separate from SinkOperatorSpec for and SinkOperatorImpl for sink. Don't need to create a sinkFn for partitionBy and sendTo anymore. Updated most unit tests to use the new classes and avoid reflection. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: A question about checkpointing
Hi, Qi, This would depend on the following two factors: # whether the send() is async or sync # how do you handle the send failure If the send() is sync, you will always receive an exception in your process() method when MessageCollector.send() is invoked. Hence, if your code does not handle the exception, it would be thrown out to the RunLoop and the whole container will fail. If your code captures the exception, it is then up to your application logic to deal with the send failure (i.e. user will need to choose either ignore the send failure and proceed, or fail and stop). If you choose to not ignore the send failures, then in this case, the checkpoint will not proceed beyond the input that caused the send failures, and the container will restart with the previous checkpoint, which does not cause data loss. If the send() is async, the commit procedure in RunLoop will make sure to flush all pending sends before checkpointing. If the flush fails, the exception will be thrown out and the container will fail. Hence, when restarted, the container will repeat from the previous checkpoint (i.e. at least once delivery still holds and no data loss). Hope the above answers your question. Thanks! -Yi On Thu, May 11, 2017 at 12:43 AM, 舒琦 wrote: > Hi Jagadish, > > I may not express my questions clearly. > > Here is what I want to know. When MessageCollector.send is called > in process method, if sending fail and fail again, under this situation is > it possible to cause data loss ( continue to fetch and process messages, > but can’t send them out, at the same time offset is still forwarding and > checkpointing ). > > Thanks very much. > > > Qi Shu > > > 在 2017年5月11日，15:35，Jagadish Venkatraman 写道： > > > > Hi Qi, > > > >>>If one record can’t be sent out all the time, then the consumer > > will still fetch messages or not, and what about the offset > checkpointing? > > > > Polling / fetching messages from the consumer (in case of Kafka) happens > in > > a separate thread. > > > > Samza offers an at-least once processing guarantee with zero data loss. > > > > I'm not sure I understand your specific question about checkpointing? > > > > > > On Thu, May 11, 2017 at 12:28 AM, 舒琦 wrote: > > > >> Hi, > >> > >>Below is the description about checkpointing. > >> > >>『Checkpointing is guaranteed to only cover events that are fully > >> processed. It happens only when there are no pending > >> process()/processAsync() or WindowableTask.window() invocations. All > >> preceding invocations happen-before checkpointing and checkpointing > >> happens-before all subsequent invocations.』 > >> > >>If one record can’t be sent out all the time, then the consumer > >> will still fetch messages or not, and what about the offset > checkpointing? > >> > >>Thanks! > >> > >> > >> Qi Shu > > > > > > > > > > -- > > Jagadish V, > > Graduate Student, > > Department of Computer Science, > > Stanford University > >
Re: [VOTE] Apache Samza 0.13.0 RC0
Resent the CANCEL email, hopefully it makes it this time. - Prateek On Wed, May 17, 2017 at 2:08 PM, Navina Ramesh (Apache) wrote: > Prateek told me that he sent out a cancel email. It didn't reach the > mail-archive I think. Lately, we have this kind of issues where the emails > are not reaching our dev list. > > On Wed, May 17, 2017 at 2:06 PM, Yi Pan wrote: > > > Hi, all, > > > > Based on the conversation above, can we officially cancel this vote? > > > > Thanks! > > > > -Yi > > > > On Mon, May 15, 2017 at 9:31 AM, Ignacio Solis wrote: > > > > > Thanks! > > > > > > On Mon, May 15, 2017 at 8:00 AM, Navina Ramesh > > > wrote: > > > > I will try to get the patch out today. Work doesn't look trivial. I > am > > on > > > > it. > > > > > > > > Navina > > > > > > > > On May 14, 2017 23:10, "Ignacio Solis" wrote: > > > > > > > >> We should hold off until it is solved. How long will it take to fix > > > this? > > > >> > > > >> On Sun, May 14, 2017 at 10:13 PM, Navina Ramesh (Apache) > > > >> wrote: > > > >> > I just changed the status of this JIRA to "BLOCKER" - > > > >> > https://issues.apache.org/jira/browse/SAMZA-1128 > > > >> > > > > >> > This causes a bug in standalone deployment where any failure in > the > > > >> barrier > > > >> > protocol stops the scheduled executorservice. Unfortunately, > > > >> > CoordinationUtils creates its own scheduled executorservice, which > > is > > > >> > incorrect. Scheduled ExecutorService is meant to be the working > > queue > > > for > > > >> > the ZkJobCoordinator. This needs to be fixed. Bharath already ran > > into > > > >> this > > > >> > bug during testing on Friday. > > > >> > > > > >> > veto for this release candidate. > > > >> > > > > >> > @Prateek/Jagadish: > > > >> > I recommend sending a "non-vote, testing release candidate" for > this > > > >> > release until we complete all pending tasks (includes docs, tests > > > etc). > > > >> It > > > >> > will also be useful to share the pending tasks and their progress. > > In > > > >> case > > > >> > you have already shared it, I might have missed it since some > emails > > > are > > > >> > bouncing off my inbox. > > > >> > > > > >> > Thanks! > > > >> > Navina > > > >> > > > > >> > On Sun, May 14, 2017 at 1:30 PM, Boris S > wrote: > > > >> > > > > >> >> I think we need to add SAMZA-1286 and > > > >> >> SAMZA-1279 to the release . > > > >> >> > > > >> >> On Wed, May 10, 2017 at 7:51 PM, Jagadish Venkatraman < > > > >> jagad...@apache.org > > > >> >> > > > > >> >> wrote: > > > >> >> > > > >> >> > This is a call for a vote on a release of Apache Samza 0.13.0. > > > Thanks > > > >> to > > > >> >> > everyone who has contributed to this release. We are very glad > to > > > see > > > >> >> some > > > >> >> > new contributors and features in this release. > > > >> >> > > > > >> >> > The release candidate can be downloaded from here: > > > >> >> > http://home.apache.org/~jagadish/samza-0.13.0-rc0/ > > > >> >> > > > > >> >> > The release candidate is signed with pgp key AF81FFBF, which > can > > be > > > >> found > > > >> >> > on keyservers: > > > >> >> > http://pgp.mit.edu/pks/lookup?op=get&search=0xAF81FFBF > > > >> >> > > > > >> >> > The git tag is release-0.13.0-rc0 and signed with the same pgp > > key: > > > >> >> > https://git-wip-us.apache.org/repos/asf?p=samza.git;a=tag;h= > > > >> >> > refs/tags/release-0.13.0-rc0 > > > >> >> > > > > >> >> > Test binaries have been published to Maven's staging > repository, > > > and > > > >> are > > > >> >> > available here: > > > >> >> > https://repository.apache.org/content/repositories/ > > > >> orgapachesamza-1020 > > > >> >> > > > > >> >> > 127 issues were resolved for this release: > > > >> >> > https://issues.apache.org/jira/issues/?jql=project%20% > > > >> >> > 3D%20SAMZA%20AND%20fixVersion%20in%20(0.13%2C%200.13.0)% > > > >> >> > 20AND%20status%20in%20(Resolved%2C%20Closed) > > > >> >> > > > > >> >> > The vote will be open for 72 hours (ending at 8:00PM Saturday, > > > >> >> 05/13/2017). > > > >> >> > > > > >> >> > Please download the release candidate, check the > > hashes/signature, > > > >> build > > > >> >> it > > > >> >> > and test it, and then please vote: > > > >> >> > > > > >> >> > > > > >> >> > [ ] +1 approve > > > >> >> > > > > >> >> > [ ] +0 no opinion > > > >> >> > > > > >> >> > [ ] -1 disapprove (and reason why) > > > >> >> > > > > >> >> > > > > >> >> > +1 from my side for the release. > > > >> >> > > > > >> >> > Cheers! > > > >> >> > > > > >> >> > > > >> > > > >> > > > >> > > > >> -- > > > >> Nacho - Ignacio Solis - iso...@igso.net > > > >> > > > > > > > > > > > > -- > > > Nacho - Ignacio Solis - iso...@igso.net > > > > > >
Re: [VOTE] Apache Samza 0.13.0 RC0
Prateek told me that he sent out a cancel email. It didn't reach the mail-archive I think. Lately, we have this kind of issues where the emails are not reaching our dev list. On Wed, May 17, 2017 at 2:06 PM, Yi Pan wrote: > Hi, all, > > Based on the conversation above, can we officially cancel this vote? > > Thanks! > > -Yi > > On Mon, May 15, 2017 at 9:31 AM, Ignacio Solis wrote: > > > Thanks! > > > > On Mon, May 15, 2017 at 8:00 AM, Navina Ramesh > > wrote: > > > I will try to get the patch out today. Work doesn't look trivial. I am > on > > > it. > > > > > > Navina > > > > > > On May 14, 2017 23:10, "Ignacio Solis" wrote: > > > > > >> We should hold off until it is solved. How long will it take to fix > > this? > > >> > > >> On Sun, May 14, 2017 at 10:13 PM, Navina Ramesh (Apache) > > >> wrote: > > >> > I just changed the status of this JIRA to "BLOCKER" - > > >> > https://issues.apache.org/jira/browse/SAMZA-1128 > > >> > > > >> > This causes a bug in standalone deployment where any failure in the > > >> barrier > > >> > protocol stops the scheduled executorservice. Unfortunately, > > >> > CoordinationUtils creates its own scheduled executorservice, which > is > > >> > incorrect. Scheduled ExecutorService is meant to be the working > queue > > for > > >> > the ZkJobCoordinator. This needs to be fixed. Bharath already ran > into > > >> this > > >> > bug during testing on Friday. > > >> > > > >> > veto for this release candidate. > > >> > > > >> > @Prateek/Jagadish: > > >> > I recommend sending a "non-vote, testing release candidate" for this > > >> > release until we complete all pending tasks (includes docs, tests > > etc). > > >> It > > >> > will also be useful to share the pending tasks and their progress. > In > > >> case > > >> > you have already shared it, I might have missed it since some emails > > are > > >> > bouncing off my inbox. > > >> > > > >> > Thanks! > > >> > Navina > > >> > > > >> > On Sun, May 14, 2017 at 1:30 PM, Boris S wrote: > > >> > > > >> >> I think we need to add SAMZA-1286 and > > >> >> SAMZA-1279 to the release . > > >> >> > > >> >> On Wed, May 10, 2017 at 7:51 PM, Jagadish Venkatraman < > > >> jagad...@apache.org > > >> >> > > > >> >> wrote: > > >> >> > > >> >> > This is a call for a vote on a release of Apache Samza 0.13.0. > > Thanks > > >> to > > >> >> > everyone who has contributed to this release. We are very glad to > > see > > >> >> some > > >> >> > new contributors and features in this release. > > >> >> > > > >> >> > The release candidate can be downloaded from here: > > >> >> > http://home.apache.org/~jagadish/samza-0.13.0-rc0/ > > >> >> > > > >> >> > The release candidate is signed with pgp key AF81FFBF, which can > be > > >> found > > >> >> > on keyservers: > > >> >> > http://pgp.mit.edu/pks/lookup?op=get&search=0xAF81FFBF > > >> >> > > > >> >> > The git tag is release-0.13.0-rc0 and signed with the same pgp > key: > > >> >> > https://git-wip-us.apache.org/repos/asf?p=samza.git;a=tag;h= > > >> >> > refs/tags/release-0.13.0-rc0 > > >> >> > > > >> >> > Test binaries have been published to Maven's staging repository, > > and > > >> are > > >> >> > available here: > > >> >> > https://repository.apache.org/content/repositories/ > > >> orgapachesamza-1020 > > >> >> > > > >> >> > 127 issues were resolved for this release: > > >> >> > https://issues.apache.org/jira/issues/?jql=project%20% > > >> >> > 3D%20SAMZA%20AND%20fixVersion%20in%20(0.13%2C%200.13.0)% > > >> >> > 20AND%20status%20in%20(Resolved%2C%20Closed) > > >> >> > > > >> >> > The vote will be open for 72 hours (ending at 8:00PM Saturday, > > >> >> 05/13/2017). > > >> >> > > > >> >> > Please download the release candidate, check the > hashes/signature, > > >> build > > >> >> it > > >> >> > and test it, and then please vote: > > >> >> > > > >> >> > > > >> >> > [ ] +1 approve > > >> >> > > > >> >> > [ ] +0 no opinion > > >> >> > > > >> >> > [ ] -1 disapprove (and reason why) > > >> >> > > > >> >> > > > >> >> > +1 from my side for the release. > > >> >> > > > >> >> > Cheers! > > >> >> > > > >> >> > > >> > > >> > > >> > > >> -- > > >> Nacho - Ignacio Solis - iso...@igso.net > > >> > > > > > > > > -- > > Nacho - Ignacio Solis - iso...@igso.net > > >
Re: [VOTE] Apache Samza 0.13.0 RC0
Prateek told me that he sent out a cancel email. It didn't reach the mail-archive I think. Lately, we have this kind of issues where the emails are not reaching our dev list. On Wed, May 17, 2017 at 2:06 PM, Yi Pan wrote: > Hi, all, > > Based on the conversation above, can we officially cancel this vote? > > Thanks! > > -Yi > > On Mon, May 15, 2017 at 9:31 AM, Ignacio Solis wrote: > > > Thanks! > > > > On Mon, May 15, 2017 at 8:00 AM, Navina Ramesh > > wrote: > > > I will try to get the patch out today. Work doesn't look trivial. I am > on > > > it. > > > > > > Navina > > > > > > On May 14, 2017 23:10, "Ignacio Solis" wrote: > > > > > >> We should hold off until it is solved. How long will it take to fix > > this? > > >> > > >> On Sun, May 14, 2017 at 10:13 PM, Navina Ramesh (Apache) > > >> wrote: > > >> > I just changed the status of this JIRA to "BLOCKER" - > > >> > https://issues.apache.org/jira/browse/SAMZA-1128 > > >> > > > >> > This causes a bug in standalone deployment where any failure in the > > >> barrier > > >> > protocol stops the scheduled executorservice. Unfortunately, > > >> > CoordinationUtils creates its own scheduled executorservice, which > is > > >> > incorrect. Scheduled ExecutorService is meant to be the working > queue > > for > > >> > the ZkJobCoordinator. This needs to be fixed. Bharath already ran > into > > >> this > > >> > bug during testing on Friday. > > >> > > > >> > veto for this release candidate. > > >> > > > >> > @Prateek/Jagadish: > > >> > I recommend sending a "non-vote, testing release candidate" for this > > >> > release until we complete all pending tasks (includes docs, tests > > etc). > > >> It > > >> > will also be useful to share the pending tasks and their progress. > In > > >> case > > >> > you have already shared it, I might have missed it since some emails > > are > > >> > bouncing off my inbox. > > >> > > > >> > Thanks! > > >> > Navina > > >> > > > >> > On Sun, May 14, 2017 at 1:30 PM, Boris S wrote: > > >> > > > >> >> I think we need to add SAMZA-1286 and > > >> >> SAMZA-1279 to the release . > > >> >> > > >> >> On Wed, May 10, 2017 at 7:51 PM, Jagadish Venkatraman < > > >> jagad...@apache.org > > >> >> > > > >> >> wrote: > > >> >> > > >> >> > This is a call for a vote on a release of Apache Samza 0.13.0. > > Thanks > > >> to > > >> >> > everyone who has contributed to this release. We are very glad to > > see > > >> >> some > > >> >> > new contributors and features in this release. > > >> >> > > > >> >> > The release candidate can be downloaded from here: > > >> >> > http://home.apache.org/~jagadish/samza-0.13.0-rc0/ > > >> >> > > > >> >> > The release candidate is signed with pgp key AF81FFBF, which can > be > > >> found > > >> >> > on keyservers: > > >> >> > http://pgp.mit.edu/pks/lookup?op=get&search=0xAF81FFBF > > >> >> > > > >> >> > The git tag is release-0.13.0-rc0 and signed with the same pgp > key: > > >> >> > https://git-wip-us.apache.org/repos/asf?p=samza.git;a=tag;h= > > >> >> > refs/tags/release-0.13.0-rc0 > > >> >> > > > >> >> > Test binaries have been published to Maven's staging repository, > > and > > >> are > > >> >> > available here: > > >> >> > https://repository.apache.org/content/repositories/ > > >> orgapachesamza-1020 > > >> >> > > > >> >> > 127 issues were resolved for this release: > > >> >> > https://issues.apache.org/jira/issues/?jql=project%20% > > >> >> > 3D%20SAMZA%20AND%20fixVersion%20in%20(0.13%2C%200.13.0)% > > >> >> > 20AND%20status%20in%20(Resolved%2C%20Closed) > > >> >> > > > >> >> > The vote will be open for 72 hours (ending at 8:00PM Saturday, > > >> >> 05/13/2017). > > >> >> > > > >> >> > Please download the release candidate, check the > hashes/signature, > > >> build > > >> >> it > > >> >> > and test it, and then please vote: > > >> >> > > > >> >> > > > >> >> > [ ] +1 approve > > >> >> > > > >> >> > [ ] +0 no opinion > > >> >> > > > >> >> > [ ] -1 disapprove (and reason why) > > >> >> > > > >> >> > > > >> >> > +1 from my side for the release. > > >> >> > > > >> >> > Cheers! > > >> >> > > > >> >> > > >> > > >> > > >> > > >> -- > > >> Nacho - Ignacio Solis - iso...@igso.net > > >> > > > > > > > > -- > > Nacho - Ignacio Solis - iso...@igso.net > > > -- Navina R.
Re: [VOTE] Apache Samza 0.13.0 RC0
Hi, all, Based on the conversation above, can we officially cancel this vote? Thanks! -Yi On Mon, May 15, 2017 at 9:31 AM, Ignacio Solis wrote: > Thanks! > > On Mon, May 15, 2017 at 8:00 AM, Navina Ramesh > wrote: > > I will try to get the patch out today. Work doesn't look trivial. I am on > > it. > > > > Navina > > > > On May 14, 2017 23:10, "Ignacio Solis" wrote: > > > >> We should hold off until it is solved. How long will it take to fix > this? > >> > >> On Sun, May 14, 2017 at 10:13 PM, Navina Ramesh (Apache) > >> wrote: > >> > I just changed the status of this JIRA to "BLOCKER" - > >> > https://issues.apache.org/jira/browse/SAMZA-1128 > >> > > >> > This causes a bug in standalone deployment where any failure in the > >> barrier > >> > protocol stops the scheduled executorservice. Unfortunately, > >> > CoordinationUtils creates its own scheduled executorservice, which is > >> > incorrect. Scheduled ExecutorService is meant to be the working queue > for > >> > the ZkJobCoordinator. This needs to be fixed. Bharath already ran into > >> this > >> > bug during testing on Friday. > >> > > >> > veto for this release candidate. > >> > > >> > @Prateek/Jagadish: > >> > I recommend sending a "non-vote, testing release candidate" for this > >> > release until we complete all pending tasks (includes docs, tests > etc). > >> It > >> > will also be useful to share the pending tasks and their progress. In > >> case > >> > you have already shared it, I might have missed it since some emails > are > >> > bouncing off my inbox. > >> > > >> > Thanks! > >> > Navina > >> > > >> > On Sun, May 14, 2017 at 1:30 PM, Boris S wrote: > >> > > >> >> I think we need to add SAMZA-1286 and > >> >> SAMZA-1279 to the release . > >> >> > >> >> On Wed, May 10, 2017 at 7:51 PM, Jagadish Venkatraman < > >> jagad...@apache.org > >> >> > > >> >> wrote: > >> >> > >> >> > This is a call for a vote on a release of Apache Samza 0.13.0. > Thanks > >> to > >> >> > everyone who has contributed to this release. We are very glad to > see > >> >> some > >> >> > new contributors and features in this release. > >> >> > > >> >> > The release candidate can be downloaded from here: > >> >> > http://home.apache.org/~jagadish/samza-0.13.0-rc0/ > >> >> > > >> >> > The release candidate is signed with pgp key AF81FFBF, which can be > >> found > >> >> > on keyservers: > >> >> > http://pgp.mit.edu/pks/lookup?op=get&search=0xAF81FFBF > >> >> > > >> >> > The git tag is release-0.13.0-rc0 and signed with the same pgp key: > >> >> > https://git-wip-us.apache.org/repos/asf?p=samza.git;a=tag;h= > >> >> > refs/tags/release-0.13.0-rc0 > >> >> > > >> >> > Test binaries have been published to Maven's staging repository, > and > >> are > >> >> > available here: > >> >> > https://repository.apache.org/content/repositories/ > >> orgapachesamza-1020 > >> >> > > >> >> > 127 issues were resolved for this release: > >> >> > https://issues.apache.org/jira/issues/?jql=project%20% > >> >> > 3D%20SAMZA%20AND%20fixVersion%20in%20(0.13%2C%200.13.0)% > >> >> > 20AND%20status%20in%20(Resolved%2C%20Closed) > >> >> > > >> >> > The vote will be open for 72 hours (ending at 8:00PM Saturday, > >> >> 05/13/2017). > >> >> > > >> >> > Please download the release candidate, check the hashes/signature, > >> build > >> >> it > >> >> > and test it, and then please vote: > >> >> > > >> >> > > >> >> > [ ] +1 approve > >> >> > > >> >> > [ ] +0 no opinion > >> >> > > >> >> > [ ] -1 disapprove (and reason why) > >> >> > > >> >> > > >> >> > +1 from my side for the release. > >> >> > > >> >> > Cheers! > >> >> > > >> >> > >> > >> > >> > >> -- > >> Nacho - Ignacio Solis - iso...@igso.net > >> > > > > -- > Nacho - Ignacio Solis - iso...@igso.net >
