As the result of the post by Bryan Buchanan I have started have a look at the Java API to interact with D3.

I'm working on AlmaLinux 8.9 with D3 10.4 installed.

I have downloaded the file MVSPJavaAPI.zip and successfully compiled and used then MVSPJavaAPI/mvspTest/mvspTest.java program. The program connected instantly and all data accesses were instant.

Using that as my basis I created a console program but ran into an issue with connecting. The connection in my program is taking 2 to 3 seconds to complete. Data access is instant after the connection occurs. At the same time I am seeing the following message lines in /var/log/messages:

Mar 10 20:49:13 Alma8 systemd[1]: Started D3's per connection MVSP server for pick0 (127.0.0.1:53850).

Mar 10 20:49:16 Alma8 systemd[1]: D3MVSPpick0@2-127.0.0.1:9000-127.0.0.1:53850.service: Main process exited, code=exited, status=1/FAILURE

Mar 10 20:49:16 Alma8 systemd[1]: D3MVSPpick0@2-127.0.0.1:9000-127.0.0.1:53850.service: Failed with result 'exit-code'.

I do not see these message lines when using the mvspTest.java program.

I cannot see any significant difference between the code in mvspTest.java and my code that can explain the delay in connecting.

My code is this:

MvspConsole.java

import com.rocketsoftware.mvapi.*;
//import com.rocketsoftware.mvapi.ResultSet.*;
//import com.rocketsoftware.mvapi.exceptions.*;
import java.util.Properties;

class MvspConsole {
    static MVConnection mvspHandle;

    public static void main(String[] args) {
        System.out.println("Started...");

        Properties props = new Properties();
        props.setProperty("username", "jrcar");
        props.setProperty("password", "0xygen16");

        String url = "jdbc:mv:D3:localhost:9000";
        mvspConnect(url, props);

        mvspLogto("mvdemo", "");

        mvspRead("customers", "12");

        mvspClose();
    }

    static void mvspConnect(String url, Properties props){
        System.out.println("Connecting...");
        try {
                mvspHandle = new MVConnection(url, props);
        }
        catch (Exception ex){
            System.out.println("new MVConnection: Unexpected exception: " +  ex.toString());
            System.out.println("  : " + ex.getMessage());
            System.out.println("Cause: " + ex.getCause());
            return;
        }
        System.out.println("Connected");
    }

    static void mvspClose(){
        try {
            mvspHandle.close();
        } catch (Exception ex) {
            System.out.println("Couldn't close mvcHandle");
        }
    }

    static void mvspLogto(String account, String pwd){
        try {
            mvspHandle.logTo(account, pwd);
            System.out.println("Logto: " + account);
        } catch (Exception ex) {
            System.out.println("Exception: " + ex.toString());
            System.out.println("  : " + ex.getMessage());
        }
    }

    static void mvspRead(String fileName, String id){
        try {
            String item = mvspHandle.fileRead(fileName, id);
            item = mvspHandle.swap(item, MVConstants.AM, "|");
            System.out.println("Read item ...");
            System.out.println(item);
        } catch (Exception ex) {
            System.out.println("Exception: " + ex.toString());
            System.out.println("  : " + ex.getMessage());
        }
    }
}

Any help would be appreciated.

PS: I have tried to post this in the more generic forum but I can't see if that succeeded. My apologies if this turns out to be a repeat post.

Follow up on my post.

I have done some further testing and discovered my original observations were flawed.

mvspTest.java DOES have a 3 second delay on creating the connection. 

The error messages I found in /var/log/messages also occur with mvspTest.java but only when I close the connection. I didn't notice this before.

So, it appears to me that it takes 3 seconds to start up D3's per connection MVSP server.

I have the same problem and I started a ticket with Rocket yesterday. 

We' re using D3/Linux 10.2 and I've nailed it down to the -m option applied to the d3_tel program that connects your socket to a d3 process logged in as MVSP.  You can see this in the /etc/xinetd.d/D3MVSPpick0 file that processes the connection request.  Assuming of course you're on a Linux server. 

You can see this if you "telnet 0 9000" (assuming 9000 is the port your MVSP is listening on) there will be a noticeable delay before the MVSP welcome text is displayed.  Type EXIT to close that test connection.  If you then remove the -m then the connection and login is instant, but MVS doesn't work.  How/why anyone is able to use MVS and tolerate this delay leads me to believe they don't experience it and it must be something about my environment.

I'm waiting for Brian Cramm to jump in to help solve it.

Solution for me was to install the latest MVS toolkit. This resolved the delay issue.  However, I'm pretty sure it only applies to MVS and not the Java API.  Rocket support would have to clarify.

Follow up on my post.

I have done some further testing and discovered my original observations were flawed.

mvspTest.java DOES have a 3 second delay on creating the connection. 

The error messages I found in /var/log/messages also occur with mvspTest.java but only when I close the connection. I didn't notice this before.

So, it appears to me that it takes 3 seconds to start up D3's per connection MVSP server.

Problem was fixed in a Java API version that is not publicly available. Tom, yours is Toolkit related and no longer an issue. James, are you interested in the lastest Java API or have you abandoned the project?

Hi James,

I tried your test program, and yes it does take 3 seconds to connect. IMO this is not a show stopper because:

a) if you're using this with a web app, you'd want to instantiate all the connections you plan to have when the web server starts (or you re-load an updated WAR).

You could use a connection pool (which you'd normally do if your backend was Postgresql or the like) . I think Rocket do have some sort connection pooling product.

In my sample code I used a ConcurrentHashMap to save the initially created connections, so it acts like a connection pool.

b) if you're making a desktop app, presumably you've a GUI front end, and you most likely sign in for the day once, so you can have some sort of waiting graphic display so it doesn't seem nothing is happening.  (You could obviously also do the same if you have a browser based app and you want to get a persistent connection - Connection.ping() is your friend in that case)

Bryan