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.
Was it introduced to overcome this behaviour?
Are there known reasons for this issue?
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.
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
returned a response status of 500 Internal Server
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>
The text "error has been logged and will be investigated"
looks promising :)