Update 1.4.19d1 released

  • Hi, I am getting image corruption when transferring files to viewers or another server. If I manually copy the files the images are fine. Problem is just with dicom send. Went back to version 1719b and dicom send works as expected. Tested transfer to KPacs, Charruasoft and Microdicom as well as another conquest server.


    OS= Centos 7 64bit

    SQL= MariaDB 5.5.60

  • We installed the 1.4.19d1 update in our datacenter

    While working with GE on some transfer issues afterwards, these are the notes I got back from them:

    So it looks like there is a PDU length issue playing here as well

  • Some studies seem to fail after 20 or so images, some die right away.

    I'll see that I can find an image that triggers it every time and if it still does it after anonymizing.

    If so, I'll send it over shortly.

  • I was able to replicate it with a specific image, which was anonymized.

    So 1 images from a dicom server runnin 1.4.19d1 on a windows server to a Linux based GE system.

    In the GE logs, the main thing seems to point to:


    2019-03-12 07:37:29 EDT INFO -|DicomServiceTemplate:102| Received association request from peer [Socket[addr=/10.x.x.xx,port=62752,localport=8118]].

    2019-03-12 07:37:29 EDT INFO -|RequestHandler:82| Association request from the peer [Socket[addr=/10.x.x.xx,port=62752,localport=8118]] accepted

    2019-03-12 07:37:29 EDT INFO -|EventManager:114| Firing the event for eventID 10003

    2019-03-12 07:37:29 EDT INFO -|CognitoTokenService:93| --------- cognitoIdTokenExpired or FirstLogin... Getting new cognitoIdToken, cognitoIdentityId, openIdToken...

    2019-03-12 07:37:30 EDT ERROR-|DicomServiceTemplate:271| Exception in creating dicom dataSpecified length (27265470) of PDU exceeds limit: 1048576

    java.io.IOException: Specified length (27265470) of PDU exceeds limit: 1048576

    ...

    2019-03-12 07:37:30 EDT ERROR-|RequestHandler:108| dicomexception occured during handling the request1003

    com.ge.med.terra.tap.dm.DMException: java.io.IOException: Specified length (27265470) of PDU exceeds limit: 1048576


    Uploading the image now and I'll send the link in a private message

  • Hi,


    the corrupted image is correct in row 0, and breaks at row 1, column 504:


    1 501 41376 41376

    1 502 39481 39481

    1 503 38962 38962

    1 504 39640 11464 (word 936+504)

    1 505 37644 11273

    1 506 37464 10365


    The first time I see this sequence 11464 11273 10365 in the uncorrupted image is at

    row 140, column 156 (byte 936+504), i.e. 129756 words later. No obvious system in it.


    Looking at changes between b and d1 they are:


    pdata.cxx, line 198:

    b: BlockSize = 4096;

    d1: BlockSize = MaxSubLen-6; //16384; // was 4096;


    buffer.cxx lines 53, 55:

    #ifdef UNIX

    b: # define DEFAULT_BREAK_SIZE 8192

    d1: # define DEFAULT_BREAK_SIZE 262144 // was 8192

    #else

    b: # define DEFAULT_BREAK_SIZE 32600

    d1: # define DEFAULT_BREAK_SIZE 262144 // was 32600

    #endif


    My impression is that all other changes are unrelated. Can you test reverting one or both of these changes? On windows the image transmits without problem.


    Thanks,


    Marcel

  • Ok,


    I think we should keep BREAK_SIZE 8192 on Linux (see also 20130416 comment in buffer.cxx).


    For pdata.cxx, I would like to know what goes wrong. Would you mind adding this printf statement:


    printf("MaxSubLen=%d\n", MaxSubLen);

    BlockSize = MaxSubLen-6; //16384; // was 4096;


    I am curious what is passed (it would show in the command line). There may be an issue reading this value from the association.


    Marcel

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!