issue_comments: 195811187
This data as json
| html_url | issue_url | id | node_id | user | created_at | updated_at | author_association | body | reactions | performed_via_github_app | issue |
|---|---|---|---|---|---|---|---|---|---|---|---|
| https://github.com/pydata/xarray/issues/793#issuecomment-195811187 | https://api.github.com/repos/pydata/xarray/issues/793 | 195811187 | MDEyOklzc3VlQ29tbWVudDE5NTgxMTE4Nw== | 4295853 | 2016-03-12T21:30:14Z | 2016-03-12T21:30:14Z | CONTRIBUTOR | I can't fully confirm that the above scripts works with synchronous execution because the job ran out of its 16hr run time. However, it does appear to be the case that forcing synchronous execution resolves potential issues because previous runs of the script crashed and this one did not. I'll have to try more cases with synchronous execution, especially over the next half week, to see if I encounter more issues but am suspicious this is the problem. @mrocklin and I noted that the netCDF reader has problems when threading is on when we were using distributed, so this appears to be a likely candidate. We got the same I'm suspicious that the netCDF reader is not thread safe and may not have been compiled as such (http://hdf-forum.184993.n3.nabble.com/Activate-thread-safe-and-enable-cxx-in-HDF5-td2993951.html) but there appear other potential issues that could be part of the problem, e.g., https://github.com/Unidata/netcdf4-python/issues/279 because I am doing so many reads. It may also be possible, as you note @shoyer, that the tread locks aren't aggressive enough. It would probably be good to come up with some type of testing strategy to better isolate the problem... I'll have to give this more thought. |
{
"total_count": 0,
"+1": 0,
"-1": 0,
"laugh": 0,
"hooray": 0,
"confused": 0,
"heart": 0,
"rocket": 0,
"eyes": 0
} |
140291221 |