You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by "Ivan V." <iv...@gridgain.com> on 2015/11/11 11:47:57 UTC
IGFS URI authority: simplify handling of IGFS and Grid names.
Hi, dev,
currently IGFS URI has form
igfs://[igfs-name[:grid-name]]@[host[:port]]/[path] .
This connection can be established with "in-process" routine (used mostly
in tests), or with SHMEM, or with TCP protocol.
Current logic of "igfs-name" and "grid-name" handling is as follows.
In case of in-proc routine the Ignite process is asked for named Grid and
its IGFS, null names mean default instances.
In case of external process connection (to "host:port" specified in the
URI) there is a restriction that the name of connected IGFS and Grid must
exactly match "igfs-name" and "grid-name" specified in the URI. But that
rule leads to the following (may be unexpected) behavior: if URI is
"igfs://localhost:10500/", the IGFS name and Grid names are null-s, and the
name match rule requires the connected IGFS and Grid to be default. And if
that is not the case, an exception is thrown. This situation has happened
with a user, and described in
https://issues.apache.org/jira/browse/IGNITE-1566 .
In order to fix the problem and improve the usability, I would suggest to
relax the name handling logic in the following way: in case of external
connection treat unspecified Igfs and Grid names as a direction to connect
to the Grid/Igfs that owns the connection port (not more than one such pair
exists).
Any objections, corrections, thoughts?
Thanks in advance.
Re: IGFS URI authority: simplify handling of IGFS and Grid names.
Posted by "Ivan V." <iv...@gridgain.com>.
Hi, Dmitriy,
null Grid name and null Igfs name mean the default Grid and Igfs
respectively.
In case of in-process connection, URI without specified grid and/or igfs
name means to connect to the default (null-named) Grid and/or Igfs.
If this contract makes sense, we should not prohibit nulls.
On Wed, Nov 11, 2015 at 9:11 PM, Dmitriy Setrakyan <ds...@apache.org>
wrote:
> I also agree (I think). Would prohibiting nulls also make sense?
>
> On Wed, Nov 11, 2015 at 4:04 AM, Vladimir Ozerov <vo...@gridgain.com>
> wrote:
>
> > +1
> >
> > User should have minimal chance to do a mistake in common scenarios.
> >
> > On Wed, Nov 11, 2015 at 1:47 PM, Ivan V. <iv...@gridgain.com>
> > wrote:
> >
> > > Hi, dev,
> > > currently IGFS URI has form
> > > igfs://[igfs-name[:grid-name]]@[host[:port]]/[path] .
> > > This connection can be established with "in-process" routine (used
> mostly
> > > in tests), or with SHMEM, or with TCP protocol.
> > > Current logic of "igfs-name" and "grid-name" handling is as follows.
> > > In case of in-proc routine the Ignite process is asked for named Grid
> and
> > > its IGFS, null names mean default instances.
> > > In case of external process connection (to "host:port" specified in the
> > > URI) there is a restriction that the name of connected IGFS and Grid
> must
> > > exactly match "igfs-name" and "grid-name" specified in the URI. But
> that
> > > rule leads to the following (may be unexpected) behavior: if URI is
> > > "igfs://localhost:10500/", the IGFS name and Grid names are null-s, and
> > the
> > > name match rule requires the connected IGFS and Grid to be default. And
> > if
> > > that is not the case, an exception is thrown. This situation has
> happened
> > > with a user, and described in
> > > https://issues.apache.org/jira/browse/IGNITE-1566 .
> > > In order to fix the problem and improve the usability, I would suggest
> to
> > > relax the name handling logic in the following way: in case of external
> > > connection treat unspecified Igfs and Grid names as a direction to
> > connect
> > > to the Grid/Igfs that owns the connection port (not more than one such
> > pair
> > > exists).
> > > Any objections, corrections, thoughts?
> > > Thanks in advance.
> > >
> >
>
Re: IGFS URI authority: simplify handling of IGFS and Grid names.
Posted by Dmitriy Setrakyan <ds...@apache.org>.
I also agree (I think). Would prohibiting nulls also make sense?
On Wed, Nov 11, 2015 at 4:04 AM, Vladimir Ozerov <vo...@gridgain.com>
wrote:
> +1
>
> User should have minimal chance to do a mistake in common scenarios.
>
> On Wed, Nov 11, 2015 at 1:47 PM, Ivan V. <iv...@gridgain.com>
> wrote:
>
> > Hi, dev,
> > currently IGFS URI has form
> > igfs://[igfs-name[:grid-name]]@[host[:port]]/[path] .
> > This connection can be established with "in-process" routine (used mostly
> > in tests), or with SHMEM, or with TCP protocol.
> > Current logic of "igfs-name" and "grid-name" handling is as follows.
> > In case of in-proc routine the Ignite process is asked for named Grid and
> > its IGFS, null names mean default instances.
> > In case of external process connection (to "host:port" specified in the
> > URI) there is a restriction that the name of connected IGFS and Grid must
> > exactly match "igfs-name" and "grid-name" specified in the URI. But that
> > rule leads to the following (may be unexpected) behavior: if URI is
> > "igfs://localhost:10500/", the IGFS name and Grid names are null-s, and
> the
> > name match rule requires the connected IGFS and Grid to be default. And
> if
> > that is not the case, an exception is thrown. This situation has happened
> > with a user, and described in
> > https://issues.apache.org/jira/browse/IGNITE-1566 .
> > In order to fix the problem and improve the usability, I would suggest to
> > relax the name handling logic in the following way: in case of external
> > connection treat unspecified Igfs and Grid names as a direction to
> connect
> > to the Grid/Igfs that owns the connection port (not more than one such
> pair
> > exists).
> > Any objections, corrections, thoughts?
> > Thanks in advance.
> >
>
Re: IGFS URI authority: simplify handling of IGFS and Grid names.
Posted by Vladimir Ozerov <vo...@gridgain.com>.
+1
User should have minimal chance to do a mistake in common scenarios.
On Wed, Nov 11, 2015 at 1:47 PM, Ivan V. <iv...@gridgain.com> wrote:
> Hi, dev,
> currently IGFS URI has form
> igfs://[igfs-name[:grid-name]]@[host[:port]]/[path] .
> This connection can be established with "in-process" routine (used mostly
> in tests), or with SHMEM, or with TCP protocol.
> Current logic of "igfs-name" and "grid-name" handling is as follows.
> In case of in-proc routine the Ignite process is asked for named Grid and
> its IGFS, null names mean default instances.
> In case of external process connection (to "host:port" specified in the
> URI) there is a restriction that the name of connected IGFS and Grid must
> exactly match "igfs-name" and "grid-name" specified in the URI. But that
> rule leads to the following (may be unexpected) behavior: if URI is
> "igfs://localhost:10500/", the IGFS name and Grid names are null-s, and the
> name match rule requires the connected IGFS and Grid to be default. And if
> that is not the case, an exception is thrown. This situation has happened
> with a user, and described in
> https://issues.apache.org/jira/browse/IGNITE-1566 .
> In order to fix the problem and improve the usability, I would suggest to
> relax the name handling logic in the following way: in case of external
> connection treat unspecified Igfs and Grid names as a direction to connect
> to the Grid/Igfs that owns the connection port (not more than one such pair
> exists).
> Any objections, corrections, thoughts?
> Thanks in advance.
>