問題タブ [glassfish-4.1.1]

最近、Glassfish を 4.0 から 4.1 にアップグレードしました。Windows 8.1 を使用しています。

アプリケーション (WAR) をアンデプロイ/再デプロイしようとすると、asadmin が無期限にハングします。

問題は、内部のすべての JARdomain1\applications\myapp\WEB-INF\libがロックされており、Glassfish が停止または強制終了されるまで削除できないことです。

回避策が必要です。

アップデート

問題はGLASSFISH-21283 に登録されています。ご覧のとおり、それを解決することに興味はありません...

Glassfish-4.1.1 では、アンデプロイ/再デプロイはまだ許可されていません...
Payara もテストしましたが、同じ問題が発生しました... あきらめました。

しかし、疑問が残ります: Windows での開発/運用に GlassFish を使用している人はどれくらいいますか? 世界中でダース？
これは重大な問題であり、1 年以上未解決です。

Glassfish では、EJB トランザクション タイムアウトはデフォルトで 120 秒に設定されています。この値を変更したいと考えています。

glassfish-ejb-jar.xml で「cmt-timeout-in-seconds」パラメーターを定義することで変更できることはわかっていますが、EJB クラスを含む Web モジュールを使用し、glassfish-web.xml を使用します。それぞれ。

タイムアウトを変更する方法はありますか?

UPD:

トランザクション サービス設定のトランザクション タイムアウト値は影響しません。

上記のコードは正常に動作します。ただし、スリープ時間を 121 秒に変更する場合

GF Server ログに次のエラーが表示されます。

この後、サービスは doSomething() メソッドをもう一度呼び出し、2 分後に再びエラーが表示されます。

サービスは doSomething() メソッドを呼び出さなくなりました。

私はグラスフィッシュが初めてです。私はRam 512 mbでdigitaloceanにvpsを持っています。1 つのドメインと 1 つの単純な Web サービス アプリケーションを実行しているだけです。しかし、グラスフィッシュは私の命令なしで止まります。何か提案はありますか？

私はグラスフィッシュ4.1.1を使用しています

トレバーのために編集します。エラーログについては言い忘れました。エラーログを確認しました。エラーまたはグラスフィッシュが停止する理由を示すログはありません。再起動すると問題なく動作しますが、数時間後に再び発生します

最近まで私は使用してきました：

私は最近、以下を使用して調査しました。

非常に大きな JSF Web アプリ (JPA 永続化プロバイダーとして ObjectDB を使用) では、Glassfish4.1 (約 2 分) よりも Glassfish4.1.1 (10 分以上) へのデプロイ時間が大幅に長くなります。それは約5倍遅いです。

[編集: 2016-09-13 Payara 163 Full (Payara Server 4.1.1.163) で試したところ、Glassfish4.1.1 よりもさらに遅く、ほぼ同じ設定で 20 分以上かかりました]

ここで再現したり、大規模な Web アプリの例を提供したりすることはできません。

Q1: Glassfish-4.1 と Glassfish-4.1.1 [編集: または Payara Server 4.1.1.163]の間で同様の違いを経験した人はいますか?違いのポイントはどこで探すことができますか?

(私はすでに NetBeans Profiler を使用して調査しようとしていますが、原因を見つけるのはまだ簡単ではありません。)

[編集: 2016 年 9 月 15 日のタイミング テスト]

スクリーンキャストの記録を使用して慎重に並べて比較し、ログのタイミングと比較しました。

Payara41 (4.1.1.163) と Glassfish4.1.1 では、以下に示すように約 10 分間「スタック」します。問題が発生した場所で 1 行の出力を提供するログ設定が見つかりませんでした。 DEBUG モードも追加情報を提供しないようです。

...すべてのステップを正常に実行し、次に多数のこれらの EJB JNDI 名宣言を実行します。

次の WELD バージョン メッセージが表示されます。

...その後、このメッセージが表示されるまでに約 8 秒かかります..

...その後、これらの無害な警告を再開する前に、何分も (通常は約 10 分)かかります..

]]

Glassfish4.1 ログにも同様の警告メッセージが表示されますが、長い一時停止/ホールドアップはありません。

Q2: 何年もの間そこで一時停止/失速している理由を調べるには、他に何ができますか?

https://java.net/jira/browse/GLASSFISH-21238によると、修正は Glassfish 4.1.1 に存在します。これは、http リスナー プロパティを設定することで適用されます。

このプロパティを設定しましたが、リクエスト ボディ メソッドで削除を呼び出すと、 HTTP 400が返されます。

私の質問:

• これを機能させるために必要な別の設定はありますか?
• この修正は本当に Glassfish 4.1.1 に含まれていますか?

何年も前からGlassfish 3.1.1で正常に動作するJEE6アプリケーションがある場合。JEE7 / Glassfish 4.1.1 に移行する必要があり、JPA / Eclipselink に関するいくつかの問題に遭遇しました。

a)一方向の OneToMany 関係としてマップされた 2 つのリストを含むエンティティApplicantがあります。

およびエンティティ ITKEnntnis

これまでは、addKenntnis を使用して申請者に ITKentnis の新しいインスタンスを追加し、申請者を永続化するだけでした。Glassfish 4.1.1 ではエラーが発生します ->

javax.persistence.PersistenceException: 例外 [EclipseLink-4002] (Eclipse Persistence Services - 2.6.2.qualifier): org.eclipse.persistence.exceptions.DatabaseException Internal Exception: java.sql.SQLException: Field 'BewerberID' does not haveデフォルト値 エラーコード: 1364

フィールド「BewerberID」は、データベース テーブルの外部キーであり、null にすることはできず、この定義を変更できません。

これまでに見つけた唯一の回避策は、関係を双方向に再定義することでした。私は多くの関係を持ち、コードは JPA 2.0 で動作したため、より簡単な解決策があれば幸いです。

b) Applicant への一方向の @ManyToOne 関係を定義するエンティティApplicationがあります。

これが良い設計であるかどうかに関係なく (そのようにマッピングする理由がありました) -> エンティティを削除しようとすると、フィールド「BewerberID」を削除ではなく null に設定する更新が表示されます。それがJPA 2.1にあるのはなぜですか?どうすればそれを変更できますか?

長い投稿で申し訳ありません。

トーマス

編集: これらの問題についてさらに調査し、Glasfish 3.1.1 で生成された SQL ステートメントをデバッグしました。動作しているサーバー。

新しい子エンティティの追加には、新しいサーバーと同じ次の SQL ステートメントがあります ->

違いは、フィールド「BewerberID」を NULL にできないため、新しいサーバーでは INSERT が失敗することです。どういうわけかデータベースのチェックが違うようです。

同じことが、次の出力を持つ DELETE にも当てはまります ->

新しいサーバーには同じ更新ステートメント「UPDATE bewerbungen SET BewerberID = ?, ....」があるため、興味深いですが、null 制約ですぐに失敗します。

Bean は次のように単純に定義されます。

そして継承するクラスはClientBehaviorBase

taglibファイルで-

-のようなエントリcontext-paramでweb.xml

フロントレイヤーでこのカスタムタグにアクセスします-

内部で使用されているバージョンのGlassfishアプリケーション サーバー4.1.1を使用しています。Mojarra 2.2.12

私はNPEここを持っています-