番台がエラーで、それぞれクライアント側のエラーなのか、サーバー側のエラーなのかを分類しています。番のステータスコードが返されているのでした。返ってきたら成功」と決めつけて実装していたため、このようなケースに対処できていなかったのでした。ここまでが実際に目の当たりにしたエラーとその原因でした。以下はこの件に関して自分が考えたことです。番台で返ってくるべきでは?」という考えもないわけではありません。番のステータスコードがあながち間違ってはいないような気もしています。その理由として、まず「これはクライアントエラーなのか?それともサーバーエラーなのか?どちらかに分類できるのか?」という問題です。これに関してはどちらとも言えるし、どちらとも言えないと思っています。(お金を払わないといけないんだけど)払ってないエラー、と定義されています。実際には定義だけで実装されていない、つまり将来のための定義とされているのでした。番に(クライアントエラーに)該当するエラーであるとは考えにくいのです。いう考え方もあるとは思います。番台エラーには該当しないと思います。サーバーエラーなのか?というと、これも該当しないと思います。プログラミングにミスがあったわけではなく、「実行したら、『実行できない』という結果が返ってきた」のは、正しく実行された(結果が期待通りではなかった)とも言えます。レベルではエラーですらないとも言えます。番のステータスコードが返ってきてもエラーの可能性を疑ってコーディングする必要があるのかも、と思うようになりました。このケースであれば実装側が工夫すれば(というか、そもそもちゃんと色んなケースを想定してエラーハンドリングしていれば)防げるものです。いう意味でもいい反省の機会でした。今後は同様のケースを想定した「成功でもエラーでもないステータス」が出て来る可能性もありますよね。書かれているのでメモリ不足な状態になっているように見えます。(1オブジェクトあたりの)ヒープサイズが足りなくなっている、というメッセージです。物理メモリを大量に搭載しているサーバーでも、サイズの巨大なファイルを扱ったり、大容量のアウトプットデータを取り扱おうとするとこのエラーは起こりうる、ということになります。実行時にパラメータを指定することで可能です。ヒープサイズ」の指定なので、他に使うサーバーアプリとの兼ね合いやスワップも含めた物理メモリサイズも含めて指定サイズを見積もる必要があります。ブログ検索」ブログパーツは、サービスを終了しました。