[
https://issues.apache.org/jira/browse/IGNITE-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361097#comment-15361097
]
Ivan Veselovsky edited comment on IGNITE-3405 at 7/4/16 9:46 AM:
-----------------------------------------------------------------
{quote} simple 2 nested loops will be enough {quote}
yes, my solution also uses 2 nested loops, just in my solution this loop is
splitted into 2 separate methods. So, please clarify, what is complex and
inefficient, and how we can reduce that?
Please note that my algorithm also fixes possible user's mistakes, e.g. if both
"/a/b" and "/a/b/c" declared to be PRIMARY, it will remove the latter, since
this is a subpath that is already PRIMARY.
{quote} IgfsPath is already comparable.{quote}
Yes, but the default #compareTo() is implemented as String comparison. Here we
need depth comparison, which is different. E.g. strings
x="/a/k", y="/b/c/d", z="/z" are string-compared as (x,y,z) , while
depth-compared as (z,x,y).
What I may suggest to speed up this comparator, is to use path1.depth() -
path2.depth() , #depth() method implemented very fast.
{quote} once and only once on node start. {quote}
yes, this is a good point, I will move path filtering into IgfsImpl(Ctx)
constructor.
was (Author: iveselovskiy):
{quote} simple 2 nested loops will be enough {quote}
yes, my solution also uses 2 nested loops, just in my solution this loop is
splitted into 2 separate methods. So, please clarify, what is complex and
inefficient, and how we can reduce that?
Please note that my algorithm also fixes possible user's mistakes, e.g. if both
"/a/b" and "/a/b/c" declared to be PRIMARY, it will remove the latter, since
this is a subpath that is already PRIMARY.
{quote} IgfsPath is already comparable.{quote}
Yes, but the default #compareTo() is implemented as String comparison. Here we
need depth comparison, which is different. E.g. strings
x="/a/k", y="/b/c/d", z="/z" are string-compared as (x,y,z) , while
depth-compared as (z,x,y).
What I may suggest to speed up this comparator, is to use path1.depth() -
path2.depth() .
{quote} once and only once on node start. {quote}
yes, this is a good point, I will move path filtering into IgfsImpl(Ctx)
constructor.
> IGFS: Do not allow DUAL -> PRIMARY -> DUAL modes interleaving.
> --------------------------------------------------------------
>
> Key: IGNITE-3405
> URL: https://issues.apache.org/jira/browse/IGNITE-3405
> Project: Ignite
> Issue Type: Bug
> Components: IGFS
> Affects Versions: 1.6
> Reporter: Vladimir Ozerov
> Assignee: Ivan Veselovsky
> Priority: Critical
> Fix For: 1.7
>
>
> Currently we allow almost any combinations of path modes. This appears to be
> wrong. Consider the following scenario:
> 1) /dir1 -> PRIMARY
> 2) /dir1/dir2 -> DUAL
> It is impossible to support this scenario properly because {{dir1}} will be
> created in both file systems anyway, but primary and secondary representation
> will be "detached" from each other.
> Instead, we should allow only DUAL -> PRIMARY and DUAL -> PROXY transitions.
> Any other combinations doesn't make sense.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
