Re: 20010112: ldmd.conf question

On Fri, 12 Jan 2001, Unidata Support wrote:

> 
> ------- Forwarded Message
> 
> >To: address@hidden
> >From: Alan Feltz <address@hidden>
> >Subject: ldmd.conf question
> >Organization: UCAR/Unidata
> >Keywords: 200101122047.f0CKlUo09496
> 
> Unidata support:
> 
> I have a question about ldmd.conf entries:
> 
> To begin with, we currently have an entry for receiving  FSL  data from
> stokes.metr.ou.edu .  Everything was working fine.  I then decided to add
> an entry for the  NEXRAD  data which will also be coming from  stokes .
> So I added the  NEXRAD  entry to the  ldmd.conf  file:
> 
>    request  FSL      ".*"  stokes.metr.ou.edu
>    request  NEXRAD   ".*"  stokes.metr.ou.edu
> 
> I restarted the LDM and everything worked fine.  The data was coming in
> for both the  FSL  and  NEXRAD  feeds and files were being created.  I then
> decided that for the time being I do not need to receive all the NEXRAD
> data, so I added the pattern  ^SDUS53  to the  NEXRAD  entry as follows:
> 
>    request  FSL     ".*"       stokes.metr.ou.edu
>    request  NEXRAD  "^SDUS53"  stokes.metr.ou.edu
> 
> When I restarted the LDM the  ldmd.log  file started filling up with groups
> of  RECLASS  and  disconnection  messages on the  stokes  process.  No data
> was being received due to the fact that no new files were being created.  I
> ran  notifyme  using the feed type  NEXRAD , the pattern  ^SDUS53 , and the
> host  stokes.metr.ou.edu  and was receiving notifications about the data.
> I tried several different patterns in both the  ldmd.conf  file and the
> notifyme  command line.  The notifyme pattern worked, but the  ldmd.conf
> entries kept giving me RECLASS lines.  A section of ldmd.log:
> 
> Jan 12 19:45:59 stokes[17972]: run_requester: Starting Up: stokes.metr.ou.edu
> Jan 12 19:45:59 stokes[17972]: run_requester: 20010112194351.307 TS_ENDT 
> {{FSL,  ".*"},{NNEXRAD,  "^SDUS53"}}
> Jan 12 19:45:59 stokes[17972]: FEEDME(stokes.metr.ou.edu): reclass: 
> 20010112194351.307 TS_ENDT {{FSL2,  ".*"},{NNEXRAD,  "^SDUS53"}}
> Jan 12 19:45:59 stokes[17972]: FEEDME(stokes.metr.ou.edu): OK
> Jan 12 19:46:00 stokes[17972]: RECLASS: 20010112184600.897 TS_ENDT {{FSL2,  
> ".*"},{NNEXRAD,  "^SDUS53"}}
> Jan 12 19:46:01 stokes[17972]: RECLASS: 20010112184601.102 TS_ENDT {{FSL2,  
> ".*"},{NNEXRAD,  "^SDUS53"}}
> Jan 12 19:46:01 stokes[17972]: RECLASS: 20010112184601.439 TS_ENDT {{FSL2,  
> ".*"},{NNEXRAD,  "^SDUS53"}}
> Jan 12 19:46:16 stokes[17972]: RECLASS: 20010112184616.944 TS_ENDT {{FSL2,  
> ".*"},{NNEXRAD,  "^SDUS53"}}
> Jan 12 19:46:17 stokes[17972]: RECLASS: 20010112184617.224 TS_ENDT {{FSL2,  
> ".*"},{NNEXRAD,  "^SDUS53"}}
> Jan 12 19:46:17 stokes[17972]: RECLASS: 20010112184617.361 TS_ENDT {{FSL2,  
> ".*"},{NNEXRAD,  "^SDUS53"}}
> Jan 12 19:46:17 stokes[17972]: Connection reset by peer
> Jan 12 19:46:17 stokes[17972]: Disconnect
> 
> 
> I then decided to see if I could just get the NEXRAD data without the FSL
> data.  So I commented out the FSL line:
> 
>    #request  FSL    ".*"       stokes.metr.ou.edu
>    request  NEXRAD  "^SDUS53"  stokes.metr.ou.edu
> 
> I restarted the LDM and and the NEXRAD began to arrive and was creating
> files as I expected it to do.
> 
> I happened to come across in one of the email archives a suggestion for
> a different problem (I think) that mentioned changing the computer name
> to its associated IP address.  So I gave that a try.
> 
>    request  FSL     ".*"       stokes.metr.ou.edu
>    request  NEXRAD  "^SDUS53"  129.15.192.81
> 
> I restarted the LDM and everything worked as expected.
> 
> 
> So after all this my question is: Is there something wrong with:
> 
>    request  FSL     ".*"       stokes.metr.ou.edu
>    request  NEXRAD  "^SDUS53"  stokes.metr.ou.edu
> 
> If I change  ^SDUS53  to  .*  it works, but I do not want all the
> NEXRAD  data at this time.
> 
> I hope this wasn't too confusing to follow.

Alan,

Noop, in fact I thought you did an excellent job of explaining the
problem and I appreciate the ground work you performed. You are correct,
the multiple request lines should of work in the manner that you expected
without all the reclass messages.  Actually, I think you might of found a
bug in the LDM.  I'm cc the LDM maintainers to see if they can duplicate
the problem or find an error that I missed.


Robb...



> 
> Thanks for any help or advice you can provide,
> 
> Alan Feltz
> Unix Sys Admin
> Dept of Physics and Astronomy
> University of Kansas
> Lawrence, KS  66045
> address@hidden
> (785) 864-5164
> 
> 
> ------- End of Forwarded Message
> 
> 

===============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
address@hidden             WWW: http://www.unidata.ucar.edu/
===============================================================================