FDSN Client

Hi All,
I have a question regarding the initialization of the FDSN Client (osbpy.fdsn.client).

Often when I initialize a new instance, I get an error message. Most of the time, however, I'm still able to use services. Sometimes, however, the services fail.

For instance, this worked despite an error opening the Client:

In [1]: from obspy.fdsn import Client
In [2]: from obspy import UTCDateTime
In [3]: client=Client("IRIS")

Exception in thread Thread-3:
Traceback (most recent call last):
   File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
     self.run()
   File "/usr/lib/python2.7/dist-packages/obspy/fdsn/client.py", line 1045, in run
     debug=debug)
   File "/usr/lib/python2.7/dist-packages/obspy/fdsn/client.py", line 1239, in download_url
     timeout=timeout, data=data)
   File "/usr/lib/python2.7/urllib2.py", line 127, in urlopen
     return _opener.open(url, data, timeout)
   File "/usr/lib/python2.7/urllib2.py", line 404, in open
     response = self._open(req, data)
   File "/usr/lib/python2.7/urllib2.py", line 422, in _open
     '_open', req)
   File "/usr/lib/python2.7/urllib2.py", line 382, in _call_chain
     result = func(*args)
   File "/usr/lib/python2.7/urllib2.py", line 1214, in http_open
     return self.do_open(httplib.HTTPConnection, req)
   File "/usr/lib/python2.7/urllib2.py", line 1184, in do_open
     raise URLError(err)
URLError: <urlopen error [Errno -2] Name or service not known>

In [4]: cat=client.get_events(starttime=UTCDateTime("2010-01-01"),endtime=UTCDateTime("2010-12-31"),minmagnitude=6.5)
In [5]: print len(cat)
60
In [6]: print cat[0]
Event: 2010-12-25T13:16:38.180000Z | -19.837, +167.938 | 7.3 MW

          resource_id: ResourceIdentifier(id="smi:service.iris.edu/fdsnws/event/1/query?eventid=3207318")
           event_type: 'earthquake'

Hi Andrew,

the reason for the strange behavior is that when the client is initialized it launches a couple (I think 5) of HTTP requests to discover the capabilities of the FDSNWS node in question.

Sometimes some of these requests fail (either the node does not have some of the services or due to some other network related problem); in theory it should then print a nice error message. Here we just don’t catch that particular exception. This all looks awfully familiar to me so I think this should be fixed in the latest master on Github. Can you check?

You might also have noticed that you cannot catch the exceptions (as they are being raised in other threads…). In any case, after the client has been initialized you can check

client.services

to see what services (and the detailed capabilities of each) have been discovered. So for IRIS you can usually expect all three. I am a bit surprised you see this behaviour with IRIS as their service is usually very stable. To figure out which request exactly triggers the exception (or if different ones are responsible), you can initialize the client with debug=True; this prints a lot of debugging messages so it might help to isolate the problem.

Cheers and all the best!

Lion

Hi Lion,

Thanks for the insight and advice. I'll see about checking out the latest master on GitHub and if I get the same behaviour.

I did notice that I couldn't catch the exceptions (I tried before sending my message). I'll check the available services after initialization, and also look at the debugging output. Do you know of a way to suppress these specific messages in the meantime (ie, allowing other error messages to still persist)?

Thanks very much,
Andrew