Smalltalk › Instantiations

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

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

gkipe1

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

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

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

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.

Email: [hidden email]

Twitter: https://twitter.com/MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/

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

Richard Sargent

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

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.

gkipe1

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

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='https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.grc.com%2Fdns%2Fbenchmark.htm\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGkTjKBiGETQ0nxyQPxNj0CazCTig';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.grc.com%2Fdns%2Fbenchmark.htm\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGkTjKBiGETQ0nxyQPxNj0CazCTig';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.

Marten Feldtmann-5

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

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='https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.grc.com%2Fdns%2Fbenchmark.htm\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGkTjKBiGETQ0nxyQPxNj0CazCTig';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.grc.com%2Fdns%2Fbenchmark.htm\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGkTjKBiGETQ0nxyQPxNj0CazCTig';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.

gkipe1

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

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='https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.grc.com%2Fdns%2Fbenchmark.htm\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGkTjKBiGETQ0nxyQPxNj0CazCTig';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.grc.com%2Fdns%2Fbenchmark.htm\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGkTjKBiGETQ0nxyQPxNj0CazCTig';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.

rjuli...@gmail.com

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

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.