8

現在、本番環境では JBoss 5.1 を実行しており、JBoss 7.1 に移行する価値があるかどうかについて議論しています。単純なサーバーのアップグレードであれば、問題にはなりません。しかし、残念ながら、構成を変更する必要があり、それには多少の労力がかかります。また、私たちのサーバーはクラスターで実行されており、JBoss 7.1 にはより多くのクラスター サポートがあることを読みました。

それで、それは価値がありますか？

ありがとう

4

4 に答える 4

12

私たちは現在、同じ状況にあります。

ポジティブな面がたくさんあるようです。

  • ある時点で 5.1 から移行する必要があります。完全なプロファイルが必要であり、OSS の代替手段はそれほど多くありません (GlassFish やおそらく Geronimo)。PCI-DSS では EoL されたソフトウェアの使用が禁止されているため、その点だけでも移行を売り込むことになるでしょう。
  • 構成ははるかに優れており、よりシンプルです。XML ファイルでアスペクトを構成する 20 個の XML ファイルに分散するのではなく、1 つの中心的な場所になります。すべてのポートが 1 か所で構成され、server.xml を変換する XSL ファイルはなくなりました。クラスの実装の詳細を知らなくても、構成ファイルを理解できます。JBoss を設定したことがない場合、これを理解するのは困難です。
  • EJB リモート処理は、ソケットごとにスレッドを使用しなくなりました。
  • 不要なサブシステムを削除するのはとても簡単です。
  • クラス ロード モデルは正常に見え、jboss-deployment-structure.xml を介して多くの制御が可能です。
  • EJB クライアント ライブラリは、さらにクリーンアップされたように見えます。JAR が 20 から 10 に減り、その半分は OSGi バンドルです (クライアントは Eclipse RCP アプリケーションです)。
  • Java EE 6 で SLSB の一部が @Singleton Bean に置き換えられ、SAR の一部がタイマー EJB に置き換えられることについては、あまり期待していませんが、確かに興味深いものです。
  • 起動が速くなり、メモリ使用量が少なくなります (少なくとも空のサーバーまたは小規模な展開の場合)。大規模な展開はまだテストしていません。
  • 展開フォルダはデフォルトで空です

まだ調べる必要があること:

  • Infinispan のパフォーマンスが少し心配です。現在、JBoss Cache の TreeCache API を使用しています。同じ API を提供する Infinispan 用のアダプターがありますが、いくつかの理論的なテストでは書き込みパフォーマンスが低下しています。これは、Infinispan のツリー API にのみ適用されます。
  • ExternalContext はサポートされなくなりました。現在は .bindings ファイルから JNDI ツリーを作成するために使用しています。
  • JMX コンソールはなくなっています。これに基づいて構築するものがある場合は、それを調整する必要があります。実際に編集して、利用可能な JMX コンソールのポートがありますAS7-2227

クラスターで実行していないため、コメントできません。

おそらく最大の作業は、JBoss と何らかの形で対話するすべてのシェル スクリプト (インストール、統合テストなど) を移行することです。

アップデート

私たちは移行しましたが、それは間違いなく価値がありました。上記の点のいくつかの更新:

  • 大規模な展開でも、最小限の調整で高速です。
  • 集中ログ (Slf4j、JUL、JCL、Log4j など) は非常に優れています。
  • 7.1 には非常に多くのバグがあり、使用できませんでした。そのため、現在 7.2 / EAP 6.1 を使用しており、7.3 / EAP 6.2 に移行する予定です。まだかなりの数のバグがありますが、回避することができます。特に、最小限の権限でスクリプトを実行できるようにする管理インターフェイスの役割ベースのアクセス制御を楽しみにしています。
  • GlassFish 4 のサポートされているバージョンは、本番環境での使用に大きな疑問符を付けるものではありません。
  • EJB リモート セキュリティは、柔軟性が大幅に低下します。以前は認証された EJB 呼び出しと認証されていない EJB 呼び出しを混在させていたため、いくつかの回避策を講じる必要がありましたが、これはもはや不可能です。
  • JBoss の JEE 6 BOM POM は混合バッグです。理論的には、すべての JEE 依存関係のバージョンを管理するので便利です。実際には、artifactId のバージョンとの調整はひどいものであり、JEE 7 に移行するときに煩わしくなります。また、テスト用に JEE API の実装を含めたい場合にもあまり役に立ちません。
  • Infinispan ツリー API のパフォーマンスは問題ではありませんでした。
  • JMX コンソール スクリプトを DMR スクリプトに置き換えました。

更新 2

  • SSL を介した EJB リモート処理を使用すると、デッドロックが発生します。このデッドロックは EAP 6.2 でも存在します。現在、WildFly から AS 7 にバックポートされた機能のかなりのパッチ セットがある時点にいます。
于 2012-04-22T15:37:03.330 に答える
1

JBoss 5.1.0 ですべてが動作していますか? あなたのパフォーマンスはあなたが生きていけるものですか？

現在、JBoss 5.1.0GA から JBoss 7.1.1 へのアップグレードの最中ですが、まったく簡単ではありませんでした。基本的に、新しいアプリケーション サーバーにアップグレードしています。この取り組みには多額の予算が必要になると思います。

JBoss 7.1.1 は 5.1.0 に比べて非常に高速です (少なくとも起動時間)。次の 6 か月間 (またはその前後) に、「難しい」移行と移行の問題のほとんどが、jboss フォーラムまたはバグ修正を通じて具体化されると思います。その時点で、あなたとあなたのチームは、移行を行うかどうかを再評価できます。

幸運を！

于 2012-06-12T16:50:08.247 に答える
1

とにかく、私は少し待ちます。

AS 5 は EE5 サーバー、AS 7.1 は EE6 サーバーです (EE6 仕様は 2009 年に公開されました)。これは、優れた新しいランタイム環境を作成するための多くの作業ですが、アーキテクチャ上の可能性を提供するものではありません。

WildFly 8.0.0.CR1 はすでに期限が切れており、これは EE7 サーバーであり、WebSockets や JAX-RS 2.0 ( http://www.slideshare.net/dandreadis/2013-11devoxxwild-flybof )など、新しい興味深い開発の可能性をもたらします。 . 単一インスタンスのパッチ適用などの新しい管理機能。また、JBossWeb/Tomcat の代わりに Undertow などのいくつかの主要な新しい機能が導入されているため、AS7 から WildFly8 への移行が非常に簡単になるかどうかはわかりません。

行かなければならないなら、行かなければならない - そして、U が死んだ 7.x パスを巻き戻す場合は、大幅に改善された 7.2.0.Final タグを手に入れることを忘れないでください (数百の問題は 7.1.1 よりも優れています)。しかし、ベータ/CR リリースを使用して今すぐ開発/移行を開始し、本番環境で安定した素晴らしい WildFly 8.xx リリースを数か月待つことができると思われる場合は、次のメジャー アップデートまでもう少し待つことができるかもしれません。

br、イェンス

于 2013-12-08T18:43:45.990 に答える