問題タブ [backlog]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
.net - .NET ソケット リッスン バックログ
一度に 1 つの接続を許可するように構成したサーバー ソケットがあります (セマフォで Accept 呼び出しをブロックすることにより)。バックログ キュー サイズは 1 です。つまり、.Listen(1) を呼び出しました。
次に、次のプロセスに従います。
- サーバー ソケットで AcceptAsync を呼び出します (1 回だけ)
- クライアントConnectAsyncがあります(正常に接続します)
- 私はクライアントConnectAsyncを持っています(おそらくキューに接続されています...伝える方法がいいでしょう)
- 3 番目のクライアント ConnectAsync があります
これら 3 つの ConnectAsync 呼び出しは、立て続けに発生します。
3 番目の ConnectAsync の予想される結果は、SocketAsyncEventArgs の "SocketError" プロパティが "SocketError.Success" 以外のものになることです。具体的には、「SocketError.ConnectionRefused」を実際に期待しています。
約 95% の確率で、これが当てはまります。3 番目のクライアントのコールバックは、Success 以外の SocketError 値を返します。
ただし、ときどき、3 番目の ConnectAsync が 2 番目の ConnectAsync と同じように "機能" します。EventArgs.SocketError は SocketError.Success を返し、対応する Socket.Connected プロパティは "true" を読み取ります。
どうしたの?AcceptAsync を1 回だけ呼び出します(ブレークポイントでこれを注意深く確認しました)。したがって、1 つのクライアントのみを受け入れ、残りはバックログ キューに入れる必要があります。私のキュー サイズは 1 ですが、3 番目のクライアントはどのように正常に接続していますか?
より大きなキュー サイズを使用するように言わないでください。これは、私が作成したテスト関数用であり、積極的にクライアントにサービスを提供しているコードではありません。この時点で、それはより好奇心です。:)
ruby - Heroku.comでホストされているRedmineにプラグインをインストールする方法
redmineをherokuプラットフォームにプッシュしただけですが、バックログプラグインを機能させることはできませんが、ローカルでは問題なく機能します。
ローカルデータベースをherokuaswwellにプッシュしました。
java - Javaのサーバーソケットのキューにある接続数を確認してください
サーバーソケットを作成し、さまざまなクライアントからの接続を受け入れるJavaプログラムがあります。
キューにある(サーバーによって処理されるのを待っている)接続の数を調べることに興味があります。backlogパラメーターを指定せずにデフォルトのコンストラクターを使用しました。
実行時に、サーバーで保留中の接続の数を知ることは可能ですか?
キューがどれだけいっぱいであるかをチェックし、それに基づいて負荷分散のためにクローンプロセスをトリガーする監視プロセスを実装したいと思います(接続が切断されないようにするため)。
heroku - バックログが深すぎるために Heroku が拒否したリクエストの量を測定する最良の方法は何ですか?
Heroku の Bamboo-mri-1.9.2 スタックで Rail 2.3 を実行しています。ただし、スケーリングの問題が発生しています。トラフィックのピーク時に、エラー H11 (バックログが深すぎる) が表示され、New Relic の監視を介して、バックログが多いことを確認できます。ただし、今知りたいのは、キューの長さではなく、Heroku によって拒否された着信要求の数です (Heroku ログで「エラー H11 (バックログが深すぎます)」という結果になります)。
要するに、着信リクエストの総数に対する拒否された着信リクエストの比率を知りたいです。
Heroku が言ったように、ログ ファイルは主にデバッグ目的で使用されますが、実際のライブ メトリックの分析には使用されません。それを行う簡単で無料の方法はありますか?
ありがとう!
PS この投稿にコメントするHow to keep log tail alive on Heroku using ssh? papertrailapp.com の Web サイト (明らかに papertrail の gem とは関係ありません) を使用することを提案しましたが、H11 のバックログが深すぎるエラーの比率を示すことができるかどうかを判断できませんでした。
agile - レール上でスクラムを行うための無料のオンライン アプリケーション
ruby on rails アプリケーションでアジャイルな開発と管理を行うのに役立つ最高の無料オンライン ソフトウェアは何ですか?
私が探しているのは、複数の人が操作できるオンライン フォームです。
- 企画ポーカー
- イテレーション/スプリント
- 速度計算/予測
- バックログの優先順位付け
- ポイント値のあるストーリー
おまけ: そして多分 github と統合する方法
scrumdo を試してみましたが、もっと優れた無料のアプリケーションがあるかどうか疑問に思いました。
scrum - スクラム バックログの優先順位付け
私たちのソフトウェア会社は、文字通り 1 日に数百件のサポート リクエストを受け取り、チーム全体が受信箱に取り組んでいます。スクラムのバックログに直接対応する効果的な指標を得るにはどうすればよいでしょうか?
具体的すぎると、チームはメトリクスの変更に常に注意を払いすぎます。一般的すぎると、PO は信頼できる優先度を得るためにあまりにも多くのメールを分類しなければなりません。
何か案は?
tfs - スクラム フレームワークでのストーリー ポイントの規模の測定
このスクラムの記事によると:
ストーリー ポイントは、特定の時間数に直接変換されない相対的な値です。代わりに、ストーリー ポイントは、チームがユーザー ストーリーの全体的なサイズを定量化するのに役立ちます。これらの相対的な推定値は精度が低いため、決定するのに必要な労力が少なくて済み、長期にわたってより適切に保持されます。ストーリー ポイントで見積もることで、チームはユーザー ストーリーの全体的なサイズを提供し、後でチーム メンバーがユーザー ストーリーを実装しようとするときに、より詳細な作業時間の見積もりを作成します。
誰でも明確にできますか:
- ストーリー ポイントの測定尺度は何にする必要がありますか? 10、100、または特定の製品バックログで割り当てられた最高のストーリー ポイントのうちどれにする必要がありますか?
- (少しトピックから外れています) 「プロダクト バックログ アイテム」(添付の画像を確認してください) はプロジェクトのすべてのユーザー ストーリーで構成され、スプリント バックログにはプロダクト バックログのストーリーのサブセットが含まれます。そうは言っても; 1 つの製品バックログで十分な場合、なぜ TFS では複数の製品バックログ アイテムを使用できるのでしょうか?
iteration - TFS 2010 イテレーション バックログ - バーンダウン。更新していません
TFS 2010 によって生成されたイテレーション バックログで、バーンダウン チャートがデータで更新されません。常に以下のエラー メッセージが表示されます。チーム プロジェクトに「\イテレーション 1」があります。
反復パス '\Iteration 1' はキューブ内にありません。この反復パスを持つ作業項目があり、キューブが処理された後で再試行してください。
助けてください。アニーシュ
c - バックログのどの値を使用する必要がありますか?
私は男を読んだ 2 聞いてください。
バックログの値がわかりません。
backlog 引数は、sockfd の保留中の接続のキューが大きくなる可能性のある最大長を定義します
どうすれば最良の値を定義できますか?
ありがとう
c - バックログ値を無視するlisten()
私が理解しているように、バックログは接続キューのサイズを決定します。その時点でこのサイズを超える追加のリクエストはすべて破棄されます(このステートメントは正しいですか??)。
今、私は非常に単純なプログラムserver.cを持っています
今、私はこのサーバーに接続するために一度に8つのクライアントを起動します。驚いたことに、サーバーは8つのクライアントすべてにサービスを提供しますが、代わりに5つのクライアントのみをキューに入れ、残りの3つのクライアントの要求は拒否する必要があります。もう1つの興味深い点は、このバックログ値を0として設定しても、結果は同じであるということです。次に、listen()呼び出しにコメントを付けてみましたが、これにより8つのクライアント接続すべてが拒否されます。
誰かがこれに関する入力を提供できますか?