問題タブ [fiware-cosmos]
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.
fiware - Cygnus から Cosmos へのリアルタイム データの永続化は遅く、信頼性が低い
Cygnus のバージョンは 0.8.2 で、FI-Ware ラボ内の FI-Ware インスタンスから Cosmos のパブリック インスタンスを使用しています。
IDAS に更新をプッシュする 8 つのセンサー デバイスがあります。1 秒に 1 回の更新もあれば、5 秒に 1 回の更新もあり、平均して 1 秒あたり約 8,35 回更新されます。Orion (バージョン 0.22) へのサブスクリプションを作成して、ONCHANGE 通知を Cygnus に送信しました。
Cygnus は、データを Cosmos、Mongo、および MySQL に保持するように構成されています。1 つのソース (http-source)、3 つのチャネル (hdfs-channel mysql-channel mongo-channel)、および 3 つのシンク (hdfs-sink mysql-sink mongo-sink) の標準構成を使用しました。
mysql-sink と mongo-sink は、ほぼリアルタイムでデータを保持します。ただし、hdfs-sink は非常に遅く、1 秒あたり約 1.65 イベントしかありません。http-source は 1 秒あたり約 8,35 のイベントを受信するため、hdfs-channel はすぐにいっぱいになり、ログ ファイルに警告が表示されます。
副作用として、http-source が hdfs-channel に通知を注入できない場合、mysql-channel と mongo-channel にも通知が注入されず、その通知が完全に失われます。どこにも永続化されていません。
異なる http ソース ポート、異なる管理インターフェイス ポートを使用して 3 つの個別の Cygnus (Cosmos 用、MySQL 用、MongoDB 用) を起動し、各 Cygnus にサブスクリプションを追加することで、問題を部分的に回避できます。MySQL と MongoDB の永続化は、hdfs チャネルがいっぱいになっても影響を受けませんが、Cosmos の永続化にはまだ問題があります。hdfs-sink を追加すると、8 つのセンサー デバイスで問題が解決する可能性がありますが、センサー デバイスを追加したり、更新を送信したりすると、問題が先送りされるだけです。
これら2つの質問は少し関係ありませんが、とにかく尋ねています...
質問 1: コスモスへの固執がそれほど遅いというのは本当ですか?
ローカル データベースへの永続化と比較して、舞台裏で多くのことが行われていること、およびリソースが制限されている Cosmos のパブリック インスタンスを使用していることはわかっていますが、それでもなおです。リアルタイム データでそのように使用することを意図しているのでしょうか (当社の 8 センサー デバイス テストはかなり控えめです)? もちろん、データをファイルにプッシュするシンクを作成してから、Cosmos に単純なファイルをアップロードすることもできますが、少し手間がかかります。そのようなファイルシンクは利用できないと思いますか?
質問 2: 通知を hdfs チャネル (任意のチャネルだと思います) に挿入できない場合、他のチャネルにも追加されず、完全に破棄されるというのは本当ですか?
hadoop - Hadoop httpFS は常に HTTP/1.1 404 Not Found を返します
Hadoop の HttpFS サービスに問題があります。リソースをカールさせようとすると、次のようになります。
私が得る応答は次のとおりです。
しかし、webhdfsで同じことをしようとすると、うまくいきます:
Httpfs サービスはポート 14000 で実行されています。nmap で確認しました。問題の可能性がある提案やアイデアはありますか?
hadoop - ハイブ ポートが閉じられています
Hive クエリをリモートで起動したいと考えています。
そのために、私は hive-jdbc ライブラリ (0.14.0 バージョン) と hadoop-core (1.2.1 バージョン) を使用しています。
数週間前、次のコードを起動しました。
それは動作しますが、今はこのエラーが発生しています:
Hive ポート (10000) が閉じられていることがわかりました。
したがって、リモート ハイブ クライアントを使用してコスモスにアクセスする正しい方法は何か、またはコスモスからデータを取得する方法を変更する必要があるかどうか疑問に思っています。
fiware - コスモス認証と ID マネージャーの統合に関する問題
cosmos-auth を Idm GE と統合したいと考えています。node.js アプリケーションの構成は次のとおりです。
HTTP POSTリクエストをIDM GEに直接送信してurlに送信すると
必要なパラメータを使用すると、OKの結果が得られます:
しかし、cosmos-auth node.js アプリケーションを curl すると
次の結果が得られます:
誰かが似たようなことに遭遇しましたか?何が問題なのですか?
fiware - IDM GE、PEP プロキシ、および Cosmos ビッグ データを統合するための PEP プロキシ構成ファイル
PEP プロキシ ファイルについて質問があります。Keystone サービスは 192.168.4.33:5000 で実行されています。Horizon サービスは 192.168.4.33:443 で実行されています。
私の WebHDFS サービスは 192.168.4.180:50070 で実行されており、192.168.4.180:80 で PEP プロキシを実行するつもりです
しかし、私が得られないのは、config.account_host の代わりに何を入れるべきかということです。keyrock manager の mysql データベース内には、「idm」パスワードを持つ「idm」ユーザーがあり、Identity manager で curl を介して行うすべての要求が機能します。
しかし、この構成では:
pep-proxy を起動すると:
次のエラーが発生します:
hadoop - Fiware Cosmos Hive 承認の問題
Fiware Cosmosの共有インスタンスを使用しています(つまり、root 権限を持っていません)。私は今日まで、jdbc と Hive CLI の両方をリモートで使用して、Hive のテーブルに正常にアクセスし、管理してきました。しかし、Hive CLI を開始すると、次のエラーが発生します。
ただし、Hive CLI で選択と作成を実行できます。次に、リモートで Hive にアクセスしようとすると、次のようになります。
エラーが発生する前にコードやコマンドに変更を加えていませんでした。
問題がどこにあるのか、それを見つける方法、またはそれを解決する方法を誰かが教えてくれれば、私は感謝しています。
前もって感謝します!
fiware - keystone による認証後に Cosmos-gui アプリケーションがクラッシュする
私は問題があります。keystone で認証しようとすると、cosmos gui アプリケーションがクラッシュします。Horizon アプリケーションはhttps://192.168.4.33:443で実行され、cosmos-gui はhttp://192.168.4.180:81で実行されます。私の gui 設定ファイルは次のようになります。
}、
そして地平線の中で私はパラメータでアプリケーションCosmos Big dataを登録しました:
その後、cosmos-gui アプリケーションを起動し、ログインをクリックすると、次の URL にリダイレクトされます。
それは問題ありません。しかし、承認ボタンをクリックすると、次の URL に移動します。
その瞬間、cosmos-gui アプリケーションがクラッシュし、ログから得られるものはすべて次のとおりです。
keystone 側では、すべて問題ないように見えます。これは keystones ログからのものです。