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

[McIDAS #PMR-133644]: ADDE transfer of nexrad composite

Hi Russ,

re:
> Thanks for the quick reply.

You caught me on a good morning :-)

re:
> I've tried the following servers
> ATM.UCAR.EDU
> ADDE.UCAR.EDU
> These 2 servers time out waiting to complete an IMGLIST
> NEXRCOMP/1KN0R-NAT request.

I just displayed the most recent image from the NEXRCOMP/1KN0R-NAT dataset
from my McIDAS-X session running on my home machine (a single board Odroid
U3 quad core ARM machine running Ubuntu 14.04 LTS), and each display took
less than 5 seconds.  After that, I did a full listing
(IMGLIST NEXRCOMP/1KN0R-NAT.ALL) of the same dataset on both adde.ucar.edu
and atm.ucar.edu, and these took about 2 seconds to complete.

re:
> I can get this to work from most machines
> but the one where my script is running (wmsserv2.ssec.wisc.edu) is
> showing this error. I am wondering if I may have been blacklisted for
> trying to get too many files? The other possibility is the machine might
> be hosed and needs a boot.

Hmm... to my knowledge we have not blacklisted (blocked) _any_ machines
from access to the ADDE servers we run on our motherlode-class machines
recently.  The full set of the machines I am referring to is:

adde.ucar.edu
atm.ucar.edu
adde.ssec.wisc.edu
lead.unidata.ucar.edu

To make sure that a block has not been implemented that I don't know
about, I just sent an email to our lead system administrator, Mike Schmidt.

re:
> I also tried the local server IDD.SSEC.WISC.EDU
> That yields a totally different failure "error generating list of
> files". It looks like the setup on IDD is hosed.

idd.ssec.wisc.edu and adde.ssec.wisc.edu are a Cname aliases for
unidata2-new.ssec.wisc.edu.  As I said in my previous email, there
is something strange happening on this machine, and investigations
are underway.

re:
> I'm wondering what you get if you try an IMGLIST.

I can do IMGLISTs of all NEXRCOMP datasets from my McIDAS-X session
running on my home machine.  This tells me that there is nothing
systematically wrong with ADDE on three of the 4 machines listed
above:

adde.ucar.edu
atm.ucar.edu
lead.unidata.ucar.edu

adde.ssec.wisc.edu, on the other hand, is experiencing problems, and
we are investigating.

(A bit later)
I just got this from Mike:

"I have not made recent changes to ADDE access (that I can recall anyway)
on the motherlode clones..."

Given this, and given that I am able to access all of the populated ADDE
datasets on three of the four motherlode-class machines listed above, I
have to believe that the problem is on your side.

Question:

- what happens when you try to 'telnet' to the ADDE port on these machines?

  For example:

telnet adde.ucar.edu 112

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: PMR-133644
Department: Support McIDAS
Priority: Normal
Status: Closed
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.