NetTalk web server service without a hidden window?

[oeb]

At several client sites we experience that opening a hidden window in a service cause Clarion runtime error 501 "Internal Error 01: WSLCLASS" or error 529 "Unable to open WINDOW" on OPEN(Window). The only way to temporarily fix this is to reboot the machine or change the user the service is running under - but the problem will eventually return. This service runs on central servers that should not be frequently rebooted so this is not ideal.

SoftVelocity recommended that we replaced the hidden windows with another solution for inter-thread communication and after experimenting with other solutions that is what we decided to do. I use CapeSoft GUTS for this and this works very well.

But I notice that the NetTalk Web Server uses at least two hidden windows. One in the application and at least one internal callback window in the DLL (referenced in the log). I have tried to replace the window in the app with a source procedure. The web server appears to start ok according to the log, but Chrome fails with ERR_CONNECTION_REFUSED when attempting to connect.

Is this at all possible to do - and is the callback window a regular Clarion window or does it use winapi directly? If it is a Clarion window I suspect it will also cause the error and the only remaining solution is to run the service with DebugView as the only GUI option

[Bruce]

Hi Ole,

>> At several client sites we experience that opening a hidden window in a service cause Clarion runtime error 501 "Internal Error 01: WSLCLASS" or error 529 "Unable to open WINDOW" on OPEN(Window). The only way to temporarily fix this is to reboot the machine or change the user the service is running under - but the problem will eventually return. This service runs on central servers that should not be frequently rebooted so this is not ideal.

I have a lot of services running, and have never seen this problem. Can you elaborate a bit. I think the important questions are;
a) What version of Clarion
b) What version of NetTalk
c) "How" are you making the program a Service? (SelfService or something else?)
d) Have you played with the PROP:Threading property at all - like setting PROP:Threading to false?

>> SoftVelocity recommended that we replaced the hidden windows

In services all windows are hidden. So they are suggesting that all windows in the application be replaced? That seems like overkill IMO.

>> with another solution for inter-thread communication

windows are not primarily there for "inter thread communication" but rather because they process events. In other words if you have "event driven" code then you need an ACCEPT loop and by implication a WINDOW.
So by "replacing windows" SV are suggesting that you no longer use or respond to events? Frankly that just sounds like bad advice.

>> and after experimenting with other solutions that is what we decided to do. I use CapeSoft GUTS for this and this works very well.

GUTS is good for inter-thread communications, but it doesn't solve your problem of event handling.

>> But I notice that the NetTalk Web Server uses at least two hidden windows.
>> One in the application and at least one internal callback window in the DLL (referenced in the log).

The app one isn't really "hidden" - although of course when running as a service you can't see it. The Internal NetTalk Callaback window is indeed hidden - it's present in all apps and is never displayed. It acts as the event handler to the Winsock layer.

>> I have tried to replace the window in the app with a source procedure.

that's not going to work. NetTalk is event-driven - it keeps the UI alive and just responds to events, to do that it needs an ACCEPT loop, and that requires a window. Using any NetTalk class without an ACCEPT loop is simply not going to work.

>> Is this at all possible to do -

no.

>>and is the callback window a regular Clarion window

yes.

>> If it is a Clarion window I suspect it will also cause the error and the only remaining solution is to run the service with DebugView as the only GUI option

Unfortunately that's not an option.

Perhaps the real question to ask is why you are getting this effect with your app, but everyone else who is running Clarion programs as Windows services has not noticed it?

cheers
Bruce

[oeb]

Thanks for your reply.

a) What version of Clarion
Clarion version does not appear to make a difference. Confirmed to occur with both Clarion 6 and 9.1.

Windows version could be more relevant. The error started to appear on Windows Server 2008/ 2012 in autumn 2014. Our software was unchanged since the end of 2013 (and been in development and use several years prior to that). Of course there is a chance we didn't notice it before, but I suspect some sort of change in these versions of Windows caused this. Since changing the user the service runs under sometimes help it makes me think that some sort of resources are running out - but this is just speculation.

b) What version of NetTalk
NetTalk 4.58 is used in production. I have upgraded to NetTalk 8 in development. But so far the error has only occured on the production version.
Please note that I don't suspect that the NetTalk windows in particular have anything to do with the problem - the error fires on the first OPEN(Window) in the program and so far that has not been the NetTalk windows. The error has also occured in a pure source-code project without NetTalk.

c) "How" are you making the program a Service? (SelfService or something else?)
SelfService yes. I should mention that I have seen one (1) occurrence of the error when the app was running as a regular program, but that could have been a different reason of course (the error description "Unable to open window" is pretty generic).

d) Have you played with the PROP:Threading property at all - like setting PROP:Threading to false?
No, but I can try that. This app has no MDI window. Why do you think that could make a difference?

>>windows are not primarily there for "inter thread communication" but rather because they process events. In other words if you have "event driven" code then you need an ACCEPT loop and by implication a WINDOW.
Well, in our own code that was really the only purpose of the windows. We used Event:Notify and GUTS was fine for replacing that.

>>The app one isn't really "hidden" - although of course when running as a service you can't see it.
I know it's not by default - but I have hidden it  

>> Is this at all possible to do -
no.
>>Unfortunately that's not an option.
Okay, thanks for clearing that up. I will probably move NetTalk so a separate app.

>>Perhaps the real question to ask is why you are getting this effect with your app, but everyone else who is running Clarion programs as Windows services has not noticed it?
Even though this error happens often enough that we want to find a solution it is still pretty rare. On machines that are frequently rebooted you would probably never notice it. Then error tends to reappear on the same machine, but there could be months in between. For 95% of our clients (very rough estimation) it does not happen at all.

The error might not always be identified though since we only recently added LibHook to the services - this makes it possible to output the error message to a file. Previously the service would just freeze on OPEN(Window) (because the Clarion runtime attempted to open a message box).

[Bruce]

Hi Ole,

>> Clarion version does not appear to make a difference. Confirmed to occur with both Clarion 6 and 9.1.

I suppose the counterpoint to your experience is that I (and many, many other folk) have been making services in Clarion for well over a decade, and this is the first I've heard of this effect. I think ultimately there is something causing the problem in your case, but declaring Windows verboten is massive overkill to the problem. I think you might need to get a bit closer to the root of the error to find an effective solution.

>> >> Have you played with the PROP:Threading property at all - like setting PROP:Threading to false?
>> No, but I can try that. This app has no MDI window. Why do you think that could make a difference?

No, quite the reverse. Setting prop:threading will cause further problems. So I asked more in the context of "that would be wrong" than "I think it might help".

>> Well, in our own code that was really the only purpose of the windows. We used Event:Notify and GUTS was fine for replacing that.

ok, well then if you've removed all your own windows from the app perhaps the next question is whether the program still exhibits the error?

Cheers
Bruce

[oeb]

Hi Bruce,
I was finally able to test this now.

>>ok, well then if you've removed all your own windows from the app perhaps the next question is whether the program still exhibits the error?
>
Yes, any window will trigger the error. But when I also disable NetTalk the service works as expected.