[jira] [Commented] (RATIS-92) Move the basic getClassByName methods from RaftProperties to ReflectionUtils

2017-06-22 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060312#comment-16060312
 ] 

Enis Soztutar commented on RATIS-92:


Thanks. You can just commit these types of trivial changes without waiting on 
the reviewer since there is already a +1. At least that is what we do in HBase 
/ Phoenix, and it works well so far. 

> Move the basic getClassByName methods from RaftProperties to ReflectionUtils
> 
>
> Key: RATIS-92
> URL: https://issues.apache.org/jira/browse/RATIS-92
> Project: Ratis
>  Issue Type: Improvement
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
>Priority: Minor
> Attachments: r92_20170622.patch, r92_20170623.patch
>
>
> getClassByName and getClassByNameOrNull can be changed to static.  Then, they 
> become independent of RaftProperties.  It is better to move them to 
> ReflectionUtils.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (RATIS-92) Move the basic getClassByName methods from RaftProperties to ReflectionUtils

2017-06-22 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059871#comment-16059871
 ] 

Enis Soztutar commented on RATIS-92:


+1. 

small typo here: 
{code}
+   * Pares the given string as a {@link SupportedRpcType}
{code}

> Move the basic getClassByName methods from RaftProperties to ReflectionUtils
> 
>
> Key: RATIS-92
> URL: https://issues.apache.org/jira/browse/RATIS-92
> Project: Ratis
>  Issue Type: Improvement
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
>Priority: Minor
> Attachments: r92_20170622.patch
>
>
> getClassByName and getClassByNameOrNull can be changed to static.  Then, they 
> become independent of RaftProperties.  It is better to move them to 
> ReflectionUtils.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (RATIS-84) A few improvements on the release script

2017-05-01 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15991775#comment-15991775
 ] 

Enis Soztutar commented on RATIS-84:


+1. 

> A few improvements on the release script
> 
>
> Key: RATIS-84
> URL: https://issues.apache.org/jira/browse/RATIS-84
> Project: Ratis
>  Issue Type: Sub-task
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
> Attachments: r84_20170428.patch
>
>
> - Exclude dependency-reduced-pom.xml.
> - Use a better mvn command to get project.name and project.artifactId.
> - Show the mvn commands being executed.
> - Improve the echo messages.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-83) Add a DISCLAIMER file

2017-05-01 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15991461#comment-15991461
 ] 

Enis Soztutar commented on RATIS-83:


+1. go for it. 

> Add a DISCLAIMER file
> -
>
> Key: RATIS-83
> URL: https://issues.apache.org/jira/browse/RATIS-83
> Project: Ratis
>  Issue Type: Sub-task
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
> Attachments: r83_20170428.patch
>
>
> We also need a DISCLAIMER file according to 
> http://incubator.apache.org/guides/branding.html#disclaimers



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-81) Add license header for ratis-replicated-map/README.md

2017-04-27 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987972#comment-15987972
 ] 

Enis Soztutar commented on RATIS-81:


+1. 

> Add license header for ratis-replicated-map/README.md
> -
>
> Key: RATIS-81
> URL: https://issues.apache.org/jira/browse/RATIS-81
> Project: Ratis
>  Issue Type: Sub-task
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
> Attachments: r81_20170427.patch
>
>
> The license header is missing.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-80) Add "Apache" to maven project.name

2017-04-27 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987422#comment-15987422
 ] 

Enis Soztutar commented on RATIS-80:


+1. 

> Add "Apache" to maven project.name
> --
>
> Key: RATIS-80
> URL: https://issues.apache.org/jira/browse/RATIS-80
> Project: Ratis
>  Issue Type: Sub-task
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
> Attachments: r80_20170427.patch
>
>
> Currently, all the project names start with "Ratis".  We should change the 
> name prefix to "Apache Ratis".



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Resolved] (RATIS-58) Add rmap.proto

2017-04-10 Thread Enis Soztutar (JIRA)

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

Enis Soztutar resolved RATIS-58.

Resolution: Fixed

I've pushed this. Thanks [~jingzhao] for the review. 

> Add rmap.proto
> --
>
> Key: RATIS-58
> URL: https://issues.apache.org/jira/browse/RATIS-58
> Project: Ratis
>  Issue Type: Sub-task
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 0.1.0-alpha
>
> Attachments: ratis-58-v1.patch
>
>
> The PB file for the replicated map RPC. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Resolved] (RATIS-71) Removed usage of version properties usages for maven-plugins

2017-04-10 Thread Enis Soztutar (JIRA)

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

Enis Soztutar resolved RATIS-71.

Resolution: Fixed

I've committed this. Thanks [~khmarbaise] for the patch. 

> Removed usage of version properties usages for maven-plugins
> 
>
> Key: RATIS-71
> URL: https://issues.apache.org/jira/browse/RATIS-71
> Project: Ratis
>  Issue Type: Improvement
>Affects Versions: 0.1.0-alpha
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Trivial
> Fix For: 0.1.0-alpha
>
> Attachments: 
> 0001-RATIS-71-Removed-usage-of-version-properties-usages-.patch
>
>
> Currently there several plugins usages which look like this:
> {code:xml}
>  org.apache.maven.plugins
>  maven-shade-plugin
>  ${maven-shade-plugin.version}
> {code}
> which is superfluous cause the versions are already defined via the 
> pluginManagement in parent.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (RATIS-71) Removed usage of version properties usages for maven-plugins

2017-04-10 Thread Enis Soztutar (JIRA)

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

Enis Soztutar reassigned RATIS-71:
--

Assignee: Karl Heinz Marbaise

> Removed usage of version properties usages for maven-plugins
> 
>
> Key: RATIS-71
> URL: https://issues.apache.org/jira/browse/RATIS-71
> Project: Ratis
>  Issue Type: Improvement
>Affects Versions: 0.1.0-alpha
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Trivial
> Fix For: 0.1.0-alpha
>
> Attachments: 
> 0001-RATIS-71-Removed-usage-of-version-properties-usages-.patch
>
>
> Currently there several plugins usages which look like this:
> {code:xml}
>  org.apache.maven.plugins
>  maven-shade-plugin
>  ${maven-shade-plugin.version}
> {code}
> which is superfluous cause the versions are already defined via the 
> pluginManagement in parent.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Resolved] (RATIS-52) Refactor RaftUtils into different classes

2017-04-10 Thread Enis Soztutar (JIRA)

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

Enis Soztutar resolved RATIS-52.

Resolution: Fixed

> Refactor RaftUtils into different classes
> -
>
> Key: RATIS-52
> URL: https://issues.apache.org/jira/browse/RATIS-52
> Project: Ratis
>  Issue Type: Improvement
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 0.1.0-alpha
>
> Attachments: ratis-52-fix.patch, ratis-52_v1.patch, 
> ratis-52_v2.patch, ratis-52_v3.patch
>
>
> Ideally we should not have a generic {{RaftUtils}} class. The code should be 
> broken up into at least: 
> {code}
> ReflectionUtils -> All reflection, construction, initialization logic 
> IOUtils -> Add buffer and IO logic 
> SystemUtils or PlatformUtils -> OS type detection, etc 
> Preconditions (or something like that) -> assertTrue, etc 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (RATIS-52) Refactor RaftUtils into different classes

2017-04-10 Thread Enis Soztutar (JIRA)

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

Enis Soztutar updated RATIS-52:
---
Attachment: ratis-52_v3.patch

> Refactor RaftUtils into different classes
> -
>
> Key: RATIS-52
> URL: https://issues.apache.org/jira/browse/RATIS-52
> Project: Ratis
>  Issue Type: Improvement
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 0.1.0-alpha
>
> Attachments: ratis-52-fix.patch, ratis-52_v1.patch, 
> ratis-52_v2.patch, ratis-52_v3.patch
>
>
> Ideally we should not have a generic {{RaftUtils}} class. The code should be 
> broken up into at least: 
> {code}
> ReflectionUtils -> All reflection, construction, initialization logic 
> IOUtils -> Add buffer and IO logic 
> SystemUtils or PlatformUtils -> OS type detection, etc 
> Preconditions (or something like that) -> assertTrue, etc 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-52) Refactor RaftUtils into different classes

2017-04-10 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962532#comment-15962532
 ] 

Enis Soztutar commented on RATIS-52:


I've committed v3: 
{code}
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 06:40 min
[INFO] Finished at: 2017-04-10T00:26:46-07:00
[INFO] Final Memory: 34M/411M
[INFO] 
{code}

> Refactor RaftUtils into different classes
> -
>
> Key: RATIS-52
> URL: https://issues.apache.org/jira/browse/RATIS-52
> Project: Ratis
>  Issue Type: Improvement
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 0.1.0-alpha
>
> Attachments: ratis-52-fix.patch, ratis-52_v1.patch, ratis-52_v2.patch
>
>
> Ideally we should not have a generic {{RaftUtils}} class. The code should be 
> broken up into at least: 
> {code}
> ReflectionUtils -> All reflection, construction, initialization logic 
> IOUtils -> Add buffer and IO logic 
> SystemUtils or PlatformUtils -> OS type detection, etc 
> Preconditions (or something like that) -> assertTrue, etc 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-54) Bump maven.min.version to 3.3.9

2017-04-03 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15954243#comment-15954243
 ] 

Enis Soztutar commented on RATIS-54:


+1. 

> Bump maven.min.version to 3.3.9
> ---
>
> Key: RATIS-54
> URL: https://issues.apache.org/jira/browse/RATIS-54
> Project: Ratis
>  Issue Type: Task
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
> Attachments: r54_20170330.patch, r54_20170331.patch
>
>
> [~enis] found that some earlier Maven 3.x version does not work well; see 
> [this 
> comment|https://issues.apache.org/jira/browse/RATIS-47?focusedCommentId=15935648&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15935648].
> Maven 3.3.9 is the latest stable release, released on 2015-11-14; see 
> https://maven.apache.org/docs/history.html
> It seems reasonable to require Maven 3.3.9.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-64) Do not pre-shade artifacts

2017-04-01 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15952391#comment-15952391
 ] 

Enis Soztutar commented on RATIS-64:


bq.  First of all, what is the problem we try to solve? Is it to avoid the 
imports from org.apache.ratis.shaded packages in our source code?
Indeed. It is for keeping the source code shading-free inside Ratis so that we 
do not fight with the IDE every day. 
bq. #3 sounds like a good idea. But why we need to kick out ratis-hadoop?
I think so, in HBase master code we have both (1) and (3) for example. (3) is 
implemented in empty-modules hbase-shaded-client and hbase-shaded-server where 
they each create uber-jars with shaded deps. However, we needed (1), because 
Hadoop would bring in PB, Guava, etc dependencies which would otherwise cause 
compilation problems. Again, without removing ratis-hadoop module, we can 
instead depend on fully shaded Hadoop artifacts so that we can have our 
versions of PB and Guava in the classpath. 
However regardless of shading, I feel that ratis-hadoop really does not belong 
inside Ratis, but it should be maintained inside Hadoop. Maybe once the RPC API 
is more stable we can consider that refactoring. 


> Do not pre-shade artifacts
> --
>
> Key: RATIS-64
> URL: https://issues.apache.org/jira/browse/RATIS-64
> Project: Ratis
>  Issue Type: Bug
>Reporter: Enis Soztutar
>
> Hugo and I were discussing a case were the shading should happen at the last 
> step, rather than what we do today. 
> I think there are 3 possible strategies of shading that one can do: 
>  (1) pre-shade some of your dependencies, so that your other dependencies can 
> work. This what we do today, we shade PB+ GRPC, etc so that Hadoop can work. 
>  (2) pre-shade some of your dependencies' transitive dependencies so that you 
> depend on already-shaded artifacts. This will be like having maven artifacts 
> of shaded-hadoop so that hadoop itself does not bring in any more dependency. 
> If hadoop has shaded artifacts, or we do shading of hadoop's dependencies in 
> another repository, we won't need to pre-shade PB, etc. 
>  (3) post-shade. This means that in the code itself we do not depend on 
> shaded packages anymore, but do the shading as a different module so that we 
> publish shaded artifacts. This allows the downstreamers to be able to consume 
> ratis, while allowing ratis source code to be saner. 
> Obviously for doing (3), we need to kick out ratis-hadoop module to the 
> hadoop project. Thinking about it, I think ratis-hadoop does not belong in 
> Ratis itself anyway. What do you guys think about moving the code over to 
> Hadoop, and getting rid of the hadoop dependency to end this shading madness? 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-64) Do not pre-shade artifacts

2017-04-01 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15952385#comment-15952385
 ] 

Enis Soztutar commented on RATIS-64:


This is from [~szetszwo], from the mail thread:
{quote}
I am open to change the shading procedure but I like to understand the
motivation.  First of all, what is the problem we try to solve?  Is it
to avoid the imports from org.apache.ratis.shaded packages in our
source code?

#3 sounds like a good idea.  But why we need to kick out ratis-hadoop?
 I mean why it can't be post-shaded?
{quote} 

> Do not pre-shade artifacts
> --
>
> Key: RATIS-64
> URL: https://issues.apache.org/jira/browse/RATIS-64
> Project: Ratis
>  Issue Type: Bug
>Reporter: Enis Soztutar
>
> Hugo and I were discussing a case were the shading should happen at the last 
> step, rather than what we do today. 
> I think there are 3 possible strategies of shading that one can do: 
>  (1) pre-shade some of your dependencies, so that your other dependencies can 
> work. This what we do today, we shade PB+ GRPC, etc so that Hadoop can work. 
>  (2) pre-shade some of your dependencies' transitive dependencies so that you 
> depend on already-shaded artifacts. This will be like having maven artifacts 
> of shaded-hadoop so that hadoop itself does not bring in any more dependency. 
> If hadoop has shaded artifacts, or we do shading of hadoop's dependencies in 
> another repository, we won't need to pre-shade PB, etc. 
>  (3) post-shade. This means that in the code itself we do not depend on 
> shaded packages anymore, but do the shading as a different module so that we 
> publish shaded artifacts. This allows the downstreamers to be able to consume 
> ratis, while allowing ratis source code to be saner. 
> Obviously for doing (3), we need to kick out ratis-hadoop module to the 
> hadoop project. Thinking about it, I think ratis-hadoop does not belong in 
> Ratis itself anyway. What do you guys think about moving the code over to 
> Hadoop, and getting rid of the hadoop dependency to end this shading madness? 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (RATIS-64) Do not pre-shade artifacts

2017-04-01 Thread Enis Soztutar (JIRA)
Enis Soztutar created RATIS-64:
--

 Summary: Do not pre-shade artifacts
 Key: RATIS-64
 URL: https://issues.apache.org/jira/browse/RATIS-64
 Project: Ratis
  Issue Type: Bug
Reporter: Enis Soztutar


Hugo and I were discussing a case were the shading should happen at the last 
step, rather than what we do today. 

I think there are 3 possible strategies of shading that one can do: 
 (1) pre-shade some of your dependencies, so that your other dependencies can 
work. This what we do today, we shade PB+ GRPC, etc so that Hadoop can work. 
 (2) pre-shade some of your dependencies' transitive dependencies so that you 
depend on already-shaded artifacts. This will be like having maven artifacts of 
shaded-hadoop so that hadoop itself does not bring in any more dependency. If 
hadoop has shaded artifacts, or we do shading of hadoop's dependencies in 
another repository, we won't need to pre-shade PB, etc. 
 (3) post-shade. This means that in the code itself we do not depend on shaded 
packages anymore, but do the shading as a different module so that we publish 
shaded artifacts. This allows the downstreamers to be able to consume ratis, 
while allowing ratis source code to be saner. 

Obviously for doing (3), we need to kick out ratis-hadoop module to the hadoop 
project. Thinking about it, I think ratis-hadoop does not belong in Ratis 
itself anyway. What do you guys think about moving the code over to Hadoop, and 
getting rid of the hadoop dependency to end this shading madness? 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-56) Update project version to 0.1.0-alpha

2017-04-01 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15952379#comment-15952379
 ] 

Enis Soztutar commented on RATIS-56:


Forgot to mention, can you also update the version in the new module, 
ratis-replicated-map. 

> Update project version to 0.1.0-alpha
> -
>
> Key: RATIS-56
> URL: https://issues.apache.org/jira/browse/RATIS-56
> Project: Ratis
>  Issue Type: Sub-task
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
> Attachments: r56_20170330.patch
>
>
> We may use the following command to update the project version from 
> 0.1-SNAPSHOT to 0.1.0-alpha.
> {code}
> find . -name pom.xml | xargs sed -i.old "s/0.1-SNAPSHOT/0.1.0-alpha/g" 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-56) Update project version to 0.1.0-alpha

2017-04-01 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15952378#comment-15952378
 ] 

Enis Soztutar commented on RATIS-56:


Good to know, but I still think that we should commit this. The reason is that 
we want the release source tarball to be created from an exact git hash (or 
tag), so that we can verify the contents are the same as the git tag. If we do 
not commit this, then we will lose the property that the recursive diff of 
tarball vs git tag is zero. 
+1 on the patch. 
Thanks for driving the release BTW. As an RM, I think you can commit these kind 
of patches without having to wait for the full round of reviews just to speed 
things up. 
On an unrelated note, what can help us for driving frequent releases is to have 
a script to drive the release process. I think we should do something like 
this: https://github.com/apache/hbase/blob/master/dev-support/make_rc.sh. 

> Update project version to 0.1.0-alpha
> -
>
> Key: RATIS-56
> URL: https://issues.apache.org/jira/browse/RATIS-56
> Project: Ratis
>  Issue Type: Sub-task
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
> Attachments: r56_20170330.patch
>
>
> We may use the following command to update the project version from 
> 0.1-SNAPSHOT to 0.1.0-alpha.
> {code}
> find . -name pom.xml | xargs sed -i.old "s/0.1-SNAPSHOT/0.1.0-alpha/g" 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-52) Refactor RaftUtils into different classes

2017-03-31 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15951388#comment-15951388
 ] 

Enis Soztutar commented on RATIS-52:


bq. I think for this patch we can do the code refactoring work only, i.e., only 
moving the existing reflection-related methods out of RaftUtils.java
Fair enough. Let me commit the fixed version without new code. 

> Refactor RaftUtils into different classes
> -
>
> Key: RATIS-52
> URL: https://issues.apache.org/jira/browse/RATIS-52
> Project: Ratis
>  Issue Type: Improvement
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 0.1.0-alpha
>
> Attachments: ratis-52-fix.patch, ratis-52_v1.patch, ratis-52_v2.patch
>
>
> Ideally we should not have a generic {{RaftUtils}} class. The code should be 
> broken up into at least: 
> {code}
> ReflectionUtils -> All reflection, construction, initialization logic 
> IOUtils -> Add buffer and IO logic 
> SystemUtils or PlatformUtils -> OS type detection, etc 
> Preconditions (or something like that) -> assertTrue, etc 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (RATIS-61) QuorumSupplier

2017-03-30 Thread Enis Soztutar (JIRA)

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

Enis Soztutar updated RATIS-61:
---
Attachment: ratis-61-v1.patch

v1 patch. Added a unit test, and some infrastructure for test utilities.  

> QuorumSupplier
> --
>
> Key: RATIS-61
> URL: https://issues.apache.org/jira/browse/RATIS-61
> Project: Ratis
>  Issue Type: Sub-task
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 0.1.0-alpha
>
> Attachments: ratis-61-v1.patch
>
>
> Replicated map is like zookeper, where there is a fixed set of known-hosts in 
> the quorum. No reconfiguration yet. 
> {code}
> QuorumSupplier::List getQuorum()
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-57) Fix pom.xml for mvn release:prepare

2017-03-30 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15950031#comment-15950031
 ] 

Enis Soztutar commented on RATIS-57:


Thanks. Let's go ahead with the commit. 

> Fix pom.xml for mvn release:prepare
> ---
>
> Key: RATIS-57
> URL: https://issues.apache.org/jira/browse/RATIS-57
> Project: Ratis
>  Issue Type: Sub-task
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
> Attachments: r57_20170330.patch
>
>
> According to [Prepare your POMs for 
> release|http://www.apache.org/dev/publishing-maven-artifacts.html#prepare-poms],
>  the following command can test the pom.
> {code}
> mvn release:prepare -DdryRun=true -DautoVersionSubmodules=true
> {code}
> The JIRA is to fix the unexpected diff between pom.xml and pom.xml.tag.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (RATIS-61) QuorumSupplier

2017-03-30 Thread Enis Soztutar (JIRA)
Enis Soztutar created RATIS-61:
--

 Summary: QuorumSupplier
 Key: RATIS-61
 URL: https://issues.apache.org/jira/browse/RATIS-61
 Project: Ratis
  Issue Type: Sub-task
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 0.1.0-alpha


Replicated map is like zookeper, where there is a fixed set of known-hosts in 
the quorum. No reconfiguration yet. 

{code}
QuorumSupplier::List getQuorum()
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (RATIS-60) Allow direct PB support for Message and SMLogEntry

2017-03-30 Thread Enis Soztutar (JIRA)

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

Enis Soztutar updated RATIS-60:
---
Attachment: ratis-60-v0.patch

This v0 patch is what I have in the patch from the parent RATIS-40. However, it 
does not fix the problem, just allows us to have PB-based Message objects. Just 
attaching for illustrating the problem. 

> Allow direct PB support for Message and SMLogEntry
> --
>
> Key: RATIS-60
> URL: https://issues.apache.org/jira/browse/RATIS-60
> Project: Ratis
>  Issue Type: Sub-task
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 0.1.0-alpha
>
> Attachments: ratis-60-v0.patch
>
>
> Right now, for flexibility, both Message and SMLogEntry are ByteStrings. This 
> allows using custom serialization formats other than PB (or maybe use a 
> different  version of PB). 
> However, this is very inefficient for the common case where both the messages 
> and SM Log Entries are themselves PB objects. We unnecessarily serialize 
> twice. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (RATIS-60) Allow direct PB support for Message and SMLogEntry

2017-03-30 Thread Enis Soztutar (JIRA)
Enis Soztutar created RATIS-60:
--

 Summary: Allow direct PB support for Message and SMLogEntry
 Key: RATIS-60
 URL: https://issues.apache.org/jira/browse/RATIS-60
 Project: Ratis
  Issue Type: Sub-task
Reporter: Enis Soztutar
Assignee: Enis Soztutar


Right now, for flexibility, both Message and SMLogEntry are ByteStrings. This 
allows using custom serialization formats other than PB (or maybe use a 
different  version of PB). 

However, this is very inefficient for the common case where both the messages 
and SM Log Entries are themselves PB objects. We unnecessarily serialize twice. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (RATIS-59) bin/ script changes for rmap

2017-03-30 Thread Enis Soztutar (JIRA)

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

Enis Soztutar updated RATIS-59:
---
Attachment: ratis-59-v1.patch

v1 patch. Need RATIS-29 to go in first. 

> bin/ script changes for rmap
> 
>
> Key: RATIS-59
> URL: https://issues.apache.org/jira/browse/RATIS-59
> Project: Ratis
>  Issue Type: Sub-task
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 0.1.0-alpha
>
> Attachments: ratis-59-v1.patch
>
>
> Changes to bin/ scripts for the Rmap server and CLI. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (RATIS-59) bin/ script changes for rmap

2017-03-30 Thread Enis Soztutar (JIRA)
Enis Soztutar created RATIS-59:
--

 Summary: bin/ script changes for rmap
 Key: RATIS-59
 URL: https://issues.apache.org/jira/browse/RATIS-59
 Project: Ratis
  Issue Type: Sub-task
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 0.1.0-alpha


Changes to bin/ scripts for the Rmap server and CLI. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (RATIS-58) Add rmap.proto

2017-03-30 Thread Enis Soztutar (JIRA)

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

Enis Soztutar updated RATIS-58:
---
Attachment: ratis-58-v1.patch

> Add rmap.proto
> --
>
> Key: RATIS-58
> URL: https://issues.apache.org/jira/browse/RATIS-58
> Project: Ratis
>  Issue Type: Sub-task
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 0.1.0-alpha
>
> Attachments: ratis-58-v1.patch
>
>
> The PB file for the replicated map RPC. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (RATIS-58) Add rmap.proto

2017-03-30 Thread Enis Soztutar (JIRA)
Enis Soztutar created RATIS-58:
--

 Summary: Add rmap.proto
 Key: RATIS-58
 URL: https://issues.apache.org/jira/browse/RATIS-58
 Project: Ratis
  Issue Type: Sub-task
Reporter: Enis Soztutar
Assignee: Enis Soztutar


The PB file for the replicated map RPC. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-8) Avoid using Optional for data fields in TransactionContext

2017-03-30 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15949753#comment-15949753
 ] 

Enis Soztutar commented on RATIS-8:
---

+1 for returning null.

> Avoid using Optional for data fields in TransactionContext
> --
>
> Key: RATIS-8
> URL: https://issues.apache.org/jira/browse/RATIS-8
> Project: Ratis
>  Issue Type: Improvement
>Reporter: Jing Zhao
>Assignee: Hugo Louro
> Attachments: RATIS-8.patch
>
>
> It's usually not recommended to use {{Optional}} as class fields. Let's use 
> this jira to revisit the {{Optional}} usage in {{TransactionContext}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (RATIS-52) Refactor RaftUtils into different classes

2017-03-30 Thread Enis Soztutar (JIRA)

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

Enis Soztutar updated RATIS-52:
---
Attachment: ratis-52_v2.patch

Thanks Nicholas. 
Attaching v2 patch which addresses the review. I've kept the PlatformUtils and 
ReflectionUtils as classes because they indeed have private methods which are 
better kept as private. 


> Refactor RaftUtils into different classes
> -
>
> Key: RATIS-52
> URL: https://issues.apache.org/jira/browse/RATIS-52
> Project: Ratis
>  Issue Type: Improvement
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Attachments: ratis-52_v1.patch, ratis-52_v2.patch
>
>
> Ideally we should not have a generic {{RaftUtils}} class. The code should be 
> broken up into at least: 
> {code}
> ReflectionUtils -> All reflection, construction, initialization logic 
> IOUtils -> Add buffer and IO logic 
> SystemUtils or PlatformUtils -> OS type detection, etc 
> Preconditions (or something like that) -> assertTrue, etc 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-8) Avoid using Optional for data fields in TransactionContext

2017-03-30 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15949584#comment-15949584
 ] 

Enis Soztutar commented on RATIS-8:
---

Patch looks good. However, can you also get rid of Optionals from the method 
return signatures as well. {{TransactionContext}} is a core data structure, 
which we are expected to be creating tens of thousands per second. Better to 
get rid of extra object creations. 

> Avoid using Optional for data fields in TransactionContext
> --
>
> Key: RATIS-8
> URL: https://issues.apache.org/jira/browse/RATIS-8
> Project: Ratis
>  Issue Type: Improvement
>Reporter: Jing Zhao
>Assignee: Hugo Louro
> Attachments: RATIS-8.patch
>
>
> It's usually not recommended to use {{Optional}} as class fields. Let's use 
> this jira to revisit the {{Optional}} usage in {{TransactionContext}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-57) Fix pom.xml for mvn release:prepare

2017-03-30 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15949535#comment-15949535
 ] 

Enis Soztutar commented on RATIS-57:


I don't see any changes other than formatting, am I missing something? 

> Fix pom.xml for mvn release:prepare
> ---
>
> Key: RATIS-57
> URL: https://issues.apache.org/jira/browse/RATIS-57
> Project: Ratis
>  Issue Type: Sub-task
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
> Attachments: r57_20170330.patch
>
>
> According to [Prepare your POMs for 
> release|http://www.apache.org/dev/publishing-maven-artifacts.html#prepare-poms],
>  the following command can test the pom.
> {code}
> mvn release:prepare -DdryRun=true -DautoVersionSubmodules=true
> {code}
> The JIRA is to fix the unexpected diff between pom.xml and pom.xml.tag.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-54) Bump maven.min.version to 3.3.9

2017-03-30 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15949501#comment-15949501
 ] 

Enis Soztutar commented on RATIS-54:


requiring the latest version is a bit aggressive, but I did not try with an 
earlier 3.3 release. I know that we have problems with 3.2. Let's go with this 
for now. 
Do you mind changing the line in BUILDING.md: 
{code}
Apache Ratis uses Apache Maven for the builds. A 3.2+ version of Maven is 
required as well as
{code}

> Bump maven.min.version to 3.3.9
> ---
>
> Key: RATIS-54
> URL: https://issues.apache.org/jira/browse/RATIS-54
> Project: Ratis
>  Issue Type: Task
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
> Attachments: r54_20170330.patch
>
>
> [~enis] found that some earlier Maven 3.x version does not work well; see 
> [this 
> comment|https://issues.apache.org/jira/browse/RATIS-47?focusedCommentId=15935648&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15935648].
> Maven 3.3.9 is the latest stable release, released on 2015-11-14; see 
> https://maven.apache.org/docs/history.html
> It seems reasonable to require Maven 3.3.9.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (RATIS-52) Refactor RaftUtils into different classes

2017-03-29 Thread Enis Soztutar (JIRA)

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

Enis Soztutar updated RATIS-52:
---
Attachment: ratis-52_v1.patch

v1 patch. Mostly straightforward refactoring. Only change is some addition of 
more convenience methods in the ReflectionUtils needed by RATIS-40. Other than 
that no code change. 

New classes: 
IOUTils, Iterables, LogUtils, PlatformUtils, Preconditions, ReflectionUtils. 
RaftUtils is gone. Should we need RAFT (as in protocol-related) utility 
methods, we can re-add at a later time. 

Appreciate if Nicolas or Jing can skim over the changes. It is a huge patch, I 
don't want to keep rebasing. Thanks. 

> Refactor RaftUtils into different classes
> -
>
> Key: RATIS-52
> URL: https://issues.apache.org/jira/browse/RATIS-52
> Project: Ratis
>  Issue Type: Improvement
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Attachments: ratis-52_v1.patch
>
>
> Ideally we should not have a generic {{RaftUtils}} class. The code should be 
> broken up into at least: 
> {code}
> ReflectionUtils -> All reflection, construction, initialization logic 
> IOUtils -> Add buffer and IO logic 
> SystemUtils or PlatformUtils -> OS type detection, etc 
> Preconditions (or something like that) -> assertTrue, etc 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (RATIS-52) Refactor RaftUtils into different classes

2017-03-29 Thread Enis Soztutar (JIRA)

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

Enis Soztutar reassigned RATIS-52:
--

Assignee: Enis Soztutar

> Refactor RaftUtils into different classes
> -
>
> Key: RATIS-52
> URL: https://issues.apache.org/jira/browse/RATIS-52
> Project: Ratis
>  Issue Type: Improvement
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
>
> Ideally we should not have a generic {{RaftUtils}} class. The code should be 
> broken up into at least: 
> {code}
> ReflectionUtils -> All reflection, construction, initialization logic 
> IOUtils -> Add buffer and IO logic 
> SystemUtils or PlatformUtils -> OS type detection, etc 
> Preconditions (or something like that) -> assertTrue, etc 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (RATIS-52) Refactor RaftUtils into different classes

2017-03-29 Thread Enis Soztutar (JIRA)
Enis Soztutar created RATIS-52:
--

 Summary: Refactor RaftUtils into different classes
 Key: RATIS-52
 URL: https://issues.apache.org/jira/browse/RATIS-52
 Project: Ratis
  Issue Type: Improvement
Reporter: Enis Soztutar


Ideally we should not have a generic {{RaftUtils}} class. The code should be 
broken up into at least: 
{code}
ReflectionUtils -> All reflection, construction, initialization logic 
IOUtils -> Add buffer and IO logic 
SystemUtils or PlatformUtils -> OS type detection, etc 
Preconditions (or something like that) -> assertTrue, etc 
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-8) Avoid using Optional for data fields in TransactionContext

2017-03-29 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15947623#comment-15947623
 ] 

Enis Soztutar commented on RATIS-8:
---

+1 for this. Unlike in other languages, Optional is not a zero-cost abstraction 
in Java. And without pattern matching, etc, it is not worth it. My Optional 
usage was a failed experiment. 

> Avoid using Optional for data fields in TransactionContext
> --
>
> Key: RATIS-8
> URL: https://issues.apache.org/jira/browse/RATIS-8
> Project: Ratis
>  Issue Type: Improvement
>Reporter: Jing Zhao
>Assignee: Hugo Louro
>
> It's usually not recommended to use {{Optional}} as class fields. Let's use 
> this jira to revisit the {{Optional}} usage in {{TransactionContext}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (RATIS-51) Add ratis-replicated-map module

2017-03-28 Thread Enis Soztutar (JIRA)

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

Enis Soztutar updated RATIS-51:
---
Attachment: ratis-51-v1.patch

> Add ratis-replicated-map module
> ---
>
> Key: RATIS-51
> URL: https://issues.apache.org/jira/browse/RATIS-51
> Project: Ratis
>  Issue Type: Sub-task
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 0.1.0-alpha
>
> Attachments: ratis-51-v1.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-40) Replicated Map

2017-03-28 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15946442#comment-15946442
 ] 

Enis Soztutar commented on RATIS-40:


I am gonna open up subtasks here to get the patches in piece meal. 

> Replicated Map
> --
>
> Key: RATIS-40
> URL: https://issues.apache.org/jira/browse/RATIS-40
> Project: Ratis
>  Issue Type: New Feature
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 0.1.0-alpha
>
> Attachments: ratis-40_v1.patch
>
>
> Ratis replicated map is an implementation of a sorted map (think TreeMap) as 
> a replicated state machine. This is not under examples because it is intended 
> to be used in production where a simple in-memory map is sufficient to hold 
> the data. The data is fully cached in memory, but it is still durable since 
> raft log is used as a replicated log, and data is snapshotted periodically.
> The replicated map (RMap) is not only the state machine implementation, but 
> all of the remaining code, including the client and querying capabilities 
> which is built on top of the other modules. In that sense, it is dog-fooding 
> the ratis library to implement an end-to-end solution for a replicated 
> in-memory data store.
> Replicated maps are conceptually similar to ZooKeeper/Etcd/LogCabin where the 
> data is hosted in a known cluster configuration and is not sharded. All the 
> servers in the cluster participate in a single RAFT ring.
> The data model is that users can create independent RMap instances in the 
> cluster and read / write or scan the data as key value pairs in those 
> replicated maps. A replicated map named the meta map contains information 
> about all of the other maps in the cluster.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (RATIS-51) Add ratis-replicated-map module

2017-03-28 Thread Enis Soztutar (JIRA)
Enis Soztutar created RATIS-51:
--

 Summary: Add ratis-replicated-map module
 Key: RATIS-51
 URL: https://issues.apache.org/jira/browse/RATIS-51
 Project: Ratis
  Issue Type: Sub-task
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 0.1.0-alpha






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (RATIS-29) bin/ scripts

2017-03-28 Thread Enis Soztutar (JIRA)

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

Enis Soztutar updated RATIS-29:
---
Attachment: ratis-29_v2.patch

v2 patch which removes all daemon related scripts. Only the minimum is there 
right now. 
{code}
bin/ratis 
bin/ratis-config.sh 
conf/log4j.properties
conf/ratis-env.sh 
{code}


> bin/ scripts
> 
>
> Key: RATIS-29
> URL: https://issues.apache.org/jira/browse/RATIS-29
> Project: Ratis
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Attachments: 0001-RATIS-29-bin-scripts.patch, ratis-29_v2.patch
>
>
> We need {{bin/}} scripts. I will model those from HBase (and not Hadoop). I 
> am not very fond of Hadoop's layout, and it is unnecessarily complex for 
> ratis for now. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-49) Add a clean profile to remove shaded source

2017-03-28 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15946089#comment-15946089
 ] 

Enis Soztutar commented on RATIS-49:


Other than what Jing says above, the patch looks good. 

> Add a clean profile to remove shaded source
> ---
>
> Key: RATIS-49
> URL: https://issues.apache.org/jira/browse/RATIS-49
> Project: Ratis
>  Issue Type: Improvement
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
> Attachments: r49_20170323b.patch, r49_20170323.patch
>
>
> There is no way to remove the shaded source using mvn.  We have to remove 
> them manually by
> - rm -rf ratis-proto-shaded/src/main/java
> - rm -rf ratis-hadoop-shaded/src/main/java



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-47) Shade google guava and combine ratis-netty-shaded with ratis-proto-shaded

2017-03-21 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15935648#comment-15935648
 ] 

Enis Soztutar commented on RATIS-47:


Offline, Nicholas helped me with adding the {{-Dshade-hadoop}} argument. Now it 
works. Somehow my maven does not pick it up by default. I think we require mvn 
3.2+ which is fine. 

> Shade google guava and combine ratis-netty-shaded with ratis-proto-shaded
> -
>
> Key: RATIS-47
> URL: https://issues.apache.org/jira/browse/RATIS-47
> Project: Ratis
>  Issue Type: Improvement
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
> Fix For: 0.1
>
> Attachments: r47_20170317.patch, r47_20170320.patch
>
>
> Even we do not use google guava internally, gRPC still depends on it.  
> Therefore, we need to shade it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-47) Shade google guava and combine ratis-netty-shaded with ratis-proto-shaded

2017-03-21 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15935636#comment-15935636
 ] 

Enis Soztutar commented on RATIS-47:


I am getting compilation errors in the recent code base. Is it only me? 
{code}
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 39.252s
[INFO] Finished at: Tue Mar 21 18:44:12 PDT 2017
[INFO] Final Memory: 49M/553M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.2:compile (default-compile) on 
project ratis-hadoop: Compilation failure: Compilation failure:
[ERROR] 
/Users/enis/projects/git-repos/ratis/ratis-hadoop/src/main/java/org/apache/hadoop/ipc/ProtobufRpcEngineShaded.java:[38,86]
 package 
org.apache.ratis.shaded.org.apache.hadoop.ipc.protobuf.ProtobufRpcEngineProtos 
does not exist
[ERROR] 
/Users/enis/projects/git-repos/ratis/ratis-hadoop/src/main/java/org/apache/hadoop/ipc/ProtobufRpcEngineShaded.java:[39,78]
 package org.apache.ratis.shaded.org.apache.hadoop.ipc.protobuf.RpcHeaderProtos 
does not exist
[ERROR] 
/Users/enis/projects/git-repos/ratis/ratis-hadoop/src/main/java/org/apache/hadoop/ipc/ProtobufRpcEngineShaded.java:[40,78]
 package org.apache.ratis.shaded.org.apache.hadoop.ipc.protobuf.RpcHeaderProtos 
does not exist
[ERROR] 
/Users/enis/projects/git-repos/ratis/ratis-hadoop/src/main/java/org/apache/hadoop/ipc/ProtobufRpcEngineShaded.java:[142,13]
 cannot find symbol
{code}

> Shade google guava and combine ratis-netty-shaded with ratis-proto-shaded
> -
>
> Key: RATIS-47
> URL: https://issues.apache.org/jira/browse/RATIS-47
> Project: Ratis
>  Issue Type: Improvement
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
> Fix For: 0.1
>
> Attachments: r47_20170317.patch, r47_20170320.patch
>
>
> Even we do not use google guava internally, gRPC still depends on it.  
> Therefore, we need to shade it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-6) Project logo

2017-03-16 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15928875#comment-15928875
 ] 

Enis Soztutar commented on RATIS-6:
---

Thanks Will. I like option 6, but it looks too similar to Kafka's? 

> Project logo
> 
>
> Key: RATIS-6
> URL: https://issues.apache.org/jira/browse/RATIS-6
> Project: Ratis
>  Issue Type: Task
>Reporter: Enis Soztutar
> Attachments: Ratis.png
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (RATIS-40) Replicated Map

2017-03-10 Thread Enis Soztutar (JIRA)

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

Enis Soztutar updated RATIS-40:
---
Attachment: ratis-40_v1.patch

v1 contains bunch of code, and bunch more TODO. But it is a good start I think. 
Need RATIS-26 and the bin scripts. 

> Replicated Map
> --
>
> Key: RATIS-40
> URL: https://issues.apache.org/jira/browse/RATIS-40
> Project: Ratis
>  Issue Type: New Feature
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 0.1
>
> Attachments: ratis-40_v1.patch
>
>
> Ratis replicated map is an implementation of a sorted map (think TreeMap) as 
> a replicated state machine. This is not under examples because it is intended 
> to be used in production where a simple in-memory map is sufficient to hold 
> the data. The data is fully cached in memory, but it is still durable since 
> raft log is used as a replicated log, and data is snapshotted periodically.
> The replicated map (RMap) is not only the state machine implementation, but 
> all of the remaining code, including the client and querying capabilities 
> which is built on top of the other modules. In that sense, it is dog-fooding 
> the ratis library to implement an end-to-end solution for a replicated 
> in-memory data store.
> Replicated maps are conceptually similar to ZooKeeper/Etcd/LogCabin where the 
> data is hosted in a known cluster configuration and is not sharded. All the 
> servers in the cluster participate in a single RAFT ring.
> The data model is that users can create independent RMap instances in the 
> cluster and read / write or scan the data as key value pairs in those 
> replicated maps. A replicated map named the meta map contains information 
> about all of the other maps in the cluster.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (RATIS-40) Replicated Map

2017-03-10 Thread Enis Soztutar (JIRA)
Enis Soztutar created RATIS-40:
--

 Summary: Replicated Map
 Key: RATIS-40
 URL: https://issues.apache.org/jira/browse/RATIS-40
 Project: Ratis
  Issue Type: New Feature
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 0.1


Ratis replicated map is an implementation of a sorted map (think TreeMap) as a 
replicated state machine. This is not under examples because it is intended to 
be used in production where a simple in-memory map is sufficient to hold the 
data. The data is fully cached in memory, but it is still durable since raft 
log is used as a replicated log, and data is snapshotted periodically.

The replicated map (RMap) is not only the state machine implementation, but all 
of the remaining code, including the client and querying capabilities which is 
built on top of the other modules. In that sense, it is dog-fooding the ratis 
library to implement an end-to-end solution for a replicated in-memory data 
store.

Replicated maps are conceptually similar to ZooKeeper/Etcd/LogCabin where the 
data is hosted in a known cluster configuration and is not sharded. All the 
servers in the cluster participate in a single RAFT ring.

The data model is that users can create independent RMap instances in the 
cluster and read / write or scan the data as key value pairs in those 
replicated maps. A replicated map named the meta map contains information about 
all of the other maps in the cluster.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-23) Add distribution management to the pom.

2017-03-06 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15898435#comment-15898435
 ] 

Enis Soztutar commented on RATIS-23:


Apache parent pom already contains these, no? 
https://svn.apache.org/viewvc/maven/pom/tags/apache-18/pom.xml?view=markup

> Add distribution management to the pom.
> ---
>
> Key: RATIS-23
> URL: https://issues.apache.org/jira/browse/RATIS-23
> Project: Ratis
>  Issue Type: Bug
>Reporter: Jitendra Nath Pandey
>Assignee: Jitendra Nath Pandey
> Attachments: RATIS-23.patch
>
>
> A distributionManagement section should be added to the pom, for releases as 
> well as snapshots.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-33) Protobuf gets compiled only when both activation conditions are triggered

2017-03-02 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15893161#comment-15893161
 ] 

Enis Soztutar commented on RATIS-33:


Offline conversation, it seems that maven did an incompatible change in profile 
activation, and took away the "OR" functionality without any replacement. 
Typical. 
Anyway +1 for the patch. Let's not spend too much time on this. 

> Protobuf gets compiled only when both activation conditions are triggered
> -
>
> Key: RATIS-33
> URL: https://issues.apache.org/jira/browse/RATIS-33
> Project: Ratis
>  Issue Type: Bug
>Reporter: Jing Zhao
>Assignee: Jing Zhao
> Attachments: RATIS-33.000.patch, RATIS-33.001.patch, 
> RATIS-33.002.patch
>
>
> In RATIS-26 we specify the following activation conditions for compiling 
> protobuf files:
> {code}
>   
> 
> 
>   ${sources.dir}
> 
> 
>   compile-protobuf
> 
>   
> {code}
> This does not work after maven version 3.2.2, due to MNG-4565 that changes 
> the activation condition relationships from OR to AND. Thus we have to do 
> both 1) delete ratis-proto-shaded/src/main/java, and 2) include 
> -Dcompile-protobuf in the command to trigger the protobuf compilation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-33) Protobuf gets compiled only when both activation conditions are triggered

2017-03-02 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15893063#comment-15893063
 ] 

Enis Soztutar commented on RATIS-33:


Does {{mvn clean test}} work? The new profile skipCompileProto does not do 
anything, maybe I may not be getting it right. 

> Protobuf gets compiled only when both activation conditions are triggered
> -
>
> Key: RATIS-33
> URL: https://issues.apache.org/jira/browse/RATIS-33
> Project: Ratis
>  Issue Type: Bug
>Reporter: Jing Zhao
>Assignee: Jing Zhao
> Attachments: RATIS-33.000.patch, RATIS-33.001.patch, 
> RATIS-33.002.patch
>
>
> In RATIS-26 we specify the following activation conditions for compiling 
> protobuf files:
> {code}
>   
> 
> 
>   ${sources.dir}
> 
> 
>   compile-protobuf
> 
>   
> {code}
> This does not work after maven version 3.2.2, due to MNG-4565 that changes 
> the activation condition relationships from OR to AND. Thus we have to do 
> both 1) delete ratis-proto-shaded/src/main/java, and 2) include 
> -Dcompile-protobuf in the command to trigger the protobuf compilation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-33) Protobuf gets compiled only when both activation conditions are triggered

2017-02-28 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15889262#comment-15889262
 ] 

Enis Soztutar commented on RATIS-33:


I think the problem I was running into before is something like this: 
 - mvn shading and unpacking the jar contents only happens in the "package" 
phase. So, if the profile is enabled by default, and you run just {{mvn 
compile}} or {{mvn test}}, the protoc compilation will happen, but it won't do 
the shading. That is why I went with the setup where the protoc only runs if 
the generated directory is not there. Otherwise, we have already generated the 
files and shaded them by unpacking the jar, so we treat those files as if they 
are regular source code. 
{{mvn clean test}} cannot run the shading, because the mvn-shade plugin only 
operates at a later stage then {{test}}. 

> Protobuf gets compiled only when both activation conditions are triggered
> -
>
> Key: RATIS-33
> URL: https://issues.apache.org/jira/browse/RATIS-33
> Project: Ratis
>  Issue Type: Bug
>Reporter: Jing Zhao
>Assignee: Jing Zhao
> Attachments: RATIS-33.000.patch
>
>
> In RATIS-26 we specify the following activation conditions for compiling 
> protobuf files:
> {code}
>   
> 
> 
>   ${sources.dir}
> 
> 
>   compile-protobuf
> 
>   
> {code}
> This does not work after maven version 3.2.2, due to MNG-4565 that changes 
> the activation condition relationships from OR to AND. Thus we have to do 
> both 1) delete ratis-proto-shaded/src/main/java, and 2) include 
> -Dcompile-protobuf in the command to trigger the protobuf compilation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Comment Edited] (RATIS-26) Flatten maven layout and compile shaded atifacts by default

2017-02-24 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15883920#comment-15883920
 ] 

Enis Soztutar edited comment on RATIS-26 at 2/25/17 1:49 AM:
-

Thanks [~jingzhao] for the review.  
bq. "https://ratis.apache.org"; should be 
"https://incubator.apache.org/projects/ratis.html";
When we have the website (RATIS-5), it will be under https://ratis.apache.org. 
bq. Similarly for some mailing lists related information we may need to change 
"ratis.apache.org" to "ratis.incubator.apache.org"
I have been using the alias in the lists. I think it works. 



was (Author: enis):
Thanks [~jing] for the review.  
bq. "https://ratis.apache.org"; should be 
"https://incubator.apache.org/projects/ratis.html";
When we have the website (RATIS-5), it will be under https://ratis.apache.org. 
bq. Similarly for some mailing lists related information we may need to change 
"ratis.apache.org" to "ratis.incubator.apache.org"
I have been using the alias in the lists. I think it works. 

> Flatten maven layout and compile shaded atifacts by default
> ---
>
> Key: RATIS-26
> URL: https://issues.apache.org/jira/browse/RATIS-26
> Project: Ratis
>  Issue Type: Improvement
>Reporter: Jing Zhao
>Assignee: Enis Soztutar
> Fix For: 0.1
>
> Attachments: RATIS-26.000.patch, ratis-26_v1.patch, 
> ratis-26_v2.patch, ratis-26_v3.patch
>
>
> Currently developers need to enter the ratis-proto-shaded directory and run 
> "mvn package -Dcompile-protobuf" to compile shaded sources. This is not 
> convenient when updating protobuf definitions. We can make this step a 
> default step.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Resolved] (RATIS-26) Flatten maven layout and compile shaded atifacts by default

2017-02-24 Thread Enis Soztutar (JIRA)

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

Enis Soztutar resolved RATIS-26.

   Resolution: Fixed
Fix Version/s: 0.1

Pushed this. 

> Flatten maven layout and compile shaded atifacts by default
> ---
>
> Key: RATIS-26
> URL: https://issues.apache.org/jira/browse/RATIS-26
> Project: Ratis
>  Issue Type: Improvement
>Reporter: Jing Zhao
>Assignee: Enis Soztutar
> Fix For: 0.1
>
> Attachments: RATIS-26.000.patch, ratis-26_v1.patch, 
> ratis-26_v2.patch, ratis-26_v3.patch
>
>
> Currently developers need to enter the ratis-proto-shaded directory and run 
> "mvn package -Dcompile-protobuf" to compile shaded sources. This is not 
> convenient when updating protobuf definitions. We can make this step a 
> default step.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-26) Flatten maven layout and compile shaded atifacts by default

2017-02-24 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15883920#comment-15883920
 ] 

Enis Soztutar commented on RATIS-26:


Thanks [~jing] for the review.  
bq. "https://ratis.apache.org"; should be 
"https://incubator.apache.org/projects/ratis.html";
When we have the website (RATIS-5), it will be under https://ratis.apache.org. 
bq. Similarly for some mailing lists related information we may need to change 
"ratis.apache.org" to "ratis.incubator.apache.org"
I have been using the alias in the lists. I think it works. 

> Flatten maven layout and compile shaded atifacts by default
> ---
>
> Key: RATIS-26
> URL: https://issues.apache.org/jira/browse/RATIS-26
> Project: Ratis
>  Issue Type: Improvement
>Reporter: Jing Zhao
>Assignee: Enis Soztutar
> Attachments: RATIS-26.000.patch, ratis-26_v1.patch, 
> ratis-26_v2.patch, ratis-26_v3.patch
>
>
> Currently developers need to enter the ratis-proto-shaded directory and run 
> "mvn package -Dcompile-protobuf" to compile shaded sources. This is not 
> convenient when updating protobuf definitions. We can make this step a 
> default step.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (RATIS-29) bin/ scripts

2017-02-24 Thread Enis Soztutar (JIRA)

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

Enis Soztutar updated RATIS-29:
---
Attachment: 0001-RATIS-29-bin-scripts.patch

v1. Includes {{bin/ratis}}, {{conf}} and daemon scripts. 
You can do bin/ratis classpath for now. 
Also: 
{code}
bin/ratis org.apache.ratis.util.NativeLibraryChecker
{code}

> bin/ scripts
> 
>
> Key: RATIS-29
> URL: https://issues.apache.org/jira/browse/RATIS-29
> Project: Ratis
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Attachments: 0001-RATIS-29-bin-scripts.patch
>
>
> We need {{bin/}} scripts. I will model those from HBase (and not Hadoop). I 
> am not very fond of Hadoop's layout, and it is unnecessarily complex for 
> ratis for now. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (RATIS-26) Flatten maven layout and compile shaded atifacts by default

2017-02-24 Thread Enis Soztutar (JIRA)

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

Enis Soztutar updated RATIS-26:
---
Summary: Flatten maven layout and compile shaded atifacts by default  (was: 
Make shaded source compilation as a default action)

> Flatten maven layout and compile shaded atifacts by default
> ---
>
> Key: RATIS-26
> URL: https://issues.apache.org/jira/browse/RATIS-26
> Project: Ratis
>  Issue Type: Improvement
>Reporter: Jing Zhao
>Assignee: Enis Soztutar
> Attachments: RATIS-26.000.patch, ratis-26_v1.patch, 
> ratis-26_v2.patch, ratis-26_v3.patch
>
>
> Currently developers need to enter the ratis-proto-shaded directory and run 
> "mvn package -Dcompile-protobuf" to compile shaded sources. This is not 
> convenient when updating protobuf definitions. We can make this step a 
> default step.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (RATIS-29) bin/ scripts

2017-02-24 Thread Enis Soztutar (JIRA)
Enis Soztutar created RATIS-29:
--

 Summary: bin/ scripts
 Key: RATIS-29
 URL: https://issues.apache.org/jira/browse/RATIS-29
 Project: Ratis
  Issue Type: Bug
Reporter: Enis Soztutar
Assignee: Enis Soztutar


We need {{bin/}} scripts. I will model those from HBase (and not Hadoop). I am 
not very fond of Hadoop's layout, and it is unnecessarily complex for ratis for 
now. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (RATIS-26) Make shaded source compilation as a default action

2017-02-23 Thread Enis Soztutar (JIRA)

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

Enis Soztutar updated RATIS-26:
---
Attachment: ratis-26_v3.patch

v3 makes it so that we will only invoke compile-protobuf if the generated 
sources are missing. Once you do a mvn install, the files will be there, so no 
need to re-generate and re-shade. {{mvn install -Dcompile-protobuf}} can be 
used to force-generate those files again. 

Since the generated code is put under src/main/java, if the generated + shaded 
files are already there, the compilation and jar packaging just runs as if the 
code is normally under there (via source checkout). 

See BUILDING.md. 

v3 should be ready to check-in. However, if anybody can test it, it would be 
great. 

> Make shaded source compilation as a default action
> --
>
> Key: RATIS-26
> URL: https://issues.apache.org/jira/browse/RATIS-26
> Project: Ratis
>  Issue Type: Improvement
>Reporter: Jing Zhao
>Assignee: Enis Soztutar
> Attachments: RATIS-26.000.patch, ratis-26_v1.patch, 
> ratis-26_v2.patch, ratis-26_v3.patch
>
>
> Currently developers need to enter the ratis-proto-shaded directory and run 
> "mvn package -Dcompile-protobuf" to compile shaded sources. This is not 
> convenient when updating protobuf definitions. We can make this step a 
> default step.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (RATIS-26) Make shaded source compilation as a default action

2017-02-22 Thread Enis Soztutar (JIRA)

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

Enis Soztutar updated RATIS-26:
---
Attachment: ratis-26_v2.patch

v2 which does some more cleanup, and bringing the poms in line with the ones 
from HBase/Hadoop. Also added release profile, snapshot repositories, various 
project-level sections (mailing lists, etc). 

The tests run with mvn install, but with mvn test, we are still getting 
ClassNotFoundException due to shaded artifacts not being resolved. In HBase, I 
think we solve this by checking in the generated files to maven. If I cannot 
find a way, we can resort to that at worst. 

> Make shaded source compilation as a default action
> --
>
> Key: RATIS-26
> URL: https://issues.apache.org/jira/browse/RATIS-26
> Project: Ratis
>  Issue Type: Improvement
>Reporter: Jing Zhao
>Assignee: Enis Soztutar
> Attachments: RATIS-26.000.patch, ratis-26_v1.patch, ratis-26_v2.patch
>
>
> Currently developers need to enter the ratis-proto-shaded directory and run 
> "mvn package -Dcompile-protobuf" to compile shaded sources. This is not 
> convenient when updating protobuf definitions. We can make this step a 
> default step.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-26) Make shaded source compilation as a default action

2017-02-22 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15879770#comment-15879770
 ] 

Enis Soztutar commented on RATIS-26:


Adding to the TODO list: 
 - assemble the list of licenses in assembly for the tarball (see 
hbase-assembly)

All the tests are failing now with NPE or something with the patch. Maybe 
because of surefire configuration changes? 



> Make shaded source compilation as a default action
> --
>
> Key: RATIS-26
> URL: https://issues.apache.org/jira/browse/RATIS-26
> Project: Ratis
>  Issue Type: Improvement
>Reporter: Jing Zhao
>Assignee: Enis Soztutar
> Attachments: RATIS-26.000.patch, ratis-26_v1.patch
>
>
> Currently developers need to enter the ratis-proto-shaded directory and run 
> "mvn package -Dcompile-protobuf" to compile shaded sources. This is not 
> convenient when updating protobuf definitions. We can make this step a 
> default step.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (RATIS-26) Make shaded source compilation as a default action

2017-02-22 Thread Enis Soztutar (JIRA)

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

Enis Soztutar updated RATIS-26:
---
Attachment: ratis-26_v1.patch

v1 patch (includes Jings patch) as well as some of the above. Let me see 
whether it needs some more cleanup. 

{{mvn clean install}} works for me, even if you do
{code}
rm -rf ratis-proto-shaded/src/main/java/ 
{code}


> Make shaded source compilation as a default action
> --
>
> Key: RATIS-26
> URL: https://issues.apache.org/jira/browse/RATIS-26
> Project: Ratis
>  Issue Type: Improvement
>Reporter: Jing Zhao
>Assignee: Enis Soztutar
> Attachments: RATIS-26.000.patch, ratis-26_v1.patch
>
>
> Currently developers need to enter the ratis-proto-shaded directory and run 
> "mvn package -Dcompile-protobuf" to compile shaded sources. This is not 
> convenient when updating protobuf definitions. We can make this step a 
> default step.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-26) Make shaded source compilation as a default action

2017-02-22 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15879723#comment-15879723
 ] 

Enis Soztutar commented on RATIS-26:


Actually I need to make bigger changes in this patch: 
 - Flatten out the maven structure. It should not be like the hadoop's layout 
with -project and -project-dist, etc. Keep it simple. 
 - Some cleanup in poms 
 - compile + shade by default

Some things to do after this patch: 
 - Add missing sections (developers, mailing lists, etc) to pom. 
 - Clean up dependencies
 - Fix assembly, tarball, etc 


> Make shaded source compilation as a default action
> --
>
> Key: RATIS-26
> URL: https://issues.apache.org/jira/browse/RATIS-26
> Project: Ratis
>  Issue Type: Improvement
>Reporter: Jing Zhao
>Assignee: Enis Soztutar
> Attachments: RATIS-26.000.patch
>
>
> Currently developers need to enter the ratis-proto-shaded directory and run 
> "mvn package -Dcompile-protobuf" to compile shaded sources. This is not 
> convenient when updating protobuf definitions. We can make this step a 
> default step.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-18) A new leader should start serving client requests only after it commits the first leader-placeholder entry

2017-02-17 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15872799#comment-15872799
 ] 

Enis Soztutar commented on RATIS-18:


bq. And this is how we implement it in the current patch
Cool. Sorry, I had not checked the patch in detail. 

> A new leader should start serving client requests only after it commits the 
> first leader-placeholder entry
> --
>
> Key: RATIS-18
> URL: https://issues.apache.org/jira/browse/RATIS-18
> Project: Ratis
>  Issue Type: Sub-task
>Reporter: Jing Zhao
>Assignee: Jing Zhao
> Attachments: RATIS-18.000.patch, RATIS-18.001.patch
>
>
> When a raft peer becomes the new leader, it can commit entries belonging to 
> the previous term only along with the entry with the new term. Before that 
> commit happens, the new leader cannot determine exactly what entries should 
> be applied to the state machine and the retry cache. The retry cache is 
> complete only after the leader commits the first leader-placeholder entry.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-18) A new leader should start serving client requests only after it commits the first leader-placeholder entry

2017-02-17 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15872766#comment-15872766
 ] 

Enis Soztutar commented on RATIS-18:


The leader should also gurantee that all of the committed transactions are 
applied to the state machine before starting to accept reads, no? Different 
issue? 

> A new leader should start serving client requests only after it commits the 
> first leader-placeholder entry
> --
>
> Key: RATIS-18
> URL: https://issues.apache.org/jira/browse/RATIS-18
> Project: Ratis
>  Issue Type: Sub-task
>Reporter: Jing Zhao
>Assignee: Jing Zhao
> Attachments: RATIS-18.000.patch
>
>
> When a raft peer becomes the new leader, it can commit entries belonging to 
> the previous term only along with the entry with the new term. Before that 
> commit happens, the new leader cannot determine exactly what entries should 
> be applied to the state machine and the retry cache. The retry cache is 
> complete only after the leader commits the first leader-placeholder entry.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-14) IP-Clearance for Ratis.

2017-02-07 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15856648#comment-15856648
 ] 

Enis Soztutar commented on RATIS-14:


[~jnp] I think it will help if we include the commit sha in the original 
repository (https://github.com/hortonworks/ratis). 

Does this patch correspond to the content of the latest commit (as of Jan 31th 
2017) {{d16c5c649311c8af3340c3373593821ba67d467f}}? 

The link is: 
https://github.com/hortonworks/ratis/commit/d16c5c649311c8af3340c3373593821ba67d467f

I have compared the commits in the incubator repo from the initial import, with 
sha {{d16c5c649311c8af3340c3373593821ba67d467f}}, and it seems that we are in 
good shape. 

{code}
git clone http://git.apache.org/incubator-ratis.git
git clone  https://github.com/hortonworks/ratis.git ratis-legacy
cd incubator-ratis
git checkout d16c5c649311c8af3340c3373593821ba67d467f  
diff -r ../ratis-legacy/ . -x .git -x .project -x .settings -x target -x 
.classpath -x "*.iml" -x .idea
{code}

Obviously, the sha's in both repos are the same up to 
{{d16c5c649311c8af3340c3373593821ba67d467f}} by design. 


> IP-Clearance for Ratis.
> ---
>
> Key: RATIS-14
> URL: https://issues.apache.org/jira/browse/RATIS-14
> Project: Ratis
>  Issue Type: Bug
>Reporter: Jitendra Nath Pandey
>Assignee: Jitendra Nath Pandey
> Attachments: ratis.patch
>
>
> Ensure ip-clearance documents are provided for Ratis.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-13) Add global unique ID for Raft Client

2017-02-03 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15852371#comment-15852371
 ] 

Enis Soztutar commented on RATIS-13:


+1. I was looking at that recently. Maybe do a ClientId class and use 
pseudo-random UUIDs. 

> Add global unique ID for Raft Client
> 
>
> Key: RATIS-13
> URL: https://issues.apache.org/jira/browse/RATIS-13
> Project: Ratis
>  Issue Type: Sub-task
>Reporter: Jing Zhao
>Assignee: Jing Zhao
>
> Similar idea as HADOOP-9688. But since we need to support various RPC 
> engines, the client id is not added in the RPC layer but in the raft protocol 
> layer.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (RATIS-6) Project logo

2017-02-01 Thread Enis Soztutar (JIRA)
Enis Soztutar created RATIS-6:
-

 Summary: Project logo
 Key: RATIS-6
 URL: https://issues.apache.org/jira/browse/RATIS-6
 Project: Ratis
  Issue Type: Task
Reporter: Enis Soztutar






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (RATIS-5) Setup website

2017-02-01 Thread Enis Soztutar (JIRA)
Enis Soztutar created RATIS-5:
-

 Summary: Setup website
 Key: RATIS-5
 URL: https://issues.apache.org/jira/browse/RATIS-5
 Project: Ratis
  Issue Type: Task
Reporter: Enis Soztutar


A project website is needed. Possibly, we can use bootstrap and fork already 
existing syles. 

https://phoenix.apache.org/
https://hbase.apache.org/
https://cassandra.apache.org/



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (RATIS-4) Setup jenkins

2017-02-01 Thread Enis Soztutar (JIRA)
Enis Soztutar created RATIS-4:
-

 Summary: Setup jenkins 
 Key: RATIS-4
 URL: https://issues.apache.org/jira/browse/RATIS-4
 Project: Ratis
  Issue Type: Task
Reporter: Enis Soztutar


Jenkins unit test builds should be set up. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (RATIS-3) Setup hadoopqa builds

2017-02-01 Thread Enis Soztutar (JIRA)

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

Enis Soztutar updated RATIS-3:
--
Description: A precommit checker would be pretty useful. We can use yetus 
for this, or do the old way via cloning the hadoopqa script. Our mvn structure 
is very similar, so should not be a hard issue. 

> Setup hadoopqa builds
> -
>
> Key: RATIS-3
> URL: https://issues.apache.org/jira/browse/RATIS-3
> Project: Ratis
>  Issue Type: Task
>Reporter: Enis Soztutar
>
> A precommit checker would be pretty useful. We can use yetus for this, or do 
> the old way via cloning the hadoopqa script. Our mvn structure is very 
> similar, so should not be a hard issue. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (RATIS-3) Setup hadoopqa builds

2017-02-01 Thread Enis Soztutar (JIRA)
Enis Soztutar created RATIS-3:
-

 Summary: Setup hadoopqa builds
 Key: RATIS-3
 URL: https://issues.apache.org/jira/browse/RATIS-3
 Project: Ratis
  Issue Type: Task
Reporter: Enis Soztutar






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RATIS-2) Change version to 0.1-SNAPSHOT

2017-02-01 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/RATIS-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15849062#comment-15849062
 ] 

Enis Soztutar commented on RATIS-2:
---

+1. 

> Change version to 0.1-SNAPSHOT
> --
>
> Key: RATIS-2
> URL: https://issues.apache.org/jira/browse/RATIS-2
> Project: Ratis
>  Issue Type: Task
>Reporter: Enis Soztutar
>Assignee: Jing Zhao
> Attachments: RATIS-2.000.patch
>
>
> I think we should change the version to 0.1-SNAPSHOT rather than 
> 1.0-SNAPSHOT. We can do a couple of 0.x releases before 1.0. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (RATIS-2) Change version to 0.1-SNAPSHOT

2017-02-01 Thread Enis Soztutar (JIRA)
Enis Soztutar created RATIS-2:
-

 Summary: Change version to 0.1-SNAPSHOT
 Key: RATIS-2
 URL: https://issues.apache.org/jira/browse/RATIS-2
 Project: Ratis
  Issue Type: Task
Reporter: Enis Soztutar


I think we should change the version to 0.1-SNAPSHOT rather than 1.0-SNAPSHOT. 
We can do a couple of 0.x releases before 1.0. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)