[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[McIDAS #QLW-227820]: 20100701: McIDAS ADDE server access

Hi Patrick,

re:
> We run a software called Spider which uses McIDAS and ADDE to retrive images
> from other Spider servers.  The servers we receive data from are NESDIS Spider
> servers.  We frequently see an error like this during transmission of a file:
> 
> Loading new image: 4000
> Beginning Image Data transfer, bytes= 13779872
> Transferring AREA data outbound, bytes= 13779952
> select timed out
> IMGCOPY: Communications to server has stopped
> IMGCOPY: Data transmission has failed
> IMGCOPY: done

This sounds like the network connection between the two machines dropped during
the transfer, OR the transfer was taking so long that the ADDE timeout was
exceeded.  I would guess the latter possibility is more likely.

re:
> We see this on at least two of the servers.  They are 
> satepsdist4e.nesdis.noaa.gov and
> satepsdist6e.nesdis.noaa.gov, which are located (I believe) in Suitland,
> MD at the NOAA Satellite Operations Facility (NSOF) facility. I looked
> back a few days and we've seen 5 of these errors.

Question:

- 5 errors out of how many attempts?  (i.e., what is the failure rate?)

re:
> The types we are trying to pull at the time are:
> 
> 6e:
> MSG/MSGGLOB09I
> IND/INDOEXWV
> MET/MEGLOB05V

I had no problem IMGCOPYing the most recent image from these datasets to
a local dataset and then displaying the result.  Then again, I only tried
the IMGCOPYs one time each.

re:
> 4e:
> PLR/SSMIEOR08B2
> PLR/AMSRE36V1

Comments:

- there is no PLR/SSMIEOR08B2 dataset on satepsdist4e.nesdis.noaa.gov:

IMGLIST PLR/SSMIEOR08B2
Image file directory listing for:PLR/SSMIEOR08B2
IMGLIST: Image directory server unable to resolve this dataset: PLR/SSMIEOR08B2
IMGLIST: done
IMGLIST failed, RC=2

  There is, however, something whose name is similar:

IMGLIST PLR/SSMIEDR08B2 FORM=ALL
Image file directory listing for:PLR/SSMIEDR08B2
 Pos Satellite/         Date       Time      Center      Res (km)   Image_Size
     sensor                                 Lat  Lon    Lat   Lon
 --- -------------  ------------  --------  ---- ----  ----- ----- ------------
  20  RMET           1 JUL 10182  20:25:46     0  160
   Band: 2    No Information Available                  7.99  7.99  2875 x 5000
     proj:    0 created: 2010182 202903  memo: SSMI EDR Rain Rate from CEMSCS
     type:PRD      cal type:BRIT
     offsets:  data=    1280 navigation=  256 calibration=  768 auxiliary=    0
     doc length:   0   cal length:   0   lev length:   0 PREFIX=   0
     valcod:          0 zcor:  1 avg-smp: N
     lcor: 8564  ecor:  7501  bytes per pixel: 1  ss:  9
     Resolution Factors (base=1):   Line=    8.0   Element=    8.0
IMGLIST: done

I was able to do an IMGCOPY of the full image from 4e to my workstation in
Unidata with no problem.  )At least, I had no problem at the particular time
of my IMGCOPY).  The problem is that the image was blank.

- there is no PLR/AMSRE36V1 dataset:

IMGLIST PLR/AMSRE36V1
Image file directory listing for:PLR/AMSRE36V1
IMGLIST: Image directory server unable to resolve this dataset: PLR/AMSRE36V1
IMGLIST: done
IMGLIST failed, RC=2

  There is, however, a PLR/AMSRE36V dataset:

IMGLIST PLR/AMSRE36V
Image file directory listing for:PLR/AMSRE36V
 Pos Satellite/         Date       Time      Center   Band(s)
     sensor                                 Lat  Lon
 --- -------------  ------------  --------  ---- ---- ------------
   1  COMPOSITE      1 JUL 10182  20:30:00     0  160 36
IMGLIST: done

  I was able to IMGCOPY the latest image from this dataset to
  local dataset with no trouble, and the image was good.


Given the success I had in IMGCOPYing from each of the datasets above,
I am left with the feeling that the problem you are seeing is sporadic.
If this is true, it is likely that the problem is in the network connection
being interrupted during the transfer and/or the copying taking so long
that the ADDE timeout cuts of the connection.

How exactly your Spider software is running the IMGCOPYs is also another
area that could somehow be introducing problems.  Do you have a good idea
of how Spider is doing the copies?

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: QLW-227820
Department: Support McIDAS
Priority: Normal
Status: Closed