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 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.


  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 
or localhost, or are you using a real ip address or dns name?

If you are not already using a local loopback address like 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


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

Reply via email to