Hi
I seem to be having some problems running a SLClient application using obspy 0.10.2 trying to retrieve the stream GE.SLIT..HHZ from geofon.gfz-potsdam.de:18000 the application stops after a few seconds to a few minutes
Digging into the source code the client seems to choke upon a returned slpack being equal to SLPacket.SLTERMINATE in the run() method of. However, overriding the run() method by copy and paste and then editing the if statement that captures slpack==SLPacket.SLTERMINATE to verify by retrieving a second package and retry, it seem that the connection to the server have not been terminated as the second package do contain trace data (the attached cleaned script demonstrates my issues).
The question here is what would be the proper way to handle this? I can come to think of two
1. overridding the run() method in my application to perform this second test. The drawback then is that the stream ends up with a gaps in the stream
2. restarting the application in an infinite while loop in which case I can set the begin_time attribute of SLClient to pre-date the time of the last retrieved data to try to avoid gaps.
Personally I would prefer the first option as in the end there may be valid causes to stop trying to connect to the server, but then the question is the best way to try to avoid the gaps in the streams?
regP
testSLClient.py (3.42 KB)
Hi,
I solved it for now by writing a wrapper function (i.e. second option in my original post).
In case this may be of used to anyone else this is what I came up with
regP
from obspy.core import UTCDateTime�
def run_SLClient(slc,max_attempts=2,max_lookback=600):
�� “”“��
�� function run_SLClient() is a wrapper for SLClient.run() to allow
�� reconnecting a seedlink server and trying to retrieve missing data
��
�� ======= Parameters =======
�� :type� slc: obspy SLClient object
�� :param slc: seedlink client application that have been properly initialized
��������������� it is assumed that the object has an attribute named stream
�� —
�� :type� max_attempts: int or None
�� :param max_attempts: maximum number of times to try to re-connect to server
������������������������ if no new data have been retrieved since last attempt
������������������������ if None no upper limit is set
�� —
�� :type� max_lookback: float or None
�� :param max_lookback: maximum lookback time relative present time when trying
������������������������ to reconnect to server, if time of last retrieved datapoint
������������������������ for a stream exceeds this stream may come to contain gaps.
������������������������ If None no upper limit is set
�� —
�� Author: Peter Schmidt, SNSN, Uppsala university, Sweden
�� “””
�� last_data = {}
�� attempts = 0
�� while 1:
����� slc.run()
����� # client terminated, increase attempts counter
����� attempts += 1
����� if slc.stream:
�������� # check if any traces have been updated since last attempt
�������� for trace in slc.stream:
����������� # we do the check in a try-except clausule as this generally is faster than a list search
����������� try:
�������������� if last_data[trace.id] != trace.stats.endtime:
����������������� # new data have been added
����������������� raise Exception
����������� except:
�������������� # New data have been added, update tracker and reset attempts counter
�������������� last_data[trace.id] = trace.stats.endtime
�������������� attempts = 0
����� if max_attempts is not None and attempts > max_attempts:
�������� # to many attempts, break here
�������� break
����� elif not attempts:
�������� # reset begin_time to try to retrieve missing data from streams
�������� begin_time = min(last_data.values())
�������� if max_lookback is not None:
����������� # check that max_lookback is not exceeded
����������� now = UTCDateTime()
����������� begin_time = now-max_lookback if now-max_lookback > begin_time else begin_time
�������� slc.begin_time = (begin_time-1).formatSeedLink() # ask for an extra second to be on the saefe side
�������� slc.initialize()
Hi Peter,
while I have no solution to your problem, I propose to
* run your test script in a loop to restart automatically and see every how often the error occurs
* let your test script log the start times, sequence numbers etc. of all received records
* run 'slinktool -S GE_SLIT:HHZ -p -p -v -v geofon.gfz-potsdam.de:18000' in parallel for comparison
Maybe this can give some clue.
Cheers
Joachim
Hi Joachim
The restart occurs approximatelly every 30s as I wright this but I will modify it to log more thoroughly (think I need to fiddle with obspy to crack that nut) to see if this gives some more info, as well as running slinktool in parrallel, thanks for the input
regP