Tim, Yes, we are using the local looback address. Here are some samples from the log file being generated by the middleware service:
Example #1: [08:31:03.05] Sending DMM WS Call: TTX-BRP;AUTO_BOOTH_2_OUTGOING;526 [08:31:03.07] Received WS Response: Success: Carrier=526; [08:31:22.19] Sending DMM WS Call: TTX-BRP;AUTO_BOOTH_OUTGOING;391 [08:31:22.21] Received WS Response: Success: Carrier=391; [08:31:51.96] Sending DMM WS Call: TTX-BRP;AUTO_BOOTH_2_INCOMING;391 [08:31:53.04] Received WS Response: Success: Carrier=391; [08:32:08.93] Sending DMM WS Call: TTX-BRP;VACUUM_MASK;603 [08:32:09.62] Error sending WS call, Attempt resend in 600 ms: The underlying connection was closed: The connection was closed unexpectedly. [08:32:43.12] Sending DMM WS Call: TTX-BRP;AUTO_BOOTH_OUTGOING;709 [08:32:43.18] Received WS Response: Success: Carrier=709; Example #2: [20:17:39.00] Sending DMM WS Call: TTX-BRP;AUTO_BOOTH_2_INCOMING;667 [20:17:40.10] Received WS Response: Success: Carrier=667; [20:18:13.33] Sending DMM WS Call: TTX-BRP;AUTO_BOOTH_INCOMING;525 [20:18:14.39] Received WS Response: Success: Carrier=525; [20:18:30.17] Sending DMM WS Call: TTX-BRP;AUTO_BOOTH_OUTGOING;204 [20:18:30.80] Error sending WS call, Attempt resend in 600 ms: An error occurred while receiving the HTTP response to http://127.0.0.1/4DSOAP/. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details. [20:18:30.80] Sending DMM WS Call: TTX-BRP;AUTO_BOOTH_2_OUTGOING;857 [20:18:30.81] Received WS Response: Success: Carrier=857; [20:18:49.03] Sending DMM WS Call: TTX-BRP;LOAD_AREA;867 [20:18:50.13] Received WS Response: Success: Carrier=867; The log files are scattered full of these two types of entries, where the middleware service is trying to talk to our Server. We also have the web server log file active, but don't see anything funky in those. Just look at the timing between good calls and errors, as how does it just randomly have good "receipts", followed by a bad "receipt" and then immediately followed by more good "receipts"? Let me know if you need more details as this particular customer is not happy. Steve ********************************************* Stephen J. Orth The Aquila Group, Inc. Office: (608) 834-9213 P.O. Box 690 Mobile: (608) 347-6447 Sun Prairie, WI 53590 E-Mail: s.o...@the-aquila-group.com ********************************************* -----Original Message----- From: Timothy Penner [mailto:tpen...@4d.com] Sent: Thursday, April 12, 2018 2:17 PM To: s.o...@the-aquila-group.com; 4D iNug Technical <4d_tech@lists.4d.com> Subject: RE: Web Server Freeze Hi Steve, > Also, the two applications reside on the same box, meaning the DMM Server and > the "middleware" application (running as a service) are on the same box. If they are on the same box, are using a local loopback address like 127.0.0.1 or localhost, or are you using a real ip address or dns name? If you are not already using a local loopback address like 127.0.0.1 then I would suggest trying that because, technically, this situation is what it is designed for. The two apps being on the same machine make wireshark seem less important, but you could still perform the packet capture and limit the interface to the local loopback, and even further limit wireshark to only capture packets destined for port 80 (or whatever port you are using). This should reduce the amount of data that is logged. Also, if one of the apps is running as a service, make sure it is running as a named user account and not as the LocalSystem account; the LocalSystem account doesn't have full access to the network and our documentation specifically suggests using a named user: http://kb.4d.com/assetid=77847 -Tim Timothy Penner Senior Technical Services Engineer 4D Inc 95 S. Market Street, Suite #240 San Jose,CA 95113 United States Telephone: +1-408-557-4600 Fax: +1-408-271-5080 Email: tpen...@4d.com Web: www.4D.com ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
