Rick,
In the init() of my web service, there is code to extract the path for the app's home directory and the path to the app's database. It does that by reading an ini file which is in the web service's "home" directory.
There can be multiple instances of my ITF app (not the web service) running on a single cloud server. Each has it's own directory structure like: c:\ITF-LCTX for the home directory and c:\ITF-LCTX\DATA for where itf.dbc resides. AND c:\ITF-SLPS for the home directory and c:\ITF-SLPS\DATA for where itf.dbc resides.
I should mention all the instances of my app use the exact same executables and database structure, same tables, same views, etc. It's conceptually like there are multiple instances of QuickBooks installed on your workstation. Each instance is the same version but each instance has it's own data, etc. You would have 2 icons on your desktop to access QuickBooks1 and QuickBooks2.
When the web service starts and reads the ini, that ini tells the web service which of the above ITF's to access. So if I want the web service to be used to access ITF-LCTX, the ini would have the home directory as c:\ITF-LCTX and the data path as c:\ITF-LCTX\DATA OR if I want the web service to be used to access ITF-SLPS, the ini would have the home directory as c:\ITF-SLPS and the data path as c:\ITF-SLPS\DATA
As of today, meaning right now, I can not do what I described above. The web service is only installed ONCE on the server and it reads the ini file that is in the web service's "home" directory. So the web service can only be used to access EITHER ITF-LCTX or ITF-SLPS.
I suppose I could have a 2nd web service running on the server and then the 2nd web service would access the other ITF.
I would rather have the web service be able to point to the appropriate ITF system based on something like which vendor is calling the service. To be clear, If the vendor that posts transactions into ITF-LCTX calls the web service, the ITF-LCTX database would get accessed and if the vendor that posts transactions into ITF-SLPS calls the web service, the ITF-SLPS database would be accessed.
In order to accomplish that I would need to know which vendor called the web service so I could point the web service to the appropriate ITF system. Technically the same vendor could call the web service for multiple ITF's but I can deal with that by having separate vendor userid's per ITF they access, something like ALLY-LCTX or ALLY-SLPS (ALLY being a vendor name).
So I modified the init() of my web service to get from the OS, which vendor/userid ran the web service so more technically which userid ran ITFWeb.dll.
That is not telling me which userid called one of the web service's methods. Instead it is telling me what userid started the web service. The userid I am getting is "ITFWebService". There is no such userid so I assume that when IIS Manager starts the web service it is doing so under the name of the web service itself (or something like that).
I also added code to the init() that writes out a text file and places the userid that it got from the OS in that text file. That was done just so that I could "see" what userid was retrieved from the OS.
I noticed something I was not expecting. The text file does not get created when IIS Manager starts the web service. That tells me the init() does not get executed when the web service is started. Instead, the init() gets created when one of the methods of the web service gets called. Everytime I make a call to the GetAccountBalance() method of the web service, the text file gets created. That tells me that the init() gets run everytime GetAccountBalance() gets called. I did not know that. I had assumed the init() was run when the web service was started and that the GetAccountBalance() method gets called when a vendor calls it. When I initially wrote the web service, I put code in the init() that does things that I wanted to be done only once (setup stuff) in hopes it would make the service run faster. I guess that was wrong.
Can you verify that it is true that the init() does indeed get run everytime any method of the service gets called and maybe explain why?
EDIT: I have searched the web over and can not find anything about this behavior (the init method of my app not getting executed until one of the methods of my app (I only have 2 that users call, GetAccountBalance() and PostInmateDebit()) is called and the init method is called everytime one of the 2 methods gets called. This is a big deal to me and I really need to understand this so please answer when you have time.
As always, Thanks, John
John -
That tells me the init() does not get executed when the web service is started. Instead, the init() gets created when one of the methods of the web service gets called.
You likely have your Init code set up in your Process class, but it should instead be set up as part of the Server class. The Web Connection Server object is created once when the application starts up. Then a new instance of your Process object is created for every request that comes in.
You can view the details of how this works by checking out the Web Connection Documentation, specifically within the User Guide > How Web Connection works sections titled Implementing the Server (look for OnInit and OnLoad) and Setting up a Process Class (check out OnProcessInit).
Hope this helps.
Mike McDonald
Hi Mike,
I am reading that documentation now. I see enough to know I am probably going to need a full comprehension of my web service to understand this documentation (or vice versa). I wrote the foxpro code that is my web service but I hired Rick to help me turn it into a web service. I guess that means that now I have to understand what Rick did. Not really looking forward to that but I need to do it anyway.
I did purchase Web Connection a couple years ago for the purpose of setting up a web site interface for my ITF app. That has been on hold for 97 weeks now due to lack of time.
Thanks for pointing me in the right direction, John
Init()
runs whenever the class is instantiated. I don't remember what your service is so I don't know how that gets instantiated.
+++ Rick---
Hi Rick, Init() does not seem to be running when the class is instantiated. Why do I say that?
I put code in the init() that writes a text file. Just a simple fopen, fputs and fclose. There is no code any other methods of my service, that writes any text files.
Below is the code where I instantiate my WWProxy program. The last line is where I make a call to my service's GetAccountBalance() method.
The text file does not get generated until the call to GetAccountBalance AND the text file gets generated every time I make a call to GetAccountBalance.
lcserviceurl="http://1.1.1.1:8017/ITFWebService.asmx" && yes that is not a real ip
lcuserid="NCIC"
lcpassword="XXXXXXXX"
lcinmateid="123456"
lcitem="ALLY-PHONETIME"
lcvendortxnid="50000000000039343"
DO ITFWebServiceProxy
&& Create an instance of the Proxy
LOCAL loProxy as ITFWebServiceProxy
loProxy = CREATEOBJECT("ITFWebServiceProxy","V4")
loProxy.HttpLogin("NotTelling","NotTellingThisEither",.F.)
LOCAL loBridge as wwDotNetBridge
loBridge = loProxy.oBridge
&& End web services setup
loBridge.SetProperty(loProxy.oService,"Url",lcserviceurl)
loBridge.SetProperty(loProxy,"cserviceurl",lcserviceurl)
loresponse=loproxy.getaccountbalance(lcuserid,lcpassword,lcinmateid)
Thanks, John
If code needs to run every time you call a method, then the method should execute or call that code explicitly.
If code needs to run when the class loads, then it should go in the Init()
. It's that simple. Never assume anything about the state of an application. Init()
is meant to set up a class to execute potentially different methods.
How Init()
is fired depends on how the class is used and in what environment.
+++ Rick ---
Rick, You said: "If code needs to run every time you call a method, then the method should execute or call that code explicitly." My answer to that is Yes, I understand that.
You said: "If code needs to run when the class loads, then it should go in the Init()." My answer to that is Yes, I understand that.
Perhaps the confusion is that I did not tell you this: I added code to my init() to write out a text file. I do not need my init() to write out a text file. I ONLY did that because I suspected the init() was NOT running "when the class loads". My test has proven exactly that. My test has proven that the init() is NOT getting run "when the class loads" and my test has proven that init() is instead getting run when (and every time) I call the GetAccountBalance() method.
The question becomes, WHY?
You said: "How Init() is fired depends on how the class is used and in what environment."
My answer to that is: Can you be more specific about the factors that would cause the behavior that I am seeing?
Thanks, John
My answer to that is: Can you be more specific about the factors that would cause the behavior that I am seeing?
No - because you have to be specific what technologies you're using.
COM objects, West Wind Server, Something else all have different life cycles.
+++ Rick ---
Rick,
The application object of my web service app is marked as OLE PUBLIC. That means VFP registers it as an OLE server. Marking the application object as OLE PUBLIC allows it to be instantiated via COM. When I compile the app I compile it to a DLL (I believe MTDLL).
You helped me turn the above into a "web service". I am fuzzy about the details but I believe it was done as described in your white paper titled "Creating and Consuming Foxpro web services using .NET".
The code from my earlier post in this thread is where I am using the West Wind WSDL Proxy Generator to access the service myself. If a vendor calls and says the web service is not responding, I run that code to see if I can access the web service. If I can access the web service it means the vendor is doing something wrong. If I can not access the web service it means something is wrong so I restart the web service.
I hope that answers you with regard to what technology I am using. If it does not, let me know and I will try again.
Thanks, John
If I remember right this was classic ASP.NET web services with COM objects.
In that case COM objects may or may not fire the constructor on each request - it depends on how the server instantiates the object based on COM instance caching rules. In theory the object should be renewed each time (and actually may be) but in some cases, instances may be cached.
As I said before - you can't and shouldn't rely on class constructors to set class state beyond initial loading. If you need specific state for method to execute the method should make sure that that state is in place. State that you set in the constructor should only ever set the initial state of the class - nothing else. If that state gets changed after init, and you need the state to be just as if it was initial you need to set it each time.
FWIW, FoxPro Init()
methods should not even have much code in them. If there is that code should be delegated to a separate method that can be easily called from other methods or externally.
+++ Rick ---
Rick,
I believe your memory is correct. This is classic ASP.NET web services with COM objects. Let's assume for this conversation, that is correct.
You said: "you can't and shouldn't rely on class constructors to set class state beyond initial loading." My answer: I would never expect otherwise. I would ONLY put code in an init() that needs to be performed ONCE. A perfect example of this is: Code in my init() sets the location of the native VFP database that should be accessed when methods like GetAccountBalance() are called. IOW, code in my init() opens the database that should be used. Methods like GetAccountBalance() do not have to OPEN the database. They only query the database. It is already OPEN.
It sounds like you and I are in complete agreement on everything you are telling me. That is exactly how I intended my web service to behave.
So what is the problem? That is NOT the behavior that I am seeing. The following is the behavior I am seeing:
- The init() is NOT being fired when the service is instantiated.
- The init() IS ALWAYS being fired when the other methods of the service are called.
The following is the behavior I intended, and the behavior that I prefer:
- I want the init() to ALWAYS be fired when the service is instantiated.
- I do NOT want the init() to EVER be fired when the other methods of the service are called.
Can I and how do I, ensure that I get the behavior that I intended?
Before you answer: As you know, I use the Visual FoxExpress framework. I am looking at the init() method of the framework. I am looking for anything that would keep the init() method from being fired when the application object is instanciated. I see code that causes the DO() method to be skipped (not executed) when the application objects.lDisplayInterface property is False. When developing a VFP/VFE app that is going to be instantiated as a COM server, the application objects.lDisplayInteface is ALWAYS set to False. I have mine set to False. So, what does the DO() method do? VFE help says "It displays the application interface and issues a READ EVENTS." Is it possible that the init() method is not being fired because the DO() method is not being called?
Thanks, John
The service starting is not the same as the a method being called. The application starting does nothing for loading your COM objects. Only when a method is called are the COM objects instantiated. So that makes perfect sense. ASP.NET and COM is purely stateless with requests loading COM objects as each method is called.
+++ Rick ---
Well, we must be getting to the heart of the problem. I have absolutely no understanding of your answer.
You said "The service starting is not the same as a method being called." My response: "I assume you mean that when I am in the command window and I issue iisreset /start, my service is running but no code in my application is executed. Am I correct so far?
You said: "with requests loading COM objects as each method is called." My response: Does that mean the init() and whatever method was called both get run at that time?
I will wait for your reply but I suspect my next question will be what do I read to fully understand WHY?
Thanks for your patience, John
Now you're getting it.
The service is IIS starting up and running. Nothing happens until you call a service endpoint. At that point, some ASP.NET code runs, and it creates an instance of your COM class and executes it. When done it releases the object. IOW, object gets created, method(s) called, object gets released. Init()
, yourMethod()
, Destroy()
fire, all in that single request.
This is why I said - the call context matters. For example, if you were using Web Connection (FoxPro Server) the server is loaded on startup and can run code then and each endpoint creates a separate class instance that executes each requests and then unloads. Similar but subtly different.
+++ Rick ---
I really had no clue that was how my service works.
I must say I am not real happy about that. Why? I have code in the init() that not only opens the appropriate dbc but it pulls many system level settings and places those setting's values in properties of the application object. Then the code in an endpoint such as GetAccountBalance() simply check/use those application properties to do what GetAccountBalance() does.
Obviously it does no good to load those properties in the init().
Response time on calls to my endpoints is not slow but it could be twice as fast if it worked the way I intended it to work.
I believe the next question is: How difficult would it to be to convert my web service from being "classic ASP.NET web services with COM objects" to "using Web Connection"?
Thanks, John
I don't recall what type of service your application it is. If it is a SOAP Web Service, then Web Connection has no support for that and this is likely why we used ASP.NET at the time to do this in the first place.
If it's a REST service then Web Connection can provide that very well and it likely wouldn't be very difficult to convert, and likely much easier for you to work with as it would be all FoxPro. However, hosting and publishing is more complicated as you need to ensure you have a server that can run FoxPro.
+++ Rick ---
It is a SOAP Web Service.
Just curious and for future reference, with regard to a REST service, you said: "you need to ensure you have a server that can run FoxPro."
My app including the web service is currently running on Windows Server 2019 using IIS. What kind of a server would NOT be able to run FoxPro?
John
Well, your server is already running FoxPro (as an MTDLL server) so that's not really an issue.
If you're using a hosting provider and a shared server, you may not be able to install the FoxPro runtime on that server.
Not an issue in your case. But Web Connection doesn't have SOAP support, so either way this isn't an option unless you decide to switch to using a REST (JSON) service.
Web Connection runs a stateful server, that basically stays running between requests so you can open connections, open databases etc. and leave them open between requests.
+++ Rick ---
I am pretty sure switching from SOAP to REST would not be an option because all the vendors accessing my service would need to modify their code.
That would take years.
Thanks for all the help. Enjoy the waves, John
Rick, I have something else I need to ask about my web service.
Background: In this thread we established my web service is classic ASP.NET web services with COM objects It is a SOAP service.
Prior to the project I am working on (what I am attempting to accomplish), each of my "customer sites" was housed on it's own cloud server. That means one instance of my app is the only app running on a cloud server named CFS001. For my app running on CFS001, if a vendor needs to access the database on CFS001 I would install my web service on CFS001 and give the vendor credentials, URL etc.
In the near future I will be running many of my customer sites on a single cloud server. If a vendor needs access to 2 or more of the systems running on that one cloud server, and if I did not make any modifications to my web service, I would have to install multiple copies of my web service on that one cloud server and each copy of the web service would still only access one of the systems.
I have modified my web service (with your help in this thread) to be able to point to any of my systems based on parameters passed to my endpoint.
For example, a vendor named ALLY needs access to my system named ITF-LCTX but ALLY also needs access to my system named ITF-SLPS. When Ally makes a call to GetAccountBalance() to get an inmate's balance for an inmate residing in the ITF-LCTX system, Ally will use a userid of LCTX-ALLY. When Ally makes a call to GetAccountBalance() to get an inmate's balance for an inmate residing in the ITF-SLPS system Ally will use a userid of SLPS-ALLY. I have modified my web service to point to a particular ITF system based on the userid. I have tested this. It works just fine.
I am worried about the extra load on my web service. Now there are potentially twice as many calls to my ONE instance of my web service.
I read your West Wind Web Connection paper on "How many server instances should I run?" I am having a hard time figuring out how that relates to my "classic ASP.NET web services with COM objects" web service.
Is it possible to run multiple instances of my web service to handle the additional load?
Thanks, John
ASP.NET service applications using FoxPro COM don't work the same as Web Connection so the dynamics how FoxPro 'instances' are used are different. ASP.NET Services load FOxPro objects as needed so there's less pressure on getting the number of instances pooled. On the flip side you don't have control over the number of instances which means that if a server gets too busy it can easily overload the server.
It all depends on how you server works. If your server requests are quick and complete in a second or two or less, then there's no issue. BUt if you have lots of long running requests that tie up the CPU with processing then you can definitely overrun the capacity of your server (or if your server is underpowered).
To find out you need to monitor your server and see what the CPU load looks like under different levels of users accessing the service.
+++ Rick ---
It sounds like I may be worried for no reason. I have no "long running" requests.
I am attaching a log file from a facility that uses the web service the most. If it's not too much trouble could you take a quick look and see if you see anything I should be concerned about.
If the time-taken field is in milliseconds it appears no requests ever take more than 1.5 seconds but I may not be reading that correctly.
>
#Software: Microsoft Internet Information Services 10.0
#Version: 1.0
#Date: 2022-05-11 00:00:53
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
2022-05-11 00:00:53 127.0.0.1 GET / - 80 - 127.0.0.1 - - 401 2 5 1027
2022-05-11 00:01:15 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 67.63.241.65 JAX-WS+RI+2.2-hudson-740- - 200 0 0 415
2022-05-11 00:02:01 127.0.0.1 GET / - 80 - 127.0.0.1 - - 401 2 5 1917
2022-05-11 00:02:28 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 24.204.48.58 JAX-WS+RI+2.2-hudson-740- - 200 0 0 418
2022-05-11 00:02:43 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 67.63.241.65 JAX-WS+RI+2.2-hudson-740- - 200 0 0 419
2022-05-11 00:02:47 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 207.141.26.56 JAX-WS+RI+2.2-hudson-740- - 200 0 0 516
2022-05-11 00:03:08 127.0.0.1 GET / - 80 - 127.0.0.1 - - 401 2 5 1776
2022-05-11 00:03:10 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 67.63.241.57 JAX-WS+RI+2.2-hudson-740- - 200 0 0 514
2022-05-11 00:03:14 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 67.63.241.65 JAX-WS+RI+2.2-hudson-740- - 200 0 0 415
2022-05-11 00:04:03 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 207.141.26.56 JAX-WS+RI+2.2-hudson-740- - 200 0 0 727
2022-05-11 00:04:03 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 67.63.241.57 JAX-WS+RI+2.2-hudson-740- - 200 0 0 761
2022-05-11 00:04:14 127.0.0.1 GET / - 80 - 127.0.0.1 - - 401 2 5 1713
2022-05-11 00:04:47 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 207.141.26.56 JAX-WS+RI+2.2-hudson-740- - 200 0 0 399
2022-05-11 00:05:21 127.0.0.1 GET / - 80 - 127.0.0.1 - - 401 2 5 1605
2022-05-11 00:05:25 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 207.141.26.56 JAX-WS+RI+2.2-hudson-740- - 200 0 0 411
2022-05-11 00:05:30 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 24.204.48.58 JAX-WS+RI+2.2-hudson-740- - 200 0 0 407
2022-05-11 00:05:44 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 67.63.241.65 JAX-WS+RI+2.2-hudson-740- - 200 0 0 427
2022-05-11 00:05:44 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 67.63.241.57 JAX-WS+RI+2.2-hudson-740- - 200 0 0 515
2022-05-11 00:05:51 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 67.63.241.65 JAX-WS+RI+2.2-hudson-740- - 200 0 0 414
2022-05-11 00:06:10 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 24.204.48.58 JAX-WS+RI+2.2-hudson-740- - 200 0 0 504
2022-05-11 00:06:14 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 24.204.48.58 JAX-WS+RI+2.2-hudson-740- - 200 0 0 499
2022-05-11 00:06:27 127.0.0.1 GET / - 80 - 127.0.0.1 - - 401 2 5 1387
2022-05-11 00:06:58 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 207.141.26.55 JAX-WS+RI+2.2-hudson-740- - 200 0 0 420
2022-05-11 00:07:25 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 207.141.26.56 JAX-WS+RI+2.2-hudson-740- - 200 0 0 498
2022-05-11 00:07:34 127.0.0.1 GET / - 80 - 127.0.0.1 - - 401 2 5 1355
2022-05-11 00:07:46 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 67.63.241.65 JAX-WS+RI+2.2-hudson-740- - 500 0 0 33
2022-05-11 00:08:07 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 207.141.26.55 JAX-WS+RI+2.2-hudson-740- - 200 0 0 410
2022-05-11 00:08:38 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 207.141.26.56 JAX-WS+RI+2.2-hudson-740- - 200 0 0 406
2022-05-11 00:08:40 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 24.204.48.58 JAX-WS+RI+2.2-hudson-740- - 200 0 0 417
2022-05-11 00:08:40 127.0.0.1 GET / - 80 - 127.0.0.1 - - 401 2 5 1271
2022-05-11 00:09:00 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 207.141.26.56 JAX-WS+RI+2.2-hudson-740- - 500 0 0 30
2022-05-11 00:09:02 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 207.141.26.55 JAX-WS+RI+2.2-hudson-740- - 200 0 0 506
2022-05-11 00:09:47 127.0.0.1 GET / - 80 - 127.0.0.1 - - 401 2 5 1059
2022-05-11 00:10:04 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 24.204.48.58 JAX-WS+RI+2.2-hudson-740- - 200 0 0 405
2022-05-11 00:10:34 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 207.141.26.55 JAX-WS+RI+2.2-hudson-740- - 500 0 0 31
2022-05-11 00:10:35 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 24.204.48.58 JAX-WS+RI+2.2-hudson-740- - 200 0 0 521
2022-05-11 00:10:55 127.0.0.1 GET / - 80 - 127.0.0.1 - - 401 2 5 1995
2022-05-11 00:11:25 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 67.63.241.57 JAX-WS+RI+2.2-hudson-740- - 500 0 0 33
2022-05-11 00:11:52 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 24.204.48.58 JAX-WS+RI+2.2-hudson-740- - 500 0 0 266
2022-05-11 00:11:52 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 207.141.26.55 JAX-WS+RI+2.2-hudson-740- - 200 0 0 416
2022-05-11 00:11:58 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 24.204.48.58 JAX-WS+RI+2.2-hudson-740- - 200 0 0 397
2022-05-11 00:12:01 127.0.0.1 GET / - 80 - 127.0.0.1 - - 401 2 5 1934
2022-05-11 00:12:11 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 207.141.26.55 JAX-WS+RI+2.2-hudson-740- - 500 0 0 29
2022-05-11 00:12:30 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 207.141.26.56 JAX-WS+RI+2.2-hudson-740- - 200 0 0 513
2022-05-11 00:12:43 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 207.141.26.55 JAX-WS+RI+2.2-hudson-740- - 500 0 0 29
2022-05-11 00:12:52 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 24.204.48.58 JAX-WS+RI+2.2-hudson-740- - 200 0 0 419
2022-05-11 00:13:08 127.0.0.1 GET / - 80 - 127.0.0.1 - - 401 2 5 1777
2022-05-11 00:13:19 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 24.204.48.58 JAX-WS+RI+2.2-hudson-740- - 500 0 0 30
2022-05-11 00:13:21 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 24.204.48.58 JAX-WS+RI+2.2-hudson-740- - 200 0 0 520
2022-05-11 00:14:01 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 207.141.26.56 JAX-WS+RI+2.2-hudson-740- - 500 0 0 31
2022-05-11 00:14:08 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 207.141.26.56 JAX-WS+RI+2.2-hudson-740- - 200 0 0 416
2022-05-11 00:14:14 127.0.0.1 GET / - 80 - 127.0.0.1 - - 401 2 5 1590
2022-05-11 00:14:25 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 207.141.26.55 JAX-WS+RI+2.2-hudson-740- - 500 0 0 29
2022-05-11 00:14:26 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 24.204.48.58 JAX-WS+RI+2.2-hudson-740- - 200 0 0 505
2022-05-11 00:15:21 127.0.0.1 GET / - 80 - 127.0.0.1 - - 401 2 5 1323
2022-05-11 00:15:22 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 24.204.48.58 JAX-WS+RI+2.2-hudson-740- - 500 0 0 31
2022-05-11 00:15:30 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 67.63.241.65 JAX-WS+RI+2.2-hudson-740- - 200 0 0 427
2022-05-11 00:15:34 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 207.141.26.56 JAX-WS+RI+2.2-hudson-740- - 500 0 0 32
2022-05-11 00:15:34 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 67.63.241.65 JAX-WS+RI+2.2-hudson-740- - 200 0 0 416
2022-05-11 00:15:44 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 24.204.48.58 JAX-WS+RI+2.2-hudson-740- - 500 0 0 30
2022-05-11 00:15:48 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 24.204.48.58 JAX-WS+RI+2.2-hudson-740- - 200 0 0 514
2022-05-11 00:15:50 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 24.204.48.58 JAX-WS+RI+2.2-hudson-740- - 200 0 0 412
2022-05-11 00:15:54 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 24.204.48.58 JAX-WS+RI+2.2-hudson-740- - 500 0 0 37
2022-05-11 00:15:56 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 67.63.241.57 JAX-WS+RI+2.2-hudson-740- - 200 0 0 521
2022-05-11 00:16:20 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 207.141.26.55 JAX-WS+RI+2.2-hudson-740- - 500 0 0 35
2022-05-11 00:16:28 127.0.0.1 GET / - 80 - 127.0.0.1 - - 401 2 5 1184
2022-05-11 00:16:28 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 207.141.26.55 JAX-WS+RI+2.2-hudson-740- - 200 0 0 421
2022-05-11 00:17:01 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 67.63.241.57 JAX-WS+RI+2.2-hudson-740- - 200 0 0 411
2022-05-11 00:17:31 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 67.63.241.65 JAX-WS+RI+2.2-hudson-740- - 200 0 0 429
2022-05-11 00:17:34 127.0.0.1 GET / - 80 - 127.0.0.1 - - 401 2 5 1088
2022-05-11 00:17:37 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 207.141.26.56 JAX-WS+RI+2.2-hudson-740- - 200 0 0 413
2022-05-11 00:17:44 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 207.141.26.56 JAX-WS+RI+2.2-hudson-740- - 200 0 0 409
2022-05-11 00:17:57 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 67.63.241.57 JAX-WS+RI+2.2-hudson-740- - 200 0 0 504
2022-05-11 00:18:06 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 24.204.48.58 JAX-WS+RI+2.2-hudson-740- - 200 0 0 495
2022-05-11 00:18:11 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 24.204.48.58 JAX-WS+RI+2.2-hudson-740- - 200 0 0 511
2022-05-11 00:18:33 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 207.141.26.56 JAX-WS+RI+2.2-hudson-740- - 200 0 0 747
2022-05-11 00:18:33 192.168.110.57 POST /ITFWebService.asmx - 80 Fileshare 67.63.241.65 JAX-WS+RI+2.2-hudson-740- - 200 0 0 449
Sorry I could not figure out how to post the logfile itself so I put a small piece of it here and it did not format very well.
Thanks, John