[GitHub] [samza] dnishimura commented on issue #1110: SAMZA-2278: Delete all for startpoints and fan outs.

2019-07-22 Thread GitBox 
dnishimura commented on issue #1110: SAMZA-2278: Delete all for startpoints and 
fan outs.
URL: https://github.com/apache/samza/pull/1110#issuecomment-514050183
 
 
   Thanks please merge.


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [samza] dnishimura opened a new pull request #1112: SAMZA-2276: Add Metdata store putAll API

2019-07-22 Thread GitBox 
dnishimura opened a new pull request #1112: SAMZA-2276: Add Metdata store 
putAll API
URL: https://github.com/apache/samza/pull/1112
 
 
   Add a putsAll API to the metadata store API. This allows for a delayed 
flush() call for underlying stores that require a flush() after write such as 
Kafka.


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [samza] dnishimura closed pull request #1111: SAMZA-2271: Add Metdata store putAll API

2019-07-22 Thread GitBox 
dnishimura closed pull request #: SAMZA-2271: Add Metdata store putAll API
URL: https://github.com/apache/samza/pull/
 
 
   


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [samza] dnishimura opened a new pull request #1111: SAMZA-2271: Add Metdata store putAll API

2019-07-22 Thread GitBox 
dnishimura opened a new pull request #: SAMZA-2271: Add Metdata store 
putAll API
URL: https://github.com/apache/samza/pull/
 
 
   Add a putsAll API to the metadata store API. This allows for a delayed 
flush() call for underlying stores that require a flush() after write such as 
Kafka. 


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [samza] dnishimura commented on a change in pull request #1108: SAMZA-2277: Semantics for cluster-manager.container.retry.window.ms not reflected in code

2019-07-22 Thread GitBox 
dnishimura commented on a change in pull request #1108: SAMZA-2277: Semantics 
for cluster-manager.container.retry.window.ms not reflected in code
URL: https://github.com/apache/samza/pull/1108#discussion_r306057384
 
 

 ##
 File path: 
samza-core/src/main/java/org/apache/samza/clustermanager/ContainerProcessManager.java
 ##
 @@ -409,32 +411,34 @@ public void onResourceCompleted(SamzaResourceStatus 
resourceStatus) {
 lastFailureTime = failure.getLastFailure();
   } else {
 currentFailCount = 1;
-lastFailureTime = 0L;
+lastFailureTime = Instant.now().toEpochMilli();
   }
-  if (currentFailCount >= retryCount) {
-long lastFailureMsDiff = System.currentTimeMillis() - 
lastFailureTime;
-
-if (lastFailureMsDiff < retryWindowMs) {
-  log.error("Processor ID: {} (current Container ID: {}) has 
failed {} times, with last failure {} ms ago. " +
-  "This is greater than retry count of {} and window of {} ms, 
" +
-  "so shutting down the application master and marking the job 
as failed.",
-  processorId, containerId, currentFailCount, 
lastFailureMsDiff, retryCount, retryWindowMs);
-
-  // We have too many failures, and we're within the window
-  // boundary, so reset shut down the app master.
-  tooManyFailedContainers = true;
-  state.status = SamzaApplicationState.SamzaAppStatus.FAILED;
-} else {
-  log.info("Resetting failure count for Processor ID: {} back to 
1, since last failure " +
-  "(for Container ID: {}) was outside the bounds of the retry 
window.", processorId, containerId);
-
-  // Reset counter back to 1, since the last failure for this
-  // container happened outside the window boundary.
-  processorFailures.put(processorId, new ProcessorFailure(1, 
System.currentTimeMillis()));
-}
+
+  long lastFailureMsDiff = Instant.now().toEpochMilli() - 
lastFailureTime;
 
 Review comment:
   I imagine it would be a sub-millisecond skew? Would that matter? Will change 
anyways to make the code cleaner.


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [samza] dnishimura commented on a change in pull request #1108: SAMZA-2277: Semantics for cluster-manager.container.retry.window.ms not reflected in code

2019-07-22 Thread GitBox 
dnishimura commented on a change in pull request #1108: SAMZA-2277: Semantics 
for cluster-manager.container.retry.window.ms not reflected in code
URL: https://github.com/apache/samza/pull/1108#discussion_r306057479
 
 

 ##
 File path: 
samza-core/src/main/java/org/apache/samza/clustermanager/ContainerProcessManager.java
 ##
 @@ -104,25 +105,26 @@
*/
   private final ClusterResourceManager clusterResourceManager;
 
-  /**
-   * If there are too many failed container failures (configured by 
job.container.retry.count) for a
-   * processor, the job exits.
-   */
-  private volatile boolean tooManyFailedContainers = false;
-
   /**
* Exception thrown in callbacks, such as {@code containerAllocator}
*/
   private volatile Throwable exceptionOccurred = null;
 
+  private ContainerProcessManagerMetrics containerProcessManagerMetrics;
+  private JvmMetrics jvmMetrics;
+  private Map metricsReporters;
+
   /**
* A map that keeps track of how many times each processor failed. The key 
is the processor ID, and the
* value is the {@link ProcessorFailure} object that has a count of failures.
*/
-  private final Map processorFailures = new 
HashMap<>();
-  private ContainerProcessManagerMetrics containerProcessManagerMetrics;
-  private JvmMetrics jvmMetrics;
-  private Map metricsReporters;
+  final Map processorFailures = new HashMap<>();
+
+  /**
+   * If there are too many failed container failures (configured by 
job.container.retry.count) for a
+   * processor, the job exits.
+   */
+  volatile boolean tooManyFailedContainers = false;
 
 Review comment:
   Will change. 


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Resolved] (SAMZA-1299) update samza configs with StandAlone tutorial link, when it is available.

2019-07-22 Thread Boris Shkolnik (JIRA) 


 [ 
https://issues.apache.org/jira/browse/SAMZA-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Shkolnik resolved SAMZA-1299.
---

> update samza configs with StandAlone tutorial link, when it is available.
> -
>
> Key: SAMZA-1299
> URL: https://issues.apache.org/jira/browse/SAMZA-1299
> Project: Samza
>  Issue Type: Sub-task
>Reporter: Boris Shkolnik
>Assignee: Boris Shkolnik
>Priority: Major
> Fix For: 0.13.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Resolved] (SAMZA-2137) Add 1.0 release notes and download link to website.

2019-07-22 Thread Daniel Chen (JIRA) 


 [ 
https://issues.apache.org/jira/browse/SAMZA-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Chen  resolved SAMZA-2137.
-
Resolution: Fixed

> Add 1.0 release notes and download link to website.
> ---
>
> Key: SAMZA-2137
> URL: https://issues.apache.org/jira/browse/SAMZA-2137
> Project: Samza
>  Issue Type: Task
>Reporter: Daniel Chen 
>Assignee: Daniel Chen 
>Priority: Major
> Fix For: 1.1
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Add blog post about 1.0 release and download link on website



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Resolved] (SAMZA-1201) Zk path setup for leader elector and barrier should be separated

2019-07-22 Thread Boris Shkolnik (JIRA) 


 [ 
https://issues.apache.org/jira/browse/SAMZA-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Shkolnik resolved SAMZA-1201.
---
Resolution: Fixed

this code has been modified extensively.

> Zk path setup for leader elector and barrier should be separated
> 
>
> Key: SAMZA-1201
> URL: https://issues.apache.org/jira/browse/SAMZA-1201
> Project: Samza
>  Issue Type: Bug
>Reporter: Xinyu Liu
>Assignee: Boris Shkolnik
>Priority: Major
> Fix For: 0.15.0
>
>
> Right now all the zk paths are created inside ZkControllerImpl.init(). 
> However, this doesn't work for coordinator service which uses ZkLeaderElector 
> but not ZkControllerImpl. The creation of these paths needs to separated so 
> that:
> * ZkLeaderElector ensures the processor paths exist
> * ZkBarrierForVersionUpdate ensures the job model version paths exist
> This way they can be used independently. 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Resolved] (SAMZA-1399) TestZkStreamProcessorSession.testTwoStreamProcessors failed in flaky fashion

2019-07-22 Thread Boris Shkolnik (JIRA) 


 [ 
https://issues.apache.org/jira/browse/SAMZA-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Shkolnik resolved SAMZA-1399.
---
Resolution: Fixed

This part of the tests has been rewritten significantly.

> TestZkStreamProcessorSession.testTwoStreamProcessors failed in flaky fashion
> 
>
> Key: SAMZA-1399
> URL: https://issues.apache.org/jira/browse/SAMZA-1399
> Project: Samza
>  Issue Type: Bug
>Affects Versions: 0.13.1
>Reporter: Fred Ji
>Assignee: Boris Shkolnik
>Priority: Major
> Fix For: 0.15.0
>
>
> We are disabling it for 0.13.1, but we need to fix this flaky test in the 
> later build. 
> Here is the stack trace:
> testTwoStreamProcessors
> java.lang.AssertionError: Didn't read all the leftover events in 5 attempts
>   at org.junit.Assert.fail(Assert.java:91)
>   at org.junit.Assert.assertTrue(Assert.java:43)
>   at 
> org.apache.samza.processor.TestZkStreamProcessorBase.waitUntilMessagesLeftN(TestZkStreamProcessorBase.java:306)
>   at 
> org.apache.samza.processor.TestZkStreamProcessorSession.testStreamProcessorWithSessionRestart(TestZkStreamProcessorSession.java:116)
>   at 
> org.apache.samza.processor.TestZkStreamProcessorSession.testTwoStreamProcessors(TestZkStreamProcessorSession.java:48)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
>

[jira] [Resolved] (SAMZA-1303) Request for waitForFinish(time, TimeUnit) api in LocalApplicationRunner

2019-07-22 Thread Bharath Kumarasubramanian (JIRA) 


 [ 
https://issues.apache.org/jira/browse/SAMZA-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bharath Kumarasubramanian resolved SAMZA-1303.
--
   Resolution: Duplicate
Fix Version/s: (was: 0.15.0)
   0.14.1

Fixed in  SAMZA-1653

> Request for waitForFinish(time, TimeUnit) api in LocalApplicationRunner
> ---
>
> Key: SAMZA-1303
> URL: https://issues.apache.org/jira/browse/SAMZA-1303
> Project: Samza
>  Issue Type: Improvement
>Reporter: Shanthoosh Venkataraman
>Priority: Minor
> Fix For: 0.14.1
>
>
> Existing waitForFinish() API in LocalApplicationRunner waits indefinitely for 
> a stream application to terminate. 
> We should consider adding waitForFinish(awaitTime, TimeUnit) API to 
> LocalApplicationRunner so that users don't block indefinitely if the 
> ApplicationRunner can't kill the application for some reason.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Closed] (SAMZA-1303) Request for waitForFinish(time, TimeUnit) api in LocalApplicationRunner

2019-07-22 Thread Bharath Kumarasubramanian (JIRA) 


 [ 
https://issues.apache.org/jira/browse/SAMZA-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bharath Kumarasubramanian closed SAMZA-1303.


> Request for waitForFinish(time, TimeUnit) api in LocalApplicationRunner
> ---
>
> Key: SAMZA-1303
> URL: https://issues.apache.org/jira/browse/SAMZA-1303
> Project: Samza
>  Issue Type: Improvement
>Reporter: Shanthoosh Venkataraman
>Priority: Minor
> Fix For: 0.14.1
>
>
> Existing waitForFinish() API in LocalApplicationRunner waits indefinitely for 
> a stream application to terminate. 
> We should consider adding waitForFinish(awaitTime, TimeUnit) API to 
> LocalApplicationRunner so that users don't block indefinitely if the 
> ApplicationRunner can't kill the application for some reason.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Assigned] (SAMZA-1760) SystemAdmin is not started properly in a few places

2019-07-22 Thread Cameron Lee (JIRA) 


 [ 
https://issues.apache.org/jira/browse/SAMZA-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cameron Lee reassigned SAMZA-1760:
--

Assignee: (was: Cameron Lee)

> SystemAdmin is not started properly in a few places
> ---
>
> Key: SAMZA-1760
> URL: https://issues.apache.org/jira/browse/SAMZA-1760
> Project: Samza
>  Issue Type: Bug
>Reporter: Cameron Lee
>Priority: Major
> Fix For: 0.14.1
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> [https://github.com/apache/samza/pull/397] added a "start" and "stop" to the 
> SystemAdmin interface. Most places got updated to manage the lifecycle. 
> However, a few places were missed (or other changes were made more recently 
> that did not correctly manage the lifecycle):
>  # CoordinatorStreamSystemConsumer starts a SystemAdmin in its "start" 
> method. However, it uses SystemAdmin.getSystemStreamMetadata in "register", 
> which is called before "start". This class properly stops SystemAdmin.
>  # SystemConsumerBench does not start/stop the SystemAdmin.
>  # TestRunner does not start/stop the SystemAdmin.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (SAMZA-1760) SystemAdmin is not started properly in a few places

2019-07-22 Thread Cameron Lee (JIRA) 


[ 
https://issues.apache.org/jira/browse/SAMZA-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890468#comment-16890468
 ] 

Cameron Lee commented on SAMZA-1760:


I haven't had a chance to finish the initial attempt at this, so I will mark 
the assignee back to "Unassigned" for now.

The original PR (#564) might still have some useful ideas, but a lot has 
changed since it went out.

> SystemAdmin is not started properly in a few places
> ---
>
> Key: SAMZA-1760
> URL: https://issues.apache.org/jira/browse/SAMZA-1760
> Project: Samza
>  Issue Type: Bug
>Reporter: Cameron Lee
>Assignee: Cameron Lee
>Priority: Major
> Fix For: 0.14.1
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> [https://github.com/apache/samza/pull/397] added a "start" and "stop" to the 
> SystemAdmin interface. Most places got updated to manage the lifecycle. 
> However, a few places were missed (or other changes were made more recently 
> that did not correctly manage the lifecycle):
>  # CoordinatorStreamSystemConsumer starts a SystemAdmin in its "start" 
> method. However, it uses SystemAdmin.getSystemStreamMetadata in "register", 
> which is called before "start". This class properly stops SystemAdmin.
>  # SystemConsumerBench does not start/stop the SystemAdmin.
>  # TestRunner does not start/stop the SystemAdmin.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[GitHub] [samza] cameronlee314 closed pull request #564: SAMZA-1760: SystemAdmin is not started properly in a few places

2019-07-22 Thread GitBox 
cameronlee314 closed pull request #564: SAMZA-1760: SystemAdmin is not started 
properly in a few places
URL: https://github.com/apache/samza/pull/564
 
 
   


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [samza] cameronlee314 commented on issue #564: SAMZA-1760: SystemAdmin is not started properly in a few places

2019-07-22 Thread GitBox 
cameronlee314 commented on issue #564: SAMZA-1760: SystemAdmin is not started 
properly in a few places
URL: https://github.com/apache/samza/pull/564#issuecomment-513949816
 
 
   I haven't had the opportunity to finish this for a while, so I will close 
this for now. If this ticket is picked up again in the future, it would be best 
to just make a new PR. I think some of the code in this PR is still valid, but 
a lot has changed in a year.


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Assigned] (SAMZA-1570) Programmatic way to set input stream priority and bootstrap mode for high-level API

2019-07-22 Thread Bharath Kumarasubramanian (JIRA) 


 [ 
https://issues.apache.org/jira/browse/SAMZA-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bharath Kumarasubramanian reassigned SAMZA-1570:


Assignee: Prateek Maheshwari

> Programmatic way to set input stream priority and bootstrap mode for 
> high-level API
> ---
>
> Key: SAMZA-1570
> URL: https://issues.apache.org/jira/browse/SAMZA-1570
> Project: Samza
>  Issue Type: Improvement
>Reporter: Jake Maes
>Assignee: Prateek Maheshwari
>Priority: Major
> Fix For: 0.15.0
>
>
> This is similar to SAMZA-1569, implemented by [~xinyu]
> Users should be able to specify whether an input stream is bootstrap stream 
> and the priority value. 
> cc [~pmaheshwari]



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Closed] (SAMZA-1658) samza-kafka module use kafka deprecated method to get topic metadata

2019-07-22 Thread Bharath Kumarasubramanian (JIRA) 


 [ 
https://issues.apache.org/jira/browse/SAMZA-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bharath Kumarasubramanian closed SAMZA-1658.


> samza-kafka module use kafka deprecated method to get topic metadata
> 
>
> Key: SAMZA-1658
> URL: https://issues.apache.org/jira/browse/SAMZA-1658
> Project: Samza
>  Issue Type: Improvement
>  Components: kafka
>Affects Versions: 0.12.0, 0.13.0, 0.14.0, 0.13.1
>Reporter: sailingYang
>Priority: Major
> Fix For: 0.15.0
>
>
> in  ClientUtilTopicMetadataStore, samza-kafka use 
> ClientUtils.fetchTopicMetadata to get topic metadata, this is a deprecated 
> method in kafka. this method use SyncProducer and  may get some problem.
> {code:java}
> // code placeholder
> def getTopicInfo(topics: Set[String]) = {
>   val currCorrId = corrID.getAndIncrement
>   val response: TopicMetadataResponse = 
> ClientUtils.fetchTopicMetadata(topics, brokers, clientId, timeout, currCorrId)
>   if (response.correlationId != currCorrId) {
> throw new SamzaException("CorrelationID did not match for request on 
> topics %s (sent %d, got %d)" format (topics, currCorrId, 
> response.correlationId))
>   }
>   response.topicsMetadata
> .map(metadata => (metadata.topic, metadata))
> .toMap
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Resolved] (SAMZA-1658) samza-kafka module use kafka deprecated method to get topic metadata

2019-07-22 Thread Bharath Kumarasubramanian (JIRA) 


 [ 
https://issues.apache.org/jira/browse/SAMZA-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bharath Kumarasubramanian resolved SAMZA-1658.
--
Resolution: Fixed

Fixed as part of recent Kafka 2.0 upgrade SAMZA-2127

> samza-kafka module use kafka deprecated method to get topic metadata
> 
>
> Key: SAMZA-1658
> URL: https://issues.apache.org/jira/browse/SAMZA-1658
> Project: Samza
>  Issue Type: Improvement
>  Components: kafka
>Affects Versions: 0.12.0, 0.13.0, 0.14.0, 0.13.1
>Reporter: sailingYang
>Priority: Major
> Fix For: 0.15.0
>
>
> in  ClientUtilTopicMetadataStore, samza-kafka use 
> ClientUtils.fetchTopicMetadata to get topic metadata, this is a deprecated 
> method in kafka. this method use SyncProducer and  may get some problem.
> {code:java}
> // code placeholder
> def getTopicInfo(topics: Set[String]) = {
>   val currCorrId = corrID.getAndIncrement
>   val response: TopicMetadataResponse = 
> ClientUtils.fetchTopicMetadata(topics, brokers, clientId, timeout, currCorrId)
>   if (response.correlationId != currCorrId) {
> throw new SamzaException("CorrelationID did not match for request on 
> topics %s (sent %d, got %d)" format (topics, currCorrId, 
> response.correlationId))
>   }
>   response.topicsMetadata
> .map(metadata => (metadata.topic, metadata))
> .toMap
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Closed] (SAMZA-1683) Deprecate RunLoop and job.container.single.thread.mode configuration

2019-07-22 Thread Bharath Kumarasubramanian (JIRA) 


 [ 
https://issues.apache.org/jira/browse/SAMZA-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bharath Kumarasubramanian closed SAMZA-1683.


> Deprecate RunLoop and job.container.single.thread.mode configuration
> 
>
> Key: SAMZA-1683
> URL: https://issues.apache.org/jira/browse/SAMZA-1683
> Project: Samza
>  Issue Type: Improvement
>Reporter: Prateek Maheshwari
>Priority: Minor
> Fix For: 0.15.0
>
>
> It's often unclear to users what the difference between 
> "job.container.single.thread.mode"
> and "job.container.thread.pool.size" configurations is. 
> Since, AsyncRunLoop has been the default for a while and it can mimic single 
> threaded RunLoop behavior with "job.container.thread.pool.size" == 0, we 
> should remove the older RunLoop class and the corresponding 
> "job.container.single.thread.mode" configuration.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Resolved] (SAMZA-1683) Deprecate RunLoop and job.container.single.thread.mode configuration

2019-07-22 Thread Bharath Kumarasubramanian (JIRA) 


 [ 
https://issues.apache.org/jira/browse/SAMZA-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bharath Kumarasubramanian resolved SAMZA-1683.
--
Resolution: Duplicate

Fixed in [SAMZA-2175]

> Deprecate RunLoop and job.container.single.thread.mode configuration
> 
>
> Key: SAMZA-1683
> URL: https://issues.apache.org/jira/browse/SAMZA-1683
> Project: Samza
>  Issue Type: Improvement
>Reporter: Prateek Maheshwari
>Priority: Minor
> Fix For: 0.15.0
>
>
> It's often unclear to users what the difference between 
> "job.container.single.thread.mode"
> and "job.container.thread.pool.size" configurations is. 
> Since, AsyncRunLoop has been the default for a while and it can mimic single 
> threaded RunLoop behavior with "job.container.thread.pool.size" == 0, we 
> should remove the older RunLoop class and the corresponding 
> "job.container.single.thread.mode" configuration.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (SAMZA-2067) Samza on Kubernetes

2019-07-22 Thread Weiqing Yang (JIRA) 


[ 
https://issues.apache.org/jira/browse/SAMZA-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890456#comment-16890456
 ] 

Weiqing Yang commented on SAMZA-2067:
-

This issue is WIP

> Samza on Kubernetes
> ---
>
> Key: SAMZA-2067
> URL: https://issues.apache.org/jira/browse/SAMZA-2067
> Project: Samza
>  Issue Type: New Feature
>Reporter: Weiqing Yang
>Priority: Major
> Fix For: 0.15.0, 1.1
>
>
> This Jira is to support Samza on Kubernetes.
> Please refer to the attached document for more details, including the 
> background, design, etc.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Updated] (SAMZA-2049) Startpoints user documentation

2019-07-22 Thread Daniel Nishimura (JIRA) 


 [ 
https://issues.apache.org/jira/browse/SAMZA-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Nishimura updated SAMZA-2049:

Fix Version/s: (was: 1.1)

> Startpoints user documentation
> --
>
> Key: SAMZA-2049
> URL: https://issues.apache.org/jira/browse/SAMZA-2049
> Project: Samza
>  Issue Type: Task
>Reporter: Daniel Nishimura
>Assignee: Daniel Nishimura
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (SAMZA-1960) Refactor QueryTranslator unit tests

2019-07-22 Thread Weiqing Yang (JIRA) 


[ 
https://issues.apache.org/jira/browse/SAMZA-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890455#comment-16890455
 ] 

Weiqing Yang commented on SAMZA-1960:
-

The issue 2 has been resolved.

> Refactor QueryTranslator unit tests
> ---
>
> Key: SAMZA-1960
> URL: https://issues.apache.org/jira/browse/SAMZA-1960
> Project: Samza
>  Issue Type: Bug
>  Components: sql
>Reporter: Weiqing Yang
>Priority: Major
> Fix For: 0.15.0
>
>
> This Jira is to track the follow issues:
>  # Currently, the unit tests about "QueryTranslator" are using their own 
> version of 
> [translate|https://github.com/apache/samza/blob/master/samza-sql/src/main/java/org/apache/samza/sql/translator/QueryTranslator.java#L107](),
>  the logic of which is a little messy. We should either use the translate() 
> [here|https://github.com/apache/samza/blob/master/samza-sql/src/main/java/org/apache/samza/sql/translator/QueryTranslator.java#L126]
>  or refactor the test version of 
> [translate|https://github.com/apache/samza/blob/master/samza-sql/src/main/java/org/apache/samza/sql/translator/QueryTranslator.java#L107]()
>  and its related unit tests.
>  # We should rename the package name of 
> "[testutil|https://github.com/apache/samza/tree/master/samza-sql/src/main/java/org/apache/samza/sql/testutil];
>  to "util". 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Resolved] (SAMZA-1901) Samza SQL Shell

2019-07-22 Thread Weiqing Yang (JIRA) 


 [ 
https://issues.apache.org/jira/browse/SAMZA-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Weiqing Yang resolved SAMZA-1901.
-
Resolution: Fixed

> Samza SQL Shell
> ---
>
> Key: SAMZA-1901
> URL: https://issues.apache.org/jira/browse/SAMZA-1901
> Project: Samza
>  Issue Type: New Feature
>  Components: sql
>Reporter: Weiqing Yang
>Priority: Major
> Fix For: 0.15.0
>
>
> This Jira implements the first version of Samza sql shell. 
> Please refer to the attached document for more details about the shell, 
> including the tech choices, features, design decisions, how to build, run and 
> debug the shell.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (SAMZA-1982) Use TimerRegistry to track time based window triggers instead of relying on window()

2019-07-22 Thread Bharath Kumarasubramanian (JIRA) 


[ 
https://issues.apache.org/jira/browse/SAMZA-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890454#comment-16890454
 ] 

Bharath Kumarasubramanian commented on SAMZA-1982:
--

I am not working on this actively. Will try to get this in for our next release 
1.3

> Use TimerRegistry to track time based window triggers instead of relying on 
> window()
> 
>
> Key: SAMZA-1982
> URL: https://issues.apache.org/jira/browse/SAMZA-1982
> Project: Samza
>  Issue Type: Improvement
>Reporter: Prateek Maheshwari
>Assignee: Bharath Kumarasubramanian
>Priority: Major
> Fix For: 1.1
>
>
> Now that we have support for arbitrary processing time timer callbacks 
> (TimerRegistry), we can switch from window() call based triggers to using 
> more precise triggers. Currently we set the window interval to be the GCD of 
> all window intervals. This has the disadvantage of keeping session windows 
> open longer than necessary, since in the worst case a new message has up to 2 
> * window time to arrive.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[GitHub] [samza] rmatharu commented on a change in pull request #1104: SAMZA-2266: Introduce a backoff when there are repeated failures for host-affinity allocations

2019-07-22 Thread GitBox 
rmatharu commented on a change in pull request #1104: SAMZA-2266: Introduce a 
backoff when there are repeated failures for host-affinity allocations
URL: https://github.com/apache/samza/pull/1104#discussion_r305993360
 
 

 ##
 File path: 
samza-core/src/main/java/org/apache/samza/clustermanager/ContainerProcessManager.java
 ##
 @@ -366,86 +381,15 @@ public void onResourceCompleted(SamzaResourceStatus 
resourceStatus) {
 state.jobHealthy.set(false);
 
 // handle container stop due to node fail
-this.handleContainerStop(processorId, resourceStatus.getContainerId(), 
ResourceRequestState.ANY_HOST, exitStatus);
+handleContainerStop(processorId, resourceStatus.getContainerId(), 
ResourceRequestState.ANY_HOST, exitStatus, Duration.ZERO);
 break;
 
   default:
-log.info("Container ID: {} for Processor ID: {} failed with exit code: 
{}.", containerId, processorId, exitStatus);
-
-state.failedContainers.incrementAndGet();
-state.failedContainersStatus.put(containerId, resourceStatus);
-state.jobHealthy.set(false);
-
-state.neededProcessors.incrementAndGet();
-// Find out previously running container location
-String lastSeenOn = 
state.jobModelManager.jobModel().getContainerToHostValue(processorId, 
SetContainerHostMapping.HOST_KEY);
-if (!hostAffinityEnabled || lastSeenOn == null) {
-  lastSeenOn = ResourceRequestState.ANY_HOST;
-}
-log.info("Container ID: {} for Processor ID: {} was last seen on host 
{}.", containerId, processorId, lastSeenOn);
-// A container failed for an unknown reason. Let's check to see if
-// we need to shutdown the whole app master if too many container
-// failures have happened. The rules for failing are that the
-// failure count for a task group id must be > the configured retry
-// count, and the last failure (the one prior to this one) must have
-// happened less than retry window ms ago. If retry count is set to
-// 0, the app master will fail on any container failure. If the
-// retry count is set to a number < 0, a container failure will
-// never trigger an app master failure.
-int retryCount = clusterManagerConfig.getContainerRetryCount();
-int retryWindowMs = clusterManagerConfig.getContainerRetryWindowMs();
-
-if (retryCount == 0) {
-  log.error("Processor ID: {} (current Container ID: {}) failed, and 
retry count is set to 0, " +
-  "so shutting down the application master and marking the job as 
failed.", processorId, containerId);
-
-  tooManyFailedContainers = true;
-} else if (retryCount > 0) {
-  int currentFailCount;
-  long lastFailureTime;
-  if (processorFailures.containsKey(processorId)) {
-ProcessorFailure failure = processorFailures.get(processorId);
-currentFailCount = failure.getCount() + 1;
-lastFailureTime = failure.getLastFailure();
-  } else {
-currentFailCount = 1;
-lastFailureTime = 0L;
-  }
-  if (currentFailCount >= retryCount) {
-long lastFailureMsDiff = System.currentTimeMillis() - 
lastFailureTime;
 
 Review comment:
   Summarizing the discussion, for anyone looking at this review, 
   there was a bug where the "fail job if N failures in a M window" was only 
looking at the "last failure being in the M window"


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [samza] rmatharu commented on a change in pull request #1108: SAMZA-2277: Semantics for cluster-manager.container.retry.window.ms not reflected in code

2019-07-22 Thread GitBox 
rmatharu commented on a change in pull request #1108: SAMZA-2277: Semantics for 
cluster-manager.container.retry.window.ms not reflected in code
URL: https://github.com/apache/samza/pull/1108#discussion_r305991882
 
 

 ##
 File path: 
samza-core/src/main/java/org/apache/samza/clustermanager/ContainerProcessManager.java
 ##
 @@ -409,32 +411,34 @@ public void onResourceCompleted(SamzaResourceStatus 
resourceStatus) {
 lastFailureTime = failure.getLastFailure();
   } else {
 currentFailCount = 1;
-lastFailureTime = 0L;
+lastFailureTime = Instant.now().toEpochMilli();
   }
-  if (currentFailCount >= retryCount) {
-long lastFailureMsDiff = System.currentTimeMillis() - 
lastFailureTime;
-
-if (lastFailureMsDiff < retryWindowMs) {
-  log.error("Processor ID: {} (current Container ID: {}) has 
failed {} times, with last failure {} ms ago. " +
-  "This is greater than retry count of {} and window of {} ms, 
" +
-  "so shutting down the application master and marking the job 
as failed.",
-  processorId, containerId, currentFailCount, 
lastFailureMsDiff, retryCount, retryWindowMs);
-
-  // We have too many failures, and we're within the window
-  // boundary, so reset shut down the app master.
-  tooManyFailedContainers = true;
-  state.status = SamzaApplicationState.SamzaAppStatus.FAILED;
-} else {
-  log.info("Resetting failure count for Processor ID: {} back to 
1, since last failure " +
-  "(for Container ID: {}) was outside the bounds of the retry 
window.", processorId, containerId);
-
-  // Reset counter back to 1, since the last failure for this
-  // container happened outside the window boundary.
-  processorFailures.put(processorId, new ProcessorFailure(1, 
System.currentTimeMillis()));
-}
+
+  long lastFailureMsDiff = Instant.now().toEpochMilli() - 
lastFailureTime;
 
 Review comment:
   Minor: Might be preferable to set lastFailureMsDiff in the if-condition 
above, to avoid time-skew in measurements.


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [samza] rmatharu commented on a change in pull request #1108: SAMZA-2277: Semantics for cluster-manager.container.retry.window.ms not reflected in code

2019-07-22 Thread GitBox 
rmatharu commented on a change in pull request #1108: SAMZA-2277: Semantics for 
cluster-manager.container.retry.window.ms not reflected in code
URL: https://github.com/apache/samza/pull/1108#discussion_r305990813
 
 

 ##
 File path: 
samza-core/src/main/java/org/apache/samza/clustermanager/ContainerProcessManager.java
 ##
 @@ -104,25 +105,26 @@
*/
   private final ClusterResourceManager clusterResourceManager;
 
-  /**
-   * If there are too many failed container failures (configured by 
job.container.retry.count) for a
-   * processor, the job exits.
-   */
-  private volatile boolean tooManyFailedContainers = false;
-
   /**
* Exception thrown in callbacks, such as {@code containerAllocator}
*/
   private volatile Throwable exceptionOccurred = null;
 
+  private ContainerProcessManagerMetrics containerProcessManagerMetrics;
+  private JvmMetrics jvmMetrics;
+  private Map metricsReporters;
+
   /**
* A map that keeps track of how many times each processor failed. The key 
is the processor ID, and the
* value is the {@link ProcessorFailure} object that has a count of failures.
*/
-  private final Map processorFailures = new 
HashMap<>();
-  private ContainerProcessManagerMetrics containerProcessManagerMetrics;
-  private JvmMetrics jvmMetrics;
-  private Map metricsReporters;
+  final Map processorFailures = new HashMap<>();
+
+  /**
+   * If there are too many failed container failures (configured by 
job.container.retry.count) for a
+   * processor, the job exits.
+   */
+  volatile boolean tooManyFailedContainers = false;
 
 Review comment:
   Would it be better to expose a getter instead, for unit-testing than make 
package private?


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [samza] rmatharu commented on a change in pull request #1108: SAMZA-2277: Semantics for cluster-manager.container.retry.window.ms not reflected in code

2019-07-22 Thread GitBox 
rmatharu commented on a change in pull request #1108: SAMZA-2277: Semantics for 
cluster-manager.container.retry.window.ms not reflected in code
URL: https://github.com/apache/samza/pull/1108#discussion_r305990813
 
 

 ##
 File path: 
samza-core/src/main/java/org/apache/samza/clustermanager/ContainerProcessManager.java
 ##
 @@ -104,25 +105,26 @@
*/
   private final ClusterResourceManager clusterResourceManager;
 
-  /**
-   * If there are too many failed container failures (configured by 
job.container.retry.count) for a
-   * processor, the job exits.
-   */
-  private volatile boolean tooManyFailedContainers = false;
-
   /**
* Exception thrown in callbacks, such as {@code containerAllocator}
*/
   private volatile Throwable exceptionOccurred = null;
 
+  private ContainerProcessManagerMetrics containerProcessManagerMetrics;
+  private JvmMetrics jvmMetrics;
+  private Map metricsReporters;
+
   /**
* A map that keeps track of how many times each processor failed. The key 
is the processor ID, and the
* value is the {@link ProcessorFailure} object that has a count of failures.
*/
-  private final Map processorFailures = new 
HashMap<>();
-  private ContainerProcessManagerMetrics containerProcessManagerMetrics;
-  private JvmMetrics jvmMetrics;
-  private Map metricsReporters;
+  final Map processorFailures = new HashMap<>();
+
+  /**
+   * If there are too many failed container failures (configured by 
job.container.retry.count) for a
+   * processor, the job exits.
+   */
+  volatile boolean tooManyFailedContainers = false;
 
 Review comment:
   Can we expose a getter instead for testing?


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [samza] dnishimura opened a new pull request #1110: SAMZA-2278: Delete all for startpoints and fan outs.

2019-07-22 Thread GitBox 
dnishimura opened a new pull request #1110: SAMZA-2278: Delete all for 
startpoints and fan outs.
URL: https://github.com/apache/samza/pull/1110
 
 
   Added a "delete all" for startpoints so we have the ability to delete all in 
case we run into situations where the startpoints poses a problem for the job.


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [samza] cameronlee314 opened a new pull request #1109: SAMZA-2279: [Scala cleanup] Convert JobConfig to Java

2019-07-22 Thread GitBox 
cameronlee314 opened a new pull request #1109: SAMZA-2279: [Scala cleanup] 
Convert JobConfig to Java
URL: https://github.com/apache/samza/pull/1109
 
 
   


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Updated] (SAMZA-2279) [Scala cleanup] Convert JobConfig to Java

2019-07-22 Thread Cameron Lee (JIRA) 


 [ 
https://issues.apache.org/jira/browse/SAMZA-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cameron Lee updated SAMZA-2279:
---
Description: The general direction is to stop writing new Scala code if 
possible. This conversion will allow additions to JobConfig to be written in 
Java instead of Scala.  (was: The general direction is to stop writing new 
Scala code if possible. This conversion will allow additions to MetricsConfig 
to be written in Java instead of Scala.)

> [Scala cleanup] Convert JobConfig to Java
> -
>
> Key: SAMZA-2279
> URL: https://issues.apache.org/jira/browse/SAMZA-2279
> Project: Samza
>  Issue Type: Improvement
>Reporter: Cameron Lee
>Assignee: Cameron Lee
>Priority: Major
>
> The general direction is to stop writing new Scala code if possible. This 
> conversion will allow additions to JobConfig to be written in Java instead of 
> Scala.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Created] (SAMZA-2279) [Scala cleanup] Convert JobConfig to Java

2019-07-22 Thread Cameron Lee (JIRA) 
Cameron Lee created SAMZA-2279:
--

 Summary: [Scala cleanup] Convert JobConfig to Java
 Key: SAMZA-2279
 URL: https://issues.apache.org/jira/browse/SAMZA-2279
 Project: Samza
  Issue Type: Improvement
Reporter: Cameron Lee
Assignee: Cameron Lee


The general direction is to stop writing new Scala code if possible. This 
conversion will allow additions to MetricsConfig to be written in Java instead 
of Scala.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Created] (SAMZA-2278) Add a "delete all" for startpoint manager

2019-07-22 Thread Daniel Nishimura (JIRA) 
Daniel Nishimura created SAMZA-2278:
---

 Summary: Add a "delete all" for startpoint manager
 Key: SAMZA-2278
 URL: https://issues.apache.org/jira/browse/SAMZA-2278
 Project: Samza
  Issue Type: Bug
Reporter: Daniel Nishimura
Assignee: Daniel Nishimura


Allows deletion of all startpoint related keys in case of emergency.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[GitHub] [samza] weiqingy edited a comment on issue #1106: Making Samza-Sql-Shell commands pluggable

2019-07-22 Thread GitBox 
weiqingy edited a comment on issue #1106: Making Samza-Sql-Shell commands 
pluggable
URL: https://github.com/apache/samza/pull/1106#issuecomment-513651830
 
 
   @atoomula 
   
   I agree.
   IMO command handers should NOT be environment variables. They are 
EXTENSIONs. They shall NOT be loaded by SET command. I prefer a load command 
instead. 


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [samza] weiqingy commented on issue #1106: Making Samza-Sql-Shell commands pluggable

2019-07-22 Thread GitBox 
weiqingy commented on issue #1106: Making Samza-Sql-Shell commands pluggable
URL: https://github.com/apache/samza/pull/1106#issuecomment-513652516
 
 
   @shenodaguirguis Forgot to remind of the Java document on interfaces and 
public methods. There'll be lots of build warnings otherwise.


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [samza] weiqingy commented on issue #1106: Making Samza-Sql-Shell commands pluggable

2019-07-22 Thread GitBox 
weiqingy commented on issue #1106: Making Samza-Sql-Shell commands pluggable
URL: https://github.com/apache/samza/pull/1106#issuecomment-513651830
 
 
   I agree.
   
   IMO command handers should NOT be environment variables. They are 
EXTENSIONs. They shall NOT be loaded by SET command. I prefer a load command 
instead. 


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services