Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not short circuit access when client and server are on the same system #191

Open
ksbhaskar opened this issue Mar 26, 2018 · 0 comments
Open

Comments

@ksbhaskar
Copy link
Member

Final Release Note

Description

For any database region mapped by the global directory to a server, but for which the server resides on the same machine, YottaDB database logic short-circuits uses in-memory access logic instead of going through the network stack. However, there are situations when it is desirable to force a connection through the network stack, even when client and server are on the same machine, for example if the client and database are for different releases of YottaDB or when the client has signal handling logic that cannot be made compatible with that of YottaDB.

Draft Release Note

chathaway-codes pushed a commit that referenced this issue Oct 18, 2018
… <hostname> is local host

When <hostname>:<filepath> is specified as the file name in the segment definition in the gld,
at runtime, YottaDB checks if <hostname> is a local host and if so does not go to GT.CM GNP.
Instead avoids using a GNP server, accesses the database locally and avoids network communication
overhead (aka short-circuiting). If not a local host, it goes to the GT.CM GNP server.

But with the @ prefix (i.e. @<hostname>:<filepath>), YottaDB now goes to the GT.CM GNP server
even if <hostname> is a local host.
chathaway-codes pushed a commit that referenced this issue Oct 19, 2018
nars1 added a commit that referenced this issue Dec 12, 2021
… syntax is used

Background
----------
* This is an issue that was observed internally.

* If I create a segment in a global directory that points to a remote host using the `@` syntax
  (support for this syntax was enabled by #191), and I attempt a `mupip create, the `NOCRENETFILE`
  error message (which is expected) has the last character of the database file name removed.

  See below example.

  ```sh
  $ $ydb_dist/yottadb -run GDE change -segment DEFAULT -file=@host:/tmp/yottadb.dat

  $ $ydb_dist/mupip create
  %YDB-E-NOCRENETFILE, Database file @host:/tmp/yottadb.da not created; cannot create across network
  %YDB-E-DBNOCRE, Not all specified database files, or their associated journal files were created
  ```

Issue
-----
* We set `path[pblk.b_esl]` to 0 in `sr_unix/mu_cre_file.c` before issuing the `ERR_NOCRENETFILE`
  error but if `@` syntax was used to specify a node name, `pblk.b_esl` (the length of the full
  path name) would not include the `@` character. And therefore, this would effectively cut out
  the last character of the file name (usually the `t` in a `.dat` file name).

Fix
---
* The initialization of `path[pblk.b_esl]` is moved to after when the `ERR_NOCRENETFILE` error is
  issued. This ensure `path` has the full name that includes the `@` syntax (if specified).

Test
----
* The `r124/ydb191` subtest has been enhanced to test this.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant