便利機能のメモ
2日以内に更新のあったものを見つける
find . -mtime -2 -ls
3日以内に更新のあったものを見つける
find . -mtime -3 -ls
便利機能のメモ
2日以内に更新のあったものを見つける
find . -mtime -2 -ls
3日以内に更新のあったものを見つける
find . -mtime -3 -ls
連投・・・
土日のREST APIがハングしなかった・・・
今しがた、コンソール叩いてレスポンスヘッダー見てみたら
chunkの文字が見当たらない・・・
ちょっと前までchunkがあったと思っていたんだけど・・・
?もしかして、twitter側でchunkやめたのか??
かなり安定しているんだけど、、chunkのせいだったのか・・・
もう少し様子を見よう・・・
追記(2014-05-20 20:45):そんなことはなかったorz
ご無沙汰しております。
表題の件について、ひとつ愚痴を・・・
自分自身のtwitterアカウントのusertimlineを、「REST API」を使用しcronで定期的に取得していたところ・・・
取得が終わらず取得プログラムのプロセスが、ずっと残っているではありませんかorz
この原因を色々調べてみたけど良く分からないo…rz
プログラムにどこまで実行できたのかをlogに出力したところ、「REST API」にリクエストを投げ(file_get_contentsを使用)て返ってこないことがわかりました。
本当に返ってきていないか調べるためにfile_get_contentsではなく、fopenで接続をしてからfreadで1バイトずつ、ファイルに出力したところ・・・jsonデータがファイルに出力されていました。
と言うことは?どういうこと??
feof関数のマニュアル以下抜粋
返り値
ファイルポインタが EOF に達しているかまたはエラー (ソケットタイムアウトを含みます) の場合に TRUE 、 その他の場合に FALSE を返します。注意
警告
fsockopen() でオープンした接続がサーバーによって閉じられていない場合、feof() はハングします。回避策は以下の例を参照ください。
“オープンした接続がサーバーによって閉じられていない場合、feof() はハングします。”
プロセスが終わらず残っていたのは、ハングしてたからか?というメボシをつけてみた・・・
で、twitterなので、freadで固定バイト数ずつ読み込んで結合し、その文字列がjson_decodeでfalseを返さない場合、while文を抜けるようにしてみたところ上手くこの処理で抜ける場合の「REST API」のリクエストがあった、これで十中八九『EOF』がtwitterのサーバーから送られていないと思われ・・
※上記のwhile文を抜けるもう少し詳しい条件としは、!feof($fp)の場合で、json_decode($str)がfalseではない場合にbreakです。
結局、REST APIのリクエストが届くサーバーが、EOFを返すサーバーと返さないサーバーがあるということで、どうもこの返さないサーバーにあたることが多いのが問題・・・
ていうか、twitterさんeof返しておくれ・・・