com.intersys.globals.GlobalsException occurs when I am trying to call

Andrew Tobilko 25 February 2018

I have a simple app which tries to establish a connection with a Cache database instance via Global API for Java:

import com.intersys.globals.Connection;
import com.intersys.globals.ConnectionContext;

public class Assignment {

    public static void main(String[] args) {
        Connection connection = ConnectionContext.getConnection();
        connection.connect("SAMPLES", "_SYSTEM", "SYS");
    }

}

The expection I am getting:

Exception in thread "main" com.intersys.globals.GlobalsException: lc_conn::connect_device returned Db_err: source: lc_conn::connect() message: lc_conn::connect: CacheSecureStart returned -1:

at com.intersys.globals.internal.GlobalsConnectionJNI.connectImpl(Native Method)
at com.intersys.globals.internal.GlobalsConnectionJNI.connect(GlobalsConnectionJNI.java:107)
at com.tobilko.a3.Assignment.main(Assignment.java:17)

The credentials and the namespace are correct.
The Cache instance has been initialised correctly and by instruction.
All the global environment variables including GLOBALS_HOME and DYLD_LIBRARY_PATH have been set.

The following libraries have been soft-linked:

ln -s $GLOBALS_HOME/bin/libisccache.dylib /usr/local/lib
ln -s $GLOBALS_HOME/bin/liblcbjni.dylib /usr/local/lib
ln -s $GLOBALS_HOME/bin/liblcbindnt.dylib /usr/local/lib
ln -s $GLOBALS_HOME/bin/liblcbclientnt.dylib /usr/local/lib
ln -s $GLOBALS_HOME/bin/libmdsjni.dylib /usr/local/lib

-Djava.library.path=/usr/local/lib has been specified.
The jars have been included.

Any help would be really appreciated.

Reply by Robert Cemper 27 February 2018

From this, I understand that your installation directory is /Cache and /Cache/mgr is the directory of namespace %SYS where System_Management runs. It is where you log in and get directed to SAMPLES by Caché, based on your config file that is then in /Cache/cache.cpf . Caché takes care of it.

Following the last like I found something you should check:

Setting Permissions for Callin Executables on UNIX®

Caché executables, files, and resources such as shared memory and operating system messages, are owned by a user selected at installation time (the installation owner) and a group with a default name of cacheusr (you can choose a different name at installation time). These files and resources are only accessible to processes that either have this user ID or belong to this group. Otherwise, attempting to connect to Caché results in protection errors from the operating system (usually specifying that access is denied); this occurs prior to establishing any connection with Caché. *)

A Callin program can only run if its effective group ID is cacheusr. To meet this condition, one of the following must be true:

The program is run by a user in the cacheusr group (or an alternate run-as group if it was changed from cacheusr to something else).
The program sets its effective user or group by manipulating its uid or gid file permissions (using the UNIX® chgrp and chmod commands).

Conclusion:
*), In fact, you were never connected to Caché - no audit no other trace

In addition, I learned that
JNI access is implemented and handled similarly to C++based CallIn.
So also error messages are similar.
And shdir has the same role as IPaddr:port for TCP connection.

Pls. check if your user is in group cacheusr

+ 3 0

Accepted Answer

Reply by Vivek Ranjan 25 February 2018

I've tried using intersystems provider for jdbc and it's work fine. Below is the sample.

import com.intersys.jdbc.CacheDataSource;
//C:\InterSystems\HealthShare\dev\java\lib\JDK18\cache-jdbc-2.0.0.jar

public class Assignment {

public static void main(String[] args) {

           ConnectionString = "jdbc:Cache://" + localhost+ ":" + 1972+ "/" + "SYS";
           CacheDataSource ds = new CacheDataSource();
           ds.setURL(ConnectionString);
           ds.setUser(UserId);
       ds.setPassword(Password);

System.out.println("Connecting to db....");
java.sql.Connection dbconnection = ds.getConnection();
java.sql.Statement stmt = dbconnection.createStatement();

           System.out.println("Fetching Data from db....");
           String sqlQuery = "SELECT * from table";
           ResultSet rs = stmt.executeQuery(sqlQuery );
}

}

+ 1 0

Reply by Andrew Tobilko 25 February 2018

thank you for the answer, but I need to access globals and I assume Globals API is the only way to do so. JDBC connections work perfectly.

0 0

Where do you provide port no?

Check with intersystems documentation.

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

I use the default configuration, and I haven't specified either port or host. Are there any methods to allow to do that?

Reply by Eduard Lebedyuk 26 February 2018

Add Password.

Reply by Andrew Tobilko 26 February 2018

It didn't help either.

Of course, I read the documentation.

"Unlike the standard Java binding, the Globals API does not use TCP/IP to communicate with Caché. Instead, it used a fast in-memory connection (implemented via standard Java JNI and the Caché Callin API), and runs in the same process as the Caché instance." - that's why JDBC connections may work while Globals API calls may not.

Reply by Robert Cemper 25 February 2018

your connection may also fail if you don't have a free license. TRYCACHE has just one and can't have more.
if you have NO licence only 1 user is allowed.
I have no experience on JNI but you might be rejected if you are logged in in parallel on Terminal or Mgmt portal or studio, ...
In this case log out from any other connection and try JNI.

sounds much like "missing license"

No other connections were established (I logged out from Mgmt portal as well)
I've got a license from my university. It shouldn't be restricted in that way.

Where can I validate my license.key if it might be a potential problem?

http://localhost:57772/csp/sys/mgr/%25CSP.UI.Portal.License.Key.zen

If it's formal valid this should show your license.
Look for OSX or "platform independent"

http://localhost:57772/csp/sys/op/%25CSP.UI.Portal.LicenseUsage.zen
here you see available licenses and used licenses

License Unit Use Local Distributed Current License Units Used 2 2 Maximum License Units Used 2 2 License Units Authorized 10 10 Current Connections 2 2 Maximum Connections 2 2

if the numbers are reasonable your license is OK.
But be aware the free download version IGNORES any license!

25 users, Platform Independent looks good.
Licensing can NOT be the problem !
---

sorry no idea at the moment where CacheSecureStart returned -1: may come from

no direct hint .... but CacheSecurerStart is mentioned.
http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=BXCI_functions#BXCI_functions_cache-secure-start-a
or
http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=BXCI_callin

But did you try unauthenticated access too ?

connection.connect("SAMPLES", "", "");
or
connection.connect("USER", "", "");

Yes, I have tried this as well as connection.connect(). I have tried connecting with incorrect parameters. The result is the same.

Reply by Robert Cemper 26 February 2018

sorry I ran out of ideas.
Your code tries to do a "CacheSecureStart" ( means + user + pw)
_SYSTEM has role %ALL ; you can't have more.
you have no License issue.
????

OS-level access issues maybe?

I've been checking a lot of stuff, and it's what I encountered after checking available instances:

Configuration 'DEFAULTCACHEINSTANCE' (default)
directory: /DefaultCacheInstance
versionid: 2017.1.1.111.0su
status: down, directory may be deleted

Configuration 'DEFAULTINSTANCE'
directory: /DefaultInstance
versionid: 2016.2.1.803.0
conf file: cache.cpf (SuperServer port = 1972, WebServer = 57772)
status: running, since Mon Feb 26 10:39:27 2018
state: warn

 #define CACHE_INVALID_INSTANCE  -17 /* invalid shdir */

there is an article on shdir in docs.

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=BXCI_callin#BXCI_callin_buildunix

I assume: your JNI connection tried to access the wrong instance using a previous shdir.

I reinstalled it again to make sure Unicode support is included. The version though doesn't have `U` at the end.

USER>WRITE $ZV

Cache for UNIX (Apple Mac OS X for x86-64) 2016.2.1 (Build 803U) Wed Oct 26 2016 12:36:07 EDT

that looks fine.
I wonder where shdir is loaded and what the value is.
it shout point to your installation.

There are 2 lines in /Cache/dev/cache/callin/samples/shdir.c:

char shdir[256] = "/Cache/mgr";
const char exeinfo[] = "User";

It's the correct path. The problem is that there is no "previous" shdir.
But how can the samples folder be involved in a JNI connection?

Moved to Answer

Reply by Andrew Tobilko 27 February 2018

Yes, that was the problem. My user didn't belong to the cacheusr group. Now it's working. Thank you a lot!!!

Andrew,
I'm glad we identified the issue.I have converted the solution into an ANSWER.
pls. mark it as accepted so other users may identify the solution at first sight.
thx.

+ 2 0

It means I have two instances, the first one was removed, but it still remains default. I've cleared it, now the system recognises one default instance.

Now sudo ccontrol list gives me:

directory: /Cache
versionid: 2016.2.1.803.0
conf file: cache.cpf  (SuperServer port = 1972, WebServer = 57772)
status:    running, since Mon Feb 26 11:47:09 2018
state:     ok

The app gives me:

lc_conn::connect_device returned Db_err: source: lc_conn::connect() message: lc_conn::connect: CacheSecureStart returned -17: <INVALID_INSTANCE>

2017.1.1.111.0su S stands for single user and is typically a Trial Version with some limits.
U for Unicode
hard to say (for me) if there could be a conflict with the .jars used
as you now run
2016.2.1.803.0 is 8bit NOT unicode.
from Terminal do "WRITE $ZV") to check the full version
2016.2.1 (Build 803U) U=UNICODE
2016.2.1 (Build 803) no U = 8bit.
This should not be an issue with SAMPLES, %SYS, ... in your case though....?

Just to understand it right:
According to your script sniplets you are working on Mac OSX ?
IS this correct?

[System Administration] > [Security] > [Services], select %Service_CallIn, and make sure the Service Enabled box is checked.
Also this ?

Yes, that's correct.
The box is checked, allowed authentication methods: Unauthenticated

Robert, here's a similar issue (by the message we got) https://stackoverflow.com/questions/26104574/issues-while-connecting-to-...

just with a different error code. How can I figure out what -1 there means?

It's worth to mention that there are no audit logs when I run the application (though the audit feature is enabled and all system events should be logged. It logs JDBC login/logouts, for instance).

The call from this issue https://stackoverflow.com/questions/26104574/issues-while-connecting-to-... was registered, any of my requests wasn't.

According to the documentation, -1 means CACHE_FAILURE (an interface error) and for the CacheSecureStart method it means "An unexpected error has occurred." This gives me nothing :)

Reply by Andre Cerri 1 March 2018

Andrew, what version of Caché are you running?

Reply by Andrew Tobilko 25 March 2018

@Andre Cerri Version 2016.2

com.intersys.globals.GlobalsException occurs when I am trying to call connection.connect() with the correct credentials

Primary tabs

Replies