SENDER Failed association DCM4CHEE

[Nicolas Pasini]

Hi,

I added a new remote aetitle following the wiki "Remote Application Entities" at https://github.com/dcm4che/dcm4chee-arc-light/wiki/Remote-Application-Entities

I redeployed dcm4chee-arc.xml in DEBUG mode

Sending an image with OFFIS dcmtk:

dcmsend -v -aet SENDER -aec DCM4CHEE 192.168.2.197 11112 dicomfile.dcm

Result:

I: checking input files ...
I: starting association #1
I: initializing network ...
I: negotiating network association ...
I: Requesting Association

F: cannot negotiate network association: DUL network read timeout

Pacs side log:

00:13:53,995 INFO  [org.dcm4che3.net.Connection] (EE-ManagedExecutorService-default-Thread-2) Accept connection Socket[addr=/192.168.2.198,port=57380,localport=11112]
00:13:54,010 DEBUG [org.dcm4che3.net.Association] (EE-ManagedExecutorService-default-Thread-2) /192.168.2.197:11112<-/192.168.2.198:57380(1): enter state: Sta2 - Transport connection open
00:13:54,011 DEBUG [org.dcm4che3.net.Connection] (EE-ManagedExecutorService-default-Thread-2) Wait for connection on /0.0.0.0:11112

1 - Pacs - Remote Aetitle misconfiguration?

2 - Network issue? note: If I send the image locally, same thing.

3 - Other?

I was expecting something like "BAD aetitle" ...

Netstat entries:

Proto  Recib Enviad Dirección local         Dirección remota       Status    
tcp        0      0 *:postgresql            *:*                     LISTEN
tcp        0      0 *:8443                  *:*                     LISTEN
tcp        0      0 *:ldap                  *:*                     LISTEN
tcp        0      0 *:9990                  *:*                     LISTEN 
tcp        0      0 *:dicom                 *:*                     LISTEN
tcp        0      0 localhost:3528          *:*                     LISTEN  
tcp        0      0 *:2575                  *:*                     LISTEN  
tcp        0      0 *:http-alt              *:*                     LISTEN  
tcp        0      0 localhost:ldap          localhost:54246         STABLISHED
tcp      265      0 192.168.2.197:dicom     192.168.2.198:57548     STABLISHED
tcp        0      0 localhost:54246         localhost:ldap          STABLISHED
tcp        0      0 localhost:postgresql    localhost:50644         STABLISHED
tcp        0      0 localhost:50648         localhost:postgresql    STABLISHED
tcp        0      0 192.168.2.197:ssh       192.168.2.198:54906     STABLISHED
tcp        0      0 localhost:50644         localhost:postgresql    STABLISHED
tcp      266      0 192.168.2.197:dicom     192.168.2.198:57546     CLOSE_WAIT
tcp        0      0 localhost:postgresql    localhost:50648         STABLISHED
tcp      266      0 192.168.2.197:dicom     192.168.2.197:47446     CLOSE_WAIT

Regards,

Nicolás

[Nicolas Pasini]

Hi,

I've found something estrange,

If I go to "Monitoring" , Control Tab , and press STOP when the image is being send (actually is the negotiating step) , then associating is accepted , then :

I: Association Accepted (Max Send PDV: 16366)
I: sending SOP instances ...
I: Sending C-STORE Request (MsgID 1, CR)
I: Received C-STORE Response (Success)
I: Releasing Association
I:
I: Status Summary
I: --------------
I: Number of associations   : 1
I: Number of pres. contexts : 1
I: Number of SOP instances  : 1
I: - sent to the peer       : 1
I:   * with status SUCCESS  : 1

¿¿??

Nicolás

[Gunter Zeilinger]

Does it works locally? If yes, check your firewall settings.

On Mon, May 14, 2018 at 6:08 AM, Nicolas Pasini <nicola...@gmail.com> wrote:

Hi,

I've found something estrange,

If I go to "Monitoring" , Control Tab , and press RELOAD when the image is being send (actually is the negotiating step) , then associating is accepted , then :

I: Association Accepted (Max Send PDV: 16366)
I: sending SOP instances ...
I: Sending C-STORE Request (MsgID 1, CR)
I: Received C-STORE Response (Success)
I: Releasing Association
I:
I: Status Summary
I: --------------
I: Number of associations   : 1
I: Number of pres. contexts : 1
I: Number of SOP instances  : 1
I: - sent to the peer       : 1
I:   * with status SUCCESS  : 1

I am dealing with a DB deadlock ?

Nicolás

--
You received this message because you are subscribed to the Google Groups "dcm4che" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dcm4che+unsubscribe@googlegroups.com.
To post to this group, send email to dcm...@googlegroups.com.
Visit this group at https://groups.google.com/group/dcm4che.
For more options, visit https://groups.google.com/d/optout.

[Nicolas Pasini]

Hi,

Thank you for replying,

No, that's not seems to be the problem

2 - Network issue? note: If I send the image locally, same thing.

I found that someone else had the same issue due to the missing JBOSS_HOME path . 

I don't know  ... still looking for the solution.

Regards,

[Gunter Zeilinger]

Is DNS working? With next version you will be able to log and disable reverse lookup: https://github.com/dcm4che/dcm4chee-arc-light/issues/1360

On Mon, May 14, 2018 at 1:56 PM, Nicolas Pasini <nicola...@gmail.com> wrote:

Hi,

Thank for replying,

[Nicolas Pasini]

Yes, DNS is working.

I don't have access to the logs right now, but I remember a message while "standalone.sh -c dcm4chee-arc.xml"  thats says something about using "0.0.0.0" and that it should be used "SERVERNAME" instead . Besides that, did find other message or warning. 

Regards,

[Nicolas Pasini]

Hi Gunter,

The pacs is running without any issues so far. 

The problem I think was a missing configuration while preparing the deploy.

 First of all, I am running Wildfly 12

Following the installation procedure at https://github.com/dcm4che/dcm4chee-arc-light/wiki/Installation I think I miss this (I mean I did not execute this step) :

One of the differences between the default configurations of Wildfly 9 and 10(or higher) is in the managed-executor-services of the ee subsystem

(core-threads and max-threads attributes are missing) which causes thread-pool related issues in the latter, typically when there are long running

tasks on archive or multiple association requests at the same time. Hence to make Wildfly 10(or higher) behave like default in Wildfly 9,

adjust the managed-executor-services configuration using JBoss CLI as given below:

   

[standalone@localhost:9990 /] /subsystem=ee/managed-executor-service=default:undefine-attribute(name=hung-task-threshold)
[standalone@localhost:9990 /] /subsystem=ee/managed-executor-service=default:write-attribute(name=long-running-tasks,value=true)
[standalone@localhost:9990 /] /subsystem=ee/managed-executor-service=default:write-attribute(name=core-threads,value=2)
[standalone@localhost:9990 /] /subsystem=ee/managed-executor-service=default:write-attribute(name=max-threads,value=100)
[standalone@localhost:9990 /] /subsystem=ee/managed-executor-service=default:write-attribute(name=queue-length,value=0)

 So within the wrong dcm4chee-arc.xml  we can see:

<managed-executor-service name="default" jndi-name="java:jboss/ee/concurrency/executor/default" context-service="default" hung-task-threshold="60000" keepalive-time="5000"/>

Within the correct dcm4chee-arc.xml we can see:

<managed-executor-service name="default" jndi-name="java:jboss/ee/concurrency/executor/default" context-service="default" long-running-tasks="true" core-threads="2" max-threads="100" keepalive-time="5000" queue-length="0"/>

I will keep in mind what you said :

With next version you will be able to log and disable reverse lookup: https://github.com/dcm4che/dcm4chee-arc-light/issues/1360

Now that I ran into this issue,  may I ask what if we change this  core-threads="2"  to this core-threads="4"? Could we see an improvement with out compromising the service ? Just wondering ...

Thank you,

Regards,

Nicolás

SOLVED

[Gunter Zeilinger]

Don't think that increasing core-threads has a significant effect to the performance. s.:

 /subsystem=ee/managed-executor-service=default:read-resource-description
    "outcome" => "success",
    "result" => {
        "description" => "A managed executor service",

        "attributes" => {

:

            "core-threads" => {
                "type" => INT,
                "description" => "The minimum number of threads to be used by the executor. If left undefined the default core-size is calculated based on the number of processors. A value of zero is not advised and in some cases invalid. See the queue-length attribute for details on how this value is used to determine the queuing strategy.",
:

[Nicolas Pasini]

Thank you Gunter,

Regards,

Nicolás