Posts by SM1312

  • Random Error when querying the web server

    marcelvanherk

    I don't see any obvious problem with TCP params. I did have a look at the logs in the EventViewer for TCP related things but don't see anything of problem.

  • Random Error when querying the web server

    marcelvanherk

    I did a powershell equivalent for that in windows while running the 10 concurrent queries:

  • Random Error when querying the web server

    Morning marcelvanherk,

    I did install 1.5.0f on Ubuntu 22.04 (this was using sqlite instead of mysql though) and tested the same 10 concurrent API queries.

    Unlike Window where there were atleast 3 or 4 failures, in Linux I saw one failure out of 10. I repeated it thrice. Out of three tries, there were 1 failure in two of them while there were none in the last. But the error was the same.

    I got the above error from PacsTrouble.log. It seems serverstatus.log doesn't seem to be updated in linux!!!

    In serverstatus.log, I only have this:

    YAML
    Tue Mar 24 10:34:50 2026 Stared zip and cleanup thread
Tue Mar 24 10:34:50 2026 *** Not enough rights to write in MAG0
Tue Mar 24 10:34:50 2026 Monitoring for files in: /home/itsme/conquest/data/incoming/
Tue Mar 24 10:34:50 2026 DGATE (1.5.0f, build Tue Mar 24 09:54:00 2026, bits 64) is running as threaded server
Tue Mar 24 10:34:50 2026 Database type: built-in SQLite driver
Tue Mar 24 10:34:50 2026 ***Failed to Listen () - bind error

    Should I do anything more or correct something to get proper serverstatus.log!???

    Thanks.

  • Random Error when querying the web server

    Hi marcelvanherk

    Thanks. Retry seems to have definitley helped. Previously, out of 10 concurrent queries, 4 failed. Now its just 1 failing (I repeated the test it thrice). Log is attached.

    I am using Windows Server 2019 for all the Conquest nodes within my deployments.

    If we are going to the retry mechanism as a solution, I suppose its better to leave that to the API users at the client side. This way they can control the retry limit and delay timings.

    I was anyway planning to implement a simple semaphore with my JS wrapper so that the API querying isn't bombarded with concurrent querying especially duing heavy loads? I can just embed the retry mechansim in there as well which can be reconfigured depending on the usage.

    What do you think of this?

  • Random Error when querying the web server

    marcelvanherk

    Here is the log from the new dgate64:

  • Random Error when querying the web server

    Here is the errored part of the log (Debug level is set to 4):

  • Random Error when querying the web server

    I am using the Apache webserver with the new `dgate64.exe` and related configs.

    Same issue. But the Apache logs do record all the queries with return code as 200 which is expected as with lua nil errors or DICOM ERROR connect failed on socket level (called not running), they are all return as responses as PHP collects it that way I suppose.

  • Random Error when querying the web server

    marcelvanherk

    I tried a different patient. This one had less no. of series in it.

    All 10 concurrent queries were fine with ladle server while 4 of them failed with typical webserver.

    I am not sure what to make of this? Depends on the patient load, it varies!???

    Also, do you think any Apache or PHP config is causing this!? but then in Apache's logs, I don't see anything fishy.

  • Random Error when querying the web server

    marcelvanherk

    Api does work with dgate64.exe as well. Out of 10 concurrent queries, 6 of them do return valid response like usual.

    The other 4 just didn't error but didn't return valid data either. Debug print statements in rquery.lua show that the response is nil for those servercommands (this was the case earlier as well).
    Previously we were seeing explicit error DICOM ERROR connect failed on socket level (called not running), we just don't see that now with dgate64.exe.