Loading…
Tilbage

Profilbillede

DiscoveryPublic daily no response around 12:00 DK time

Dmitriy Lapko

Hello Dear Nemhandel Support

Are there any known maintenance exercises around 12:00 DK time on http://discoverypublic.nemhandel.dk UDDI service, which could lead to no answer from the service?

Since 29.09.2021 we experience almost daily issues with the old OIORASP 2.1.1 library, which hangs forever on UDDI lookup if it happens around 12:00. In the new version of OIORASP 3.0.0 we see a change which introduces a timeout parameter for the UDDI client with default value 120 seconds.

https://rep.erst.dk/git/openebusiness/library/java/-/commit/23576b1df8a24f7f8782694b7eb774bece763245

Was it introduced to overcome this behaviour?

Are there known reasons for this issue?

Dear Dimitriy,

Thanks for this post. It's important for you to have this input. The load on NHR is growing due to more and more automatic lookups. We have an on-going problem analysis regarding the problem, which you are expierence around 12:00 DK time. 

The features on OIORASP version 3.0.0 is implemented to minimize or remove negative impact for the sender, but it is not the root course. 

The feature with the timeout parameter is already running in production on Fakturablanketten (with is based on OIORASP Java). With a clear postive effect.

Best Regards 

Nemhandel teamet

 

Hello Mogens


Thank you for the reply! 

From what I see, I can confirm that Java OIORASP 3.0.0 fixed the issue with stucked forever UddiLookupClient queries because of spoiled HttpClient instance by invalid response from discoverypublic at 12:00, although it is done in a little rude way - via clearing cached instances of HttpClient in each new instance of UddiFallbackClient, introduced in a commit change https://rep.erst.dk/git/openebusiness/library/java/-/commit/a8e17f307759e5f779a5fc3cc8a1517ad0c98c8f#b1cde84c93a9ec83e54d9b33e9a6c9b1b852178c_42_42


From my research I can say that timeout option, introduced in 3.0.0, do not solve this exact problem, as it requires to set http.connection-manager.timeout inside openuddi-client-1.4.jar, and not socket timeout...


Theoretically, the correct fix could be either to solve the reason of spoiled httpClient instance ("Attempt to access a parser that has thrown a parse exception before; rethrowing the original exception.") or cleaning cache from spoiled httpClient inside catch blocks of UddiFallbackClient instances.


I could share more details on a meeting, please feel free to contact!

BTW, during local queries to discoverypublic via proxy yesterday I noticed, that at response at Sat, 09 Oct 2021 10:01:48 GMT contained Soap Fault message:

<?xml version='1.0' encoding='UTF-8'?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
    <S:Body>
        <S:Fault xmlns:ns4="http://www.w3.org/2003/05/soap-envelope">
            <faultcode>S:Server</faultcode>
            <faultstring>GET http://back1-prod:8080/nemhandelregister/rest/service/orchestratedservice/participant/128684/service/104422/documenttype/UtilityStatement returned a response status of 500 Internal Server Error</faultstring>
            <detail>
                <ns2:dispositionReport xmlns:ns2="urn:uddi-org:api_v3" xmlns="http://www.w3.org/2000/09/xmldsig#">
                    <ns2:result errno="10500">
                        <ns2:errInfo errCode="E_fatalError">getServiceDetail: Unable to execute query at the moment, due to backend error (error has been logged and will be investigated)</ns2:errInfo>
                    </ns2:result>
                </ns2:dispositionReport>
            </detail>
        </S:Fault>
    </S:Body>
</S:Envelope>

The text "error has been logged and will be investigated" looks promising :)