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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

gkipe1

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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/2d79a28a-2cc2-4bcc-a632-9024d9340e15%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

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

Mariano Martinez Peck-2
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, 

On Wed, Jan 8, 2020 at 6:36 PM longhorn999 <[hidden email]> 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.

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

--
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 [hidden email].
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.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/CAOUkibF2d2UpaarvbbXfb4rNP9mQvfZ%2BE55N3wxan4i3wV44YQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

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

Richard Sargent
Administrator
In reply to this post by gkipe1
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.
https://www.grc.com/dns/benchmark.htm



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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/c480cb29-286e-449f-8d7c-e8a8a975bf53%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

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

gkipe1
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




On Thursday, January 9, 2020 at 1:28:56 PM UTC-6, Richard Sargent wrote:
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.
<a href="https://www.grc.com/dns/benchmark.htm" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.grc.com%2Fdns%2Fbenchmark.htm\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGkTjKBiGETQ0nxyQPxNj0CazCTig&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.grc.com%2Fdns%2Fbenchmark.htm\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGkTjKBiGETQ0nxyQPxNj0CazCTig&#39;;return true;">https://www.grc.com/dns/benchmark.htm



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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/b5281c06-5ded-4330-891b-20606d5c1fb7%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

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

Marten Feldtmann-5
In reply to this post by Richard Sargent
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

Am Donnerstag, 9. Januar 2020 20:28:56 UTC+1 schrieb Richard Sargent:
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.
<a href="https://www.grc.com/dns/benchmark.htm" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.grc.com%2Fdns%2Fbenchmark.htm\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGkTjKBiGETQ0nxyQPxNj0CazCTig&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.grc.com%2Fdns%2Fbenchmark.htm\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGkTjKBiGETQ0nxyQPxNj0CazCTig&#39;;return true;">https://www.grc.com/dns/benchmark.htm



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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/7423188c-7811-4d95-8b6e-4fca8876e159%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

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

gkipe1
Marten,
When you say executing the call in an asynchronous way, are you simply talking about adding a System abtShowBusyCursor around the call?
-Garet



On Thursday, January 9, 2020 at 3:49:25 PM UTC-6, Marten Feldtmann wrote:
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

Am Donnerstag, 9. Januar 2020 20:28:56 UTC+1 schrieb Richard Sargent:
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.
<a href="https://www.grc.com/dns/benchmark.htm" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.grc.com%2Fdns%2Fbenchmark.htm\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGkTjKBiGETQ0nxyQPxNj0CazCTig&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.grc.com%2Fdns%2Fbenchmark.htm\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGkTjKBiGETQ0nxyQPxNj0CazCTig&#39;;return true;">https://www.grc.com/dns/benchmark.htm



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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/f1c628aa-2f9b-44e7-8985-e18dd4e1701a%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

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

Julian Ford-2
In reply to this post by gkipe1
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

On Wednesday, January 8, 2020 at 4:36:00 PM UTC-5, 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.

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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/d4b69d49-f525-471b-9e1d-e265c7a3798b%40googlegroups.com.