setting up forwarding (by Query or normal) results in repeated re-sending

[AKS]

I have setup 2 installations of the default dcm4chee (mysql) server (version dcm4chee-2.18.0-mysql.zip) 
in 2 different vmwares (Windows XP SP2) having 2 different IPs and names in the domain.

Both are configured using java version "1.6.0_20", 
jboss (jboss-4.2.3.GA-jdk6.zip) 
and MySQL (mysql-5.0.67-win32).

On One i have changed the default AETitle as AJDCM and on the other EJAZDCM.
I changed the location of the online storage to D:\dcmImages instead of Archive in both.
In both systems, i have added the AE Titles of the other system.

I configured the AJDCM4 for forwarding (default config) except the following:
I also modified the poll Interval to 3m from NEVER.
In dcm4chee.archive:service=MoveScu, modified the attribute RetryIntervals to 2x10m,24x1h,7x1d

Hence the servers are now set up for image receiving by AJDCM4 and auto forward to EJAZDCM.
I have used DCM4CHE2 to do dcmsnd of file UMJ4UXNF as TEST(aetitle) to AJDCM4.
As expected, after receiving the file in AJDCM4 successfully (can see the image), when the next forward by query fired(in 3 minutes), the image was sent to EJAZDCM.
There also it was checked and found to be received.

But after some time, this process starts to repeat continuously as seen from the log.
There is no failure but still it is repeating as seen from the logs of both the servers which I ave attached.

Kindly help me to know why it is repeating and what i can do to sort it. It is most urgent...

Thanks 
Awaiting a quick resolution....

[AKS]

I have noticed in the logs, that once after sending, it changes the LastSeriesPK attribute of the ForwardByQuery service to the last PK which is send.

But on the next schedule when the ForwardByQuery checks and displays the log, the LastSeriesPK attribute again goes back to 0.

Hence the repetition in sending the images.....

Can someone please help me as to why LastSeriesPK attribute again goes back to 0.

On checking the ForwardByQueryService.java source code....

please see codes marked by ===>

    public int doCheckForward() {

        if (lastCheckResult == null) {

            try {

                checkSQL(sql);

                if (sqlCmd != null) { 

                    sqlCmd.close();

                }

                sqlCmd = QueryForwardCmd.getInstance(sql, limit, fetchSize);

            } catch ( Throwable t) {

                log.error("Check of SQL statement failed!",t);

            }

        }

        if (!sqlIsValid) {

            log.warn("SQL is not marked to be valid! checkForward is disabled!");

            isRunning = false;

            return -1;

        }

        int nrOfSeries = 0;

        try {

            long scheduledTime = 0L;

===>            Map<String,List<String>> orders = sqlCmd.getSeriesIUIDs(delay < 0 ? null : new Long(System.currentTimeMillis()-delay), lastSeriesPk);

            log.info("Found "+orders.size()+" MoveOrder! lastSeriesPk:"+lastSeriesPk);

            lastSeriesPk = orders.isEmpty() ? 0 : sqlCmd.getLastSeriesPk();

            MoveOrder order;

            List<String> series;

[Peter Heiles]

as indicated in the issues you opened the ForwardByQuery Service needs a criteria, which identifies that the data has been already forwarded to avoid an "infinit forward loop".

This service has been created to perform archiving via DICOM C-Store to another PACS System (e.g. second dcm4chee installation, VNA, ...). The existing criteria in dcm4chee to identify that data has been successfully archived to such a system is the ext_retr_aet, which is set [to the destination archives aet] after receiving a positive storage commitment. The ext_retr_aet identifies exactly one AET from which data can be retrieved if it has been deleted from the local filesystem.

So from my point of view you have got two options:

1) utilize the ext_retr_aet within the sql query [see also StgCmtScuScp service, parameter RequestStorageCommitFromAETitles to request a Storage Commitment from the destination after forwarding data]. 

2) Implement a service/application, which meets your requirements - might be meaningful to implement it based on the data in the original system and just initiate a c-move (to avoid enhancing the dcm4chee datamodell and filling in values from an external source)

If you would like to go ahead with the ForwardByQuery service you can deploy it multiple times by, e.g.:

a) copy server/default/deploy/dcm4chee-forwardquery-service.xml to something unique per deployment of the service, e.g. dcm4chee-forwardqueryDEST1-service.xml

b) modify the parameter name="dcm4chee.archive:service=ForwardByQuery" to something unique per deployment of the service, e.g. name="dcm4chee.archive:service=ForwardByQuery_DEST1"