Essci40.dll call via the SciSocketmanager#getHostByAddr method - hangs with slow response time

56 views
Skip to first unread message

longhorn999

unread,
Jan 8, 2020, 4:36:00 PM1/8/20
to VA Smalltalk

We are making a Essci40.dll call via the SciSocketmanager#getHostByAddr method.
The first call is always quick.
Then sometime afterwards ( may take 10 more calls to it, may take 100 more calls to it ), the method will hang up to 2-3 minutes.

We can verify that the call is somehow using the Windows host file ( we can change the host file values and see either the FQDM get returned or just the name, depending on what we change it to ), but we cannot debug any further because its an IBM/Instantiations DLL.

Can someone tell me exactly what the SciSocketManager>>getHostByAddr is doing in the DLL?
And has anyone experienced this issue, and have a resolution?
This method has never thrown a walkback or error code, it'll just hang and eventually returns, but it is painfully slow.

We are running the application on a Windows 2008 server.

Here's an example of our debugging and logging, where it took over 3 minutes for the DLL call to return a value:

12/23/2019 5:09:22 PM --- TrsFileNetSOAPXmlSimpleHttpProcessor>>#processCommand START method: 12/23/2019 5:09:22 PM
12/23/2019 5:09:22 PM --- AbtXmlSimpleHttpProcessor>>#processCommand START method: 12/23/2019 5:09:22 PM
12/23/2019 5:09:22 PM --- AbtXmlSimpleHttpProcessor>>host = xxx.70.118.37  12/23/2019 5:09:22 PM
12/23/2019 5:09:22 PM --- AbtXmlSimpleHttpProcessor>>port = 7102  12/23/2019 5:09:22 PM
12/23/2019 5:09:22 PM --- AbtXmlSimpleHttpProcessor>>Got Host Name: 12/23/2019 5:09:22 PM
12/23/2019 5:09:22 PM --- AbtXmlSimpleHttpProcessor>>openAsClientToHost: inside method START 12/23/2019 5:09:22 PM
12/23/2019 5:09:22 PM --- AbtXmlSimpleHttpProcessor>>openAsClientToHost: inside method , creating new socket stream 12/23/2019 5:09:22 PM
12/23/2019 5:09:22 PM --- SciSocketmanager>>getHostByAddr START, String = 'xx.70.118.37' 12/23/2019 5:09:22 PM
12/23/2019 5:12:59 PM --- SciSocketmanager>>getHostByAddr END method 12/23/2019 5:12:59 PM
12/23/2019 5:12:59 PM --- SciSocketAddress>>abtFromHost = 2722526757  12/23/2019 5:12:59 PM
12/23/2019 5:12:59 PM --- AbtXmlSimpleHttpProcessor>>openAsClientToHost: inside method , set address  12/23/2019 5:12:59 PM
12/23/2019 5:12:59 PM --- AbtXmlSimpleHttpProcessor>>openAsClientToHost: inside method , connect and END of method 12/23/2019 5:12:59 PM
12/23/2019 5:12:59 PM --- AbtXmlSimpleHttpProcessor>>#processCommand openAsClientToHost method: 12/23/2019 5:12:59 PM
12/23/2019 5:12:59 PM --- AbtXmlSimpleHttpProcessor>>#processCommand writeRequestHeaders method: 12/23/2019 5:12:59 PM
12/23/2019 5:12:59 PM --- AbtXmlSimpleHttpProcessor>>#processCommand readResponseStatusFrom   method: 12/23/2019 5:12:59 PM
12/23/2019 5:12:59 PM --- AbtXmlSimpleHttpProcessor>>#processCommand END method: 12/23/2019 5:12:59 PM
12/23/2019 5:12:59 PM --- TrsFileNetSOAPXmlSimpleHttpProcessor>>#processCommand END method: 12/23/2019 5:12:59 PM
12/23/2019 5:12:59 PM --- TrsFileNetInterface>>#processRequest TrsContentExecuteSearchRequest  END method: 12/23/2019 5:12:59 PM
12/23/2019 5:12:59 PM --- numberOfAttempts calling exectureSearch: 1   12/23/2019 5:12:59 PM


Thanks in advance, Garet

Mariano Martinez Peck

unread,
Jan 9, 2020, 7:30:14 AM1/9/20
to VA Smalltalk
Greetings Garet, 

I don't have anything on top of my head but if you have an active license feel free to contact Instantiations Support (https://www.instantiations.com/support/index.html) and we will happy to dedicate engineering time to help you. 

Best, 

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/2d79a28a-2cc2-4bcc-a632-9024d9340e15%40googlegroups.com.


--
Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Richard Sargent

unread,
Jan 9, 2020, 2:28:56 PM1/9/20
to VA Smalltalk
On Wednesday, January 8, 2020 at 1:36:00 PM UTC-8, longhorn999 wrote:

We are making a Essci40.dll call via the SciSocketmanager#getHostByAddr method.
The first call is always quick.
Then sometime afterwards ( may take 10 more calls to it, may take 100 more calls to it ), the method will hang up to 2-3 minutes.


One of my colleagues tells me this could be a DNS issue. Although, I cannot imagine it taking minutes. If you are using your ISP's DNS, you might want to experiment with others, such as Google's for example (Google Public DNS: 8.8.8.8 and 8.8.4.4).

Ideally, you would write a test harness to avoid VA Smalltalk's interface and experiment with your current DNS (reproducibility) and with others (possible solutions). [I mean calling your own OS gethostbyaddr implementation without VA Smalltalk being involved at all.]

Is there anything about the addresses that could explain the anomalous behaviour? e.g. frequently used addresses can be cached by your infrastructure but uncommon addresses need to go out for external DNS resolution. e.g particular addresses or domains?


Of course, if the addresses are all identified in the hosts file on your system, then the DNS implementation in the outside world would be irrelevant.

You may also want to look into Gibson Research's DNS Benchmarking tool.

longhorn999

unread,
Jan 9, 2020, 2:41:11 PM1/9/20
to VA Smalltalk
Richard, Thank you for the reply .
The application runs on a closed network, no Internet access at all, need a secure VPN to access.
We have had our network experts look at everything they know about, and they have been pushing back on the developer(s) that it's an application problem.  The code ( calls to method #getHostByAddr ) has worked for over 8+ years probably, until recently.
The IP addresses are relatively new, and we moved from Citrix to RDS recently also.  ( Win2003 machines to Win2008 machines ).  
I will gently ask the network & server teams to try Gibson Research DNS tool.  
-Garet

Marten Feldtmann

unread,
Jan 9, 2020, 4:49:25 PM1/9/20
to VA Smalltalk
Oh yes, DNS calls can take VERY long time and the "typical" 2 minutes under Windows are possible. All API calls with DNS calls are potential dangerous and break your application (if you think, that this call is easy and takes no time). Normally DNS calls should be executed in an asynchronous way ... but most of the time, nobody takes care of that.

The poster mentioned VPN and there have been questions in the net regarding very slow DNS queries in VPN connections, some mentioned forwarder problem ... its a large area.

Marten

longhorn999

unread,
Jan 9, 2020, 5:12:05 PM1/9/20
to VA Smalltalk
Marten,
When you say executing the call in an asynchronous way, are you simply talking about adding a System abtShowBusyCursor around the call?
-Garet

Julian Ford

unread,
Jan 10, 2020, 11:01:41 AM1/10/20
to VA Smalltalk
I have also experienced this issue (not taking MINUTES, but defintiely taling too many SECONDS).
In my experience, Richard is right on.... it is a DNS issue.
I had a really good IT person sort out the DNS issue on the router, and the delay disappeared.

I have also had the "push back" you described....but it the problem is in the router.

As an interesting discovery, on the few occasions when I have seen this delay,
I tried switching to using #getHostByName:, and the delay also disappeared.
I do not know why looking up by name was faster, but my IT friends assure me it is a router
thing.

Not sure if this helps, other than to say you are not alone.
But also... try the named lookup, and see if that helps.
If nothing else, it might give you some support, when you tell the IT people the issue
is with DNS on the router...

Regards,
Julian
Reply all
Reply to author
Forward
0 new messages