, ,

Join The Works program to have access to the most current content, and to be able to ask questions and get answers from Revelation staff and the Revelation community

NetOI Stops Responding (OpenInsight 32-bit)

At 16 JUL 2020 07:56:21AM Rich Channer wrote:

Hi Friends,

I have a recurring fail when using NetOI occurring after a few connect/disconnects…

I’m connecting to an OESocketServer (Version: 3.0.0.411)

Oinsight Version: 9.4.4

RevelationDotNet.dll Properties: 9.5.0.0

I have built the following test code in c#.net - now, this may well not be the most efficient way of doing this (Connecting and disconnecting each time), but I don’t understand why it works for the first 6 times, then hangs during the disconnect - any thoughts?

Cheers, Rich

      static void Main(string[] args)
      {
          string serverName = "localhost";
          string port = "8088";
          string username = "SYSPROG";
          string password = "";
          string applicationName = "SYSPROG";
          string oiLocation = "";
          Server myServer = new Server();
          System.Console.WriteLine("NetOI Version: " + myServer.Version);
          for (int i = 0; i < 1000; i++)
          {
              myServer.OIConnect(serverName, port, applicationName, username, password, oiLocation);
              OIFile oiFile = myServer.OpenFile("SYSENV");
              OIRecord oiRecord = myServer.ReadRecord(oiFile, "CFG_OIPI");
              System.Console.WriteLine(i);
              oiFile.Close();
              System.Console.WriteLine("About to Disconnect - Connection Status: " + myServer.connectionStatus);
              try
              {
                  myServer.OIDisconnect();
              } 
              catch (Exception e)
              {
                  System.Console.WriteLine("Error: " + e.Message);
              }
              System.Console.WriteLine("Disconnected");
              //System.Threading.Thread.Sleep(10000);
              System.Console.WriteLine("");
          }
          myServer.OIDisconnect();
      }

Outputs:…

NetOI Version: 1.0.0.0

0

About to Disconnect - Connection Status: True

Disconnected

1

About to Disconnect - Connection Status: True

Disconnected

2

About to Disconnect - Connection Status: True

Disconnected

3

About to Disconnect - Connection Status: True

Disconnected

4

About to Disconnect - Connection Status: True

Disconnected

5

About to Disconnect - Connection Status: True

Disconnected

6

About to Disconnect - Connection Status: True


At 16 JUL 2020 08:16AM bshumsky wrote:

Hi, Rich. Maybe it's related to having the connection open and close so quickly? If you have your engine server running in 'debug' mode (rather than as a service), you could see the engines start and stop. What is apparently going on during the 'failure' case?

- Bryan Shumsky

Revelation Software, Inc.


At 16 JUL 2020 10:59AM Rich Channer wrote:

Hi Bryan,

Thanks for your response - apologies for the long threads…!

I considered the speed of connection as being the issue, but even with a 10 second forced pause between loops, I still hit the same issue.

The 5 connect/open/reads that work, are all identical, ending with the following output from the socketserver:

(there are 157 lines per loop, these are just the last ones)

doing CALL

Returning *0*

Writing response: *000000030*

have *11* chars to output

output *11*, have *0* left to output

read in 00000002

Originally received request: *2*

In state *1*, asked to execute command *2*, *1* parameters

Requeuing synchronous engine (if required)

Checking SYNCHRONOUS engine #1 for existing engine match

Found match in synchronous list - exiting

In LOGGED IN state

JD3 mode: original call is *2*, new call is *4*

doing CALL

Returning *5*

Writing response: *000000025*

have *10* chars to output

output *10*, have *0* left to output

In OEngineFactory: RemoveEngine - removing used engine from lSynchronous

Have 1 entries to check

checking entry #0

found the entry in the lSynchronous

Closing engine

read in 00000002

Originally received request: *2*

In state *0*, asked to execute command *2*, *1* parameters

In LOGGED OUT state

However, on the one that fails,

0-130 lines are identical, but then I get (differences marked in bold):

doing CALL

Returning *0*

Writing response: *000000030*

have *11* chars to output

output *11*, have *0* left to output

read in 00000006 Originally received request: *32?1* In state *1*, asked to execute command *3*, *2* parameters

Requeuing synchronous engine (if required)

Checking SYNCHRONOUS engine #1 for existing engine match

Found match in synchronous list - exiting

In LOGGED IN state

JD3 mode: original call is *3*, new call is *4*

doing CALL

Returning *0* Writing response: *000000030* have *11* chars to output output *11*, have *0* left to output read in 00000008 Originally received request: *313?1?* In state *1*, asked to execute command *3*, *2* parameters Requeuing synchronous engine (if required) Checking SYNCHRONOUS engine #1 for existing engine match Found match in synchronous list - exiting In LOGGED IN state JD3 mode: original call is *3*, new call is *4* doing CALL Returning *5*

Writing response: *000000025*

have *10* chars to output

output *10*, have *0* left to output

This is where it hangs…

Cheers, Rich


At 16 JUL 2020 02:57PM bshumsky wrote:

Hi, Rich. Let's see if it helps (or hurts) to destroy and create the object each loop. So can you change your code to this:

static void Main(string[] args)

{

string serverName = "localhost";

string port = "8088";

string username = "SYSPROG";

string password = "";

string applicationName = "SYSPROG";

string oiLocation = "";

Server myServer; bzs for (int i = 0; i < 1000; i++) { myServer = new Server(); bzs

System.Console.WriteLine("NetOI Version: " + myServer.Version); bzs myServer.OIConnect(serverName, port, applicationName, username, password, oiLocation); OIFile oiFile = myServer.OpenFile("SYSENV"); OIRecord oiRecord = myServer.ReadRecord(oiFile, "CFG_OIPI"); System.Console.WriteLine(i); oiFile.Close(); System.Console.WriteLine("About to Disconnect - Connection Status: " + myServer.connectionStatus); try { myServer.OIDisconnect(); } catch (Exception e) { System.Console.WriteLine("Error: " + e.Message); } System.Console.WriteLine("Disconnected"); System.Threading.Thread.Sleep(10000);

myServer = null; bzs System.Console.WriteLine(""); } bzs myServer.OIDisconnect();

}

(I marked the changed/moved lines with bzs). Let me know how/if that changes things? Thanks, - Bryan Shumsky Revelation Software, Inc. </QUOTE> —- === At 17 JUL 2020 05:27AM Rich Channer wrote: === <QUOTE>Hi Bryan, Thanks for the speedy suggestion - that did work, and we can now move on with developing and testing. Just one more request, are there any other notes relating to NetOI other than the NETOI chm ? The doc is a good reference point for properties and methods but I can't find anything relating to "best practice" such as what and what not to do, or 'how to…' for example, other than what is contained in the example VB project. Thanks again, Rich </QUOTE> —- === At 17 JUL 2020 07:05AM Rich Channer wrote: === <QUOTE>Hi Again… :) As a follow up to my last post, requesting best practice etc. I’m also having issues around files for (int i = 0; i < 10; i++) { oiFile = myServer.OpenFile("SYSENV"); OIRecord oiRecord = myServer.ReadRecord(oiFile, "CFG_OIPI"); oiFile.Close(); oiFile = null; } This will only work 3-4 times before hanging. However: oiFile = myServer.OpenFile("SYSENV"); oiFile.Close(); for (int i = 0; i < 10; i++) { oiFile.Open(); OIRecord oiRecord = myServer.ReadRecord(oiFile, "CFG_OIPI"); oiFile.Close(); } This will work for (seemingly) as long as I want to wait. BUT, I’ve noticed that not Closing a file, and doing a lot of reads, can cause issues when disconnecting. (Seemingly hung, and OEngine started eating up all of the memory) I’ve yet to replicate that in these tests, that was actually What I was trying to do when I hit these issues. I’m just concerned that either my environment is set up wrong, or else I’m trying to use it wrong in some way, as these issues seem far too easy to hit, and once you do there is no way to rescue from them. Cheers, Rich </QUOTE> —- === At 17 JUL 2020 03:19PM bshumsky wrote: === <QUOTE>Hi, Rich. Glad to hear that that workaround seems to have solved it for now. I'll keep investigating why your original code wouldn't work, and see if I can find a bug to fix. Unfortunately, I don't think there's anything like a "best practices" doc, or even many other examples. We've never really had a "library sharing" model for NetOI routines, so I think most people go off, develop what they need…and that's it. We don't usually get anyone coming back with any "here's how I succeeded" stories, only the occasional "this didn't work" posts (like yours) which we hopefully can fix on a case-by-case basis. Now, there might have been more posts about NetOI that were lost when our servers were attacked at the end of last year, and everything had to be restored or recreated (and when most WORKS and non-Works forum postings were lost). As to your current question - again, it looks like it should work properly both ways, so I'll have to see if I can debug it and see why method #1 stops working after a few times, while method #2 continues to work… Thanks, - Bryan Shumsky Revelation Software, Inc. </QUOTE> —- === At 20 JUL 2020 02:31PM bshumsky wrote: === <QUOTE>Hi, Rich. I think I see where the problem may be. When you use myServer.OpenFile(tableName), NetOI tries to open both the data AND DICT portion of the specified table. SYSENV is one of those "special" tables that doesn't have a DICT associated with it, though. Obviously, NetOI should "gracefully" deal with this, but what I think is happening is that the automatic opening of the DICT portion fails (as you'd expect), but the "handle" to the DICT isn't marked unavailable or bad. So, when you close the file, I think it gets "confused." This happens when you're either explicitly calling CLOSE on the file object, or when you close the connection (NetOI tries to "clean up" any open tables at that point). After it gets confused a few times, it blocks the connection. What I've found is that if you use a table that has both a DICT and data section, your test routine works fine for 1000 opens and closes, even as you originally programmed it. Can you try that? Can you change which file you open, and which record you read, and see if that makes it run more reliably for you? Thanks, - Bryan Shumsky Revelation Software, Inc. </QUOTE> —- === At 21 JUL 2020 05:57AM Rich Channer wrote: === <QUOTE>Hi Bryan, Makes sense - just a bad file to use as a test I guess! I will change to another file and let you know how it goes… Many thanks for looking into this for us! Cheers, Rich </QUOTE> View this thread on the Works forum...