oecgi Win7 (OpenInsight 32-bit Specific)
At 30 MAR 2011 11:13:10AM Paxton Scott wrote:
Greetings!
I have been doing web development work on WinXP pro and recently setup a 64bit Win7 Pro machine.
I Have Apache2 setup and running fine, and I have OI 9.1.1 running fine.
I have the same registry entries in both machines.
But, I still get "OECGI RevCreateEngine failed, error 3." when I try to use oecgi.
I am suspecting some permission/rights settings are incorrect in Win7, but I am real new to dealing with that.
Could anyone provide some guidance?
Thanks,
Have fun,
Paxton
At 30 MAR 2011 01:47PM Jared Bratu wrote:
Please verify that this is OECGI.EXE and not OECGI2.EXE or OECGI3.EXE. The currently supported OECGI executables are versions 2 and 3. Although OECGI.EXE is still included it is not recommended for use. You should be able to drop in OECGI2.EXE to replace OECGI.EXE
At 30 MAR 2011 02:37PM Paxton Scott wrote:
Jared,
This is development. I use oecgi2 in production. Production is on WinXP.
thanks,
Paxton
At 30 MAR 2011 06:09PM David Goddard wrote:
G'day Scott,
So what version of oecgi are you using in development?
oecgi.exe
oecgi2.exe
oecgi3.exe
Dave G
At 31 MAR 2011 06:24PM Paxton Scott wrote:
hmmm,
oecgi.exe
Did I miss stating that?
Paxton
At 01 APR 2011 12:07AM David Goddard wrote:
Any reason why you use oecgi.exe rather than oecgi2 or oecgi3?
At 01 APR 2011 03:11PM Paxton Scott wrote:
Sure,
Easier to use the debugger unless there is some new configuration I do not know about. At the time I started doing this, or rather when oecgi2 came out Bob Carten (sp) suggested develop in oecgi and deploy oecgi2.
Otherwise debugger does not work .
You have another solution?
Paxton
At 01 APR 2011 07:58PM bshumsky wrote:
Hi, Paxton. Yes, it's much easier now to use the debugger with OECGI2/OECGI3. In your registry settings for OECGI2/OECGI3, set the StartupFlags to "1", and the ShutdownFlags to "1". Next, instead of running the EngineServer (required by OECGI2 and OECGI3) as a service, run it instead on the desktop with the java command. To do this, open up a DOS box, "cd" to your OpenInsight folder, and type in:
java -jar oesocketserver.jar
(This assumes the path to the 32 bit java executable is in your system path).
Now, whenever you hit a DEBUG statement or anything that would send you into the debugger, the normal OpenInsight debugger will appear on your desktop.
Hope that helps,
- Bryan Shumsky
Revelation Software
At 02 APR 2011 09:44AM Paxton Scott wrote:
Oh, that does sound vaguely familiar, I will give it a go…
Thanks
At 02 APR 2011 01:42PM Paxton Scott wrote:
Brian,
I appreciate your description of how to use the debugger with oecgi2.
Remember,r I am using 64bit Win7. I installed Java from the download sight, but could not actually determine if it is 64 or 32bit or both.
Anyhow when I got "'java' is not recognized as an internal or external command,operable program or batch file." after entering "java -jar oesocketserver.jar" I found java.exe in C:\Program Files (x86)\Java\jre6\bin and added that location to the path.
I still get the "not recognized…." response (after even rebooting)
Perhaps, I do not know how to deal with spaces in the PATH.
Not sure if it is a case of not properly installing the 32bit version or what.
Also, What is the benefit of my using oecgi2 for development? Things have worked real well using oecgi for development and oecgi2 for production. ( I renamed oecgi2 to oecgi on the production platform so upgrades containing references do not have to be changed. Makes things pretty simple.
Back to the Original Question on this post. Since I have this machine's configuration set up exactly like my WinXp 32bit machine…namely the registry entries and I am getting the "OECGI RevCreateEngine failed, error 3." It occurred to me that a likely problem was the permissions/rights in Win7. I thought perhaps someone could provide some guidance in this area. It appears that no one is using OI9.1.1 oecgi on win7 64bit.
All ideas appreciated.
Have fun,
Paxton
At 02 APR 2011 06:28PM bshumsky wrote:
Hi, Paxton. You can avoid the problem of entering the path to the java exe into your "path" variable by typing it directly in front of the exe name, as in:
C:\program files(x86)\java\bin\java.exe -jar oesocketserver.jar
OECGI communicates with the OEngine in an entirely different fashion than OECGI2, so you may find the problem goes away when you switch to OECGI2.
No new development on, or feature additions to, OECGI has occurred for the last several releases. On the other hand, OECGI2 (and its successor, OECGI3) continue to be actively developed and - if you run into difficulties with them - can be supported and debugged.
Hope that helps,
- Bryan Shumsky
Revelation Software
At 02 APR 2011 07:09PM Paxton Scott wrote:
Brian,
Thanks for all you help and attention, even on the weekend!I did in fact try the path in front of the java.exe eariler as you suggest. Maybe I had a syntax error, but I do not think so.
I think windows does not like a space in the path as it complains c:\Program is not recognized as an internal or….
It is probably common knowledge, but I do not know how to issue a command with a space in the command line, and the folder path has a space…maybe enclose in quotes. Yes! that is it! In case anyone else is reading this.
OK, now, at least the symptoms change. I started oesocketserver at least the command found it, and returned Version: 1.0.0d - Licensed for use to CN=Revelation Software
Error waiting for response: An existing connection was forcibly closed by the remote host. And from the browser, I get: "Trying to open inet_dce…. Seems like I have seen that before somewhere.
Maybe that error is because of the way I start OpenInsight, which is:
C:\RevSoft\Oinsight\OINSIGHT.exe /AP=DCE /UN=DCE /SN=OECGI /DV
I think this is progress, and maybe you have yet another clue.
I appreciate your help, have a good weekend!
Have fun,
Paxton
PS
I understand the value of oegineserver, as we use it in production and I recognize you plan no further support for oecgi.
I am working to get this running using oecgi2 as you suggest,
but I still to do not see a benefit in using oecgi2 over oecgi in my current development environment which works fine on my 32bit machines.
I guess the benefit is anything that works!
![]()
At 03 APR 2011 02:15AM bshumsky wrote:
Hi, Paxton. Yes, you'll need to enclose the path and exe in quotes, as you found. Glad that started up.
Now, have you configured your registry properly for OECGI2 (since that's what you're using now, versus OECGI)? What are you specifying in your URL - it should now end with …/oecgi2.exe/ (unless you're doing some fancy footwork to hide the oecgi2.exe name, which I assume you aren't).
Hope that helps,
- Bryan Shumsky
Revelation Software
At 03 APR 2011 02:35AM bshumsky wrote:
Hi, Paxton. A few other points to remember/understand:
- if your URL _is_ now correctly using OECGI2.EXE, you will probably need to configure IIS to understand that this is an executable and will need to be allowed (you should be able to find configuration information for setting up IIS with OECGI2 in the OI documentation);
- how you start up OpenInsight isn't relevant anymore, because OECGI2 needn't communicate with your "named engine". While it _can_ do so (via the EngineName registry setting), that's neither needed nor recommended when using the StartupFlags/ShutdownFlags set to "1", so if you still have that specified in the registry for the EngineName, you should probably remove it.
- Bryan Shumsky
Revelation Software
At 03 APR 2011 10:23AM Paxton Scott wrote:
Brian,
Well this part I understand, and My solution is to rename oecgi2.exe to oecgi to match all my existing code.
Works fine, been dong that for a long time. That allows the same code to run in development oecgi and in production on oecgi2 (renamed)
The issue, as I keep repeating, was to get that same strategy to work when the development environment is 64bit Win7.
But, making progress in getting the development site set up to actually do development with oecgi2
![]()
Paxton
At 03 APR 2011 11:22AM Paxton Scott wrote:
Hi, Brian.
Well, I assume you mean CreateFlags and ShutDownSessions as I see no reference to StartUpFlags both set to 1.
But, I did add StartUpFlags and ShutDownFlags both set to one.
I changed "localhost" to 192.168.1.14 but I would not think that necessary.
Now getting: Unable to connect to Engine Server localhost:8088 - The attempt to connect was forcefully rejected.
fixed up the java -jar oesocketserver.jar command in a bat file to easy to start.
now, start oesocketserver and then I get a different response from the browser….
"You have chosen to open inet_dce which is blah, blah, blah. What should FireFox do with this file?
Is there any complete documentation on how to set up oecgi2 and OpenInsight for use with the debugger?
I am now suspecting I have some simple thing tangled, such as How should I start OpenInsight now? You recall my command string is: C:\RevSoft\Oinsight\OINSIGHT.exe /AP=DCE /UN=DCE /SN=OECGI /DV
Also, fyi, I am running Apache2
Thanks again, Brian
Have fun,
Paxton
At 03 APR 2011 12:52PM bshumsky wrote:
Hi, Paxton. Just to be clear, when running OECGI2 (either normally or for debugging), you do NOT need to have your OpenInsight running. So how you start up your OpenInsight shouldn't be relevant.
There are, indeed, registry flags for OECGI2 named "StartupFlags" and "ShutdownFlags", and _not_ "CreateFlags". I suggest again that you find the OECGI2 configuration documentation and review that to make sure you've got the registry configured properly.
- Bryan Shumsky
Revelation Software
At 03 APR 2011 12:57PM bshumsky wrote:
] The issue, as I keep repeating, was to get that same strategy to work when the development environment is 64bit Win7
Hi, Paxton. You are certainly free to pursue resolving that issue; if you want to continue to work with OECGI rather than OECGI2, then that's up to you.
However, if you wish to try and get OECIG2/OECGI3 working - the currently supported software, as opposed to OECGI - then I can try to help with that.
If you find issues when using OECGI2/OECGI3, then we're more likely to be able to resolve them; if you're finding issues with OECGI, though, then you'll have to rely on the rest of the OpenInsight community to assist you with them, as that's not something I can speak about from current experience.
At 03 APR 2011 04:00PM Paxton Scott wrote:
Brian,
Again thanks for sticking with me on this, even on the weekend.
Anyhow, I have put in the StartupFlags and ShutdownFlags, as you suggest.
I would love to find OECGI2 configuration documentation, but what I have, shipped with OI9.1.1, under OpenEngine,OECGI2,Registry Settings makes no mention of StartupFlags or ShutdownFlags. The configuration illustrated does not give access to the OI debugger.
So is used for production. I do have oecgi2 running in production just fine.
Doing development, I WANT OpenInsight running all the time to make edits to SP's and other adjustments.
If Oinsight.exe is not running, how will the debugger run?
And, not discussed yet, what is the recommended procedure in starting oesocketserver and OpenInsight? Do I have to restart the server each time I call it from the browser?
Somehow I sort of expected the use of oecgi2 in development to be no more difficult (or unhandy) than using oecgi with my /SN=OECGI parameter. Otherwise why change?
Thanks again.
I hope you can point me to some doc to help me.
Have fun,
Paxton
I must say that so far, the original method suggested by Bob Carten and what I have been using for years on my 32bit WinXP seems better. but, I am willing to learn a better method.
If you can point me to documentation on this subject, I will gladly study it. that is my normal nature rather than a conversation on problems.
I may just have to stick with 32bit WinXP, but Occasionally it locks up so bad I have to do a reset. I was hoping to take advantage of more memory using 64bit.
Eager to follow your suggestions
At 03 APR 2011 06:56PM David Goddard wrote:
Was just looking for the documentation on setting up OECGI2 and found instructions in the OpenInsight Help file that details how use OECGI2.EXE to talk to a local running engine, just like you used to do with the old OECGI
From the application manager, select help and contents.
Under the Contents tab, click on OpenEngine, then OECGI2 then debugging OECGI2. I think you will find this will work in a similar way to the old OECGI.
Dave G
At 03 APR 2011 07:32PM Paxton Scott wrote:
Dave,
Thank you very much for you kind attention. My help only has 3 topics under OECGI2, OECGI2, OECGI2 Registry Settings and File Uploads Using OECGI2
I will search around and check my installs now that I know there is doc somewhere.
Are you looking at 9.2 help or 9.1.1 which is what I have.
Have fun,
Paxton
At 03 APR 2011 09:05PM David Goddard wrote:
Belay that order. Can't get that method to work.
I'm running Windows 7 64Bit as well. This is what I do:
1. I start a copy of the OESocketServer from the command line using a batch file. The contents of the batch file look like this:
echo off
cls
"C:\Program Files (x86)\Java\jre6\bin\java.exe" -jar d:\revsoft\oinsight\OESocketServer.jar -l d:\revsoft\oinsight\eserver.cfg
2. My eserver.cfg looks like this: (just the relevant settings show)
configuration file for oesocketserver.jar invocation:
java - jar oesocketserver.jar {-l } {-d {<debuglevel}}
which port to listen on PortNumber=8088 maximum number of sockets connected at any time (0=unlimited)
MaxConnections=0
maximum number of engines to keep in queue (for stateless connections ONLY) MaxEngines=2 time (in minutes) to wait before killing idle engines from queue
IdleTimeout=1
3. My registry settings for OECGI3 ( I use OECGI3 because it's the latest and greatest) look like this.
Windows Registry Editor Version 5.00
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\RevSoft\OECGI3
"ApplicationName"=EXAMPLES"
"EngineName"="
"FileMode"=1"
"FilePath"="
"OILocation"="
"ProcedureName"=RUN_OECGI_REQUEST"
"ServerPort"=8088"
"ServerURL"=localhost"
"ShutdownFlags"=1"
"StartupFlags"=1"
"SysDownPage"="
"UserName"=EXAMPLES"
"UserPassword"="
Now when a procedure hits a debug statement the debugger will appear.
You run a separate copy of OpenInsight on your desktop to edit your procedures. Note that your procedure changes won't be reflected by oesocketserver until it starts a new engine, as the engines cache the procedures in memory. That's why I set the idletimeout to 1 minute in the eserver.cfg file.
At 03 APR 2011 11:39PM bshumsky wrote:
And, just to expand on what David has said and to address some of your earlier questions, Paxton:
Unlike OECGI, OECGI2 has the EngineServer create an OpenEngine when the request for an OpenInsight stored procedure comes in. As David mentioned, this OEngine is "cached" by the EngineServer so it can be more responsive.
What the StartupFlags and ShutdownFlags do are tell the EngineServer to create the OEngine visibly, on the desktop; when you get this to work, you should see the OEngine actually on the task bar. When you hit the debug statement (or any statement that triggers the debugger), the OEngine that's on your taskbar will open up the OpenInsight debugger for you to step through your procedure. _That's_ how you'll debug the process; it's not via any OpenInsight that _you_ start up, it's the one that the EngineServer manages for you.
Hope that helps a bit,
- Bryan Shumsky
Revelation Software
At 04 APR 2011 08:57AM Dave Harmacek wrote:
With a running, named engine, I use the below configuration to debug O4W scripts:
(btw, I also use Apache on the file/web server)
Originally, the registry for Revsoft\OECGI2 (or OECGI3) looks like:
HKEY_LOCAL_MACHINE\SOFTWARE\RevSoft\OECGI2\o4w
"ApplicationName"=APP"
"EngineName"="
"ProcedureName"=RUN_OECGI_REQUEST"
"ServerPort"=8088"
"ServerURL"=localhost"
"ShutdownFlags"=1"
"StartupFlags"=65"
"SysDownPage"="
"UserName"=WEBUSER"
"UserPassword"=WEBPASSWORD"
1. Start OINSIGHT with the /sn=ENGINENAME /ap=APP /un=USERNAME /PW=UPASS /DV=1
2. Then, I go into REGEDIT and import a .reg file changed as follows:
HKEY_LOCAL_MACHINE\SOFTWARE\RevSoft\OECGI2\o4w
"ApplicationName"=APP"
"EngineName"=ENGINENAME"
"ProcedureName"=RUN_OECGI_REQUEST"
"ServerPort"=8088"
"ServerURL"=localhost"
"ShutdownFlags"=0"
"StartupFlags"=2"
"SysDownPage"="
"UserName"=USERNAME"
"UserPassword"=UPASS"
3. Go to Processess and Restart the OEngineServer.
Then, the named engine starts to process all calls. You can see all activity in the OENGINE of the named OINSIGHT. If I place a DEBUG in the script, the Debugger appears and works as expected. In the Debugger when I click Run then the page continues and the browser reflects this.
In the OINSIGHT session, if I change the script and compile, the change is immediately reflected in the next browser call. I don't have to use Java or restart the OEngineServer again.
To revert to production, if needed, I just import a .reg with the original settings and restart the OEngineServer.
I think you can apply the above concepts to just debug a regular oecgi2 session.
Dave
Harmacek Database Systems
At 04 APR 2011 09:22AM Paxton Scott wrote:
Thanks so much, David,Dave and Brian.
I will work on these suggestions today, depending on interruptions, and will post my results. Of course with the excellent suggestions, I expect to post success.
Thanks, all
Have fun, Paxton
ps
I must say, I really do understand the difference in oecgi calling Oengine directly and using oesocketserver. But, still, for development purposes only, I do not see the benefit. It indeed is wonderful for production… There, I post an upgrade and restart the service and it works great.
All this comes about just wanting to replicate my 32bit environment on the 84bit machine….Oh Well.