時間を経過するとAndroidプログラム起動で必ず落ちる

毎度、お騒がせしています。Onnetです。

ログイン画面を作り、メニューから業務画面をすこしづつ作成しています（在庫確認、勤怠打刻）。
そして、ユーザに「どうだ、すごいでしょ」とデモしています。皆さんスマホ好きですから「すごいね」と言ってくれます。

その際、
・アイコン押下
・スプラッシュ画面
・初期画面表示
（ここまでは完璧です）
・ログイン画面で、ユーザの存在チェックを照会リンクで行うと、初回に「エラー（-197）が発生しました。システム管理者に連絡してください」と出ます。
（ユーザにテキトーなことを言ってごまかして、何食わぬ顔で）
・再度起動するとすべてうまくいきます。
・客先はまだ気づいていないので、商談も進んでいます。

本件もどうしても解決する必要があります。
回避策があれば教えてください。
よろしくお願いします。

外しているかもしれませんが・・・・
ヘルプ →
トラブルシューティング
> パーティショニングエラー
> -197 ERR CTX NOT FOUND
はいかがでしょうか？

nkmtさん
超低速開発のonnetです。

ご指摘ページを確認しました。
状況が分かってきました。

コンテキストIDが時間経過で、サーバ側で消えるためと思います。
原因が分かりましたので、対策を考えます。

改善しましたら報告します。
超、ありがとうございました。

途中経過です。

こんにちは。
コンテキスト非同期タイムアウトをしていた
という事なんですかね。

Android上で前回起動した画面を残したままにしていたとかですか？

昔、私もこの内容で困ったことがありました。
イベントで５分おきにサーバーに通信を行うプログラムを起動させています。

こんにちは。
外しているかもしれませんが・・・・
動作環境設定 → コンテキスト非稼動タイムアウトの時間を
長くするはどうなんですかね？

onnetさん、

「コンテキスト非稼働タイムアウト」は動作環境の「アプリケーション
サーバ」→「コンテキスト非稼働タイムアウト」で変更できます。

デフォルトは24時間となっていますので、24時間以上アクセスがないと
コンテキストが抹消されることになります。

このコンテキスト非稼働タイムアウトを使用したくない場合は、メイン
プログラム上で独自のプログラムを稼働させて、エンドユーザ宛に
メッセージを表示させるようにするといいと思います。

メッセージの例：

「長時間のアクセスがありませんでしたので、サーバとの接続を一旦、
解除いたしました。プログラムを再起動して実行してください。」

オンラインゲーム等でよくあるやり取りですね。

注意：

1コンテキストに付き、1ライセンスが消費されますので、コンテキスト
の常駐時間が長すぎると、ライセンスの消費が激しくなります。

また、メモリも大量に消費されます。

ちなみに、初期のころはデフォルトが10分でしたので、お昼休みから
帰ってくると、もうエラーが出てたという状況でした。（笑

tandaさん、みなさんありがとうございました。

みなさんのコメントから推測し、コンテキスト抹消間隔が、初期値１時間を見つけ出しました。
午前中プログラムで、終了（X）イベントで、CTXKILL関数を実行する様にして様子を見ました。
理由は、CTXのIDが端末側に残っており、再実行した時に、そのIDで呼ぶためと思ったからです。KILLすれば、IDなしなのでサーバ確認が無いとの仮説を立てました。
でもダメだったです。他の方法を模索します。

Tandaさんの案（再起動促しメッセージ）が良いのですが、エラー検出方法がわかりません。Tryみたいなことができますか？すみません。

デフォルトは２４時間ではなかったですか？

ヘルプを見ると１時間というところと２４時間と２つありますね・・・

ただ実際のＭＡＧＩＣ．ＩＮＩを見ると２４時間だと思われます。

CtxClose関数、CtxKill関数ともに使った事がないのですが、
これはモバイル端末側で今自分が動いている分に対して
発行出来るもんなんですかね？

まさかサーバー側で監視PGを別途動かすのですかね？
モバイルRIAの稼働を提供した事は有りますが、長時間客先現地
で動かした経験はなくわかりません。

ISHIJIMAさん、Onnetです。
ヘルプの説明では、１時間になっていました。
こちらの感覚でも１時間くらいかなという感じです。
後で、実際の設定値を調べてみます。

この設定されているところはコンテキスト非稼働タイムアウトではなく別のところという事でしょうか

引用：

ＣＴＸ・・・関数はブローカーモニタを自作する場合に使用するものだと思っていました。

違っていたらすみません・・・

ISHIJIMAさん、Onnetです。

CTXKILLは、サーバ側で動作するものでした。当方側の勘違いでした。
今から、初期値を確認します。

Onnetです。
たびたびすみません。初期値は24時間になっていました。
とすると、１時間程度で必ずエラーになるということが分からなくなりました。

取り急ぎ、報告まで

タイムアウトという項目はいろいろありこれをすべて把握して設定をするのはなかなか大変だと思います。
私はこれを断念して５分毎にサーバーに通信をするようにしています。

ネットワークが切れた場合に通信する事は考えていませんが・・・
その場合はオフラインを使用するのでしょうか・・・

色々とありがとうございます。
本日は、この辺りで終了します。

明日は
・エラーイベントが取得できるか否かの調査
エラーが出た場合、「再実行促し」のメッセージ表示

の調査をします。

onnetさん、こんにちは


>ログイン画面で、ユーザの存在チェックを照会リンクで行うと、
>初回に「エラー（-197）が発生しました。システム管理者に連絡して>ください」と出ます。
---------------------------------------

僕の経験では、エラー（-197）が出るときには基本的にRIAサーバーがクラッシュしています。(XPA2.5）

同時刻のイベントログにアプリケーションの異常終了が起きていましたのでクラッシュ時にメモリーダンプをとったものをeサポに送って解析してもらいました。

プログラムの構造やメモリーテーブルの容量オーバーなどの要因でRIAサーバーがクラッシュすることもあるので、そっちも調査されてみては如何でしょうか？

たぶん、RIAサーバーは複数のインスタンスにそれぞれ複数のスレッドを割り当てられていると思いますので、1インスタンスがクラッシュしても、次に接続する際に別のインスタンスとセッションが張られれば、正常に動きますので、なかなか気がつきにくいところでもあります。


ちなみに、コンテキストIDはセッションを張る都度ユニークな値で生成されますので、同じコンテキストを複数で共有するということはありません。


HAYATO@アインシュタイン設計社

--
HAYATO@アインシュタイン設計社
-----------------------------
「MAGICサルベージサービス」
-----------------------------http://www.dbMAGIC.BIZ

HAYATOさん
ありがとうございます。Onnetです。
以下のご指摘で間違いないと思います。
ただ、RIAサーバ側か、弊社プログラムの問題かはあると思います。
ただ、試験的に組んだログイン画面なので簡単なものです。
状況の全体がつかめたので、本日、サポートに問い合わせます。

そう思った理由は、
・期間設定が24時間になっているにも関わらず、利用終了後、30分前後経過で落ちる（ちゃんと終了処理している）。
・一回セッション確率するとその後はうまくいく（初期起動の問題）
・IIS設定で何かあるのでは、と疑えること

などによります。
もう、数日経過いているので、くたびれました。
結果は、ご報告します。

ＭＢＲのＩＮＩファイルでＭＢＲ起動時にアプリケーションを実行されていると思いますがどのような設定になっていますか？

クライアントアプリを再起動すれば正常に動くということであれば、
サーバ側がダウンしていることはないと思います。

クライアント側からコンテキストが非稼働になっているかどうかを
検証するすべはまったくありません。なぜならば、コンテキストが
生きているかどうかを見に行く所作自体がサーバへのアクセスに
なってしまい、アクションが矛盾するからです。

メインプログラムで行う方法としては、コンテキストごとに最終
アクセス時間を保持して、そこから何分経過したらどのような
メッセージを表示させるかという処理ですね。メッセージを表示
させながら、明示的にコンテキストをKILLするという方法です。

昔作って、どこかで公開した覚えがあるのですが、どこに行って
しまったか見当たりません。すみません。

みなさん、
色々とありがとうございます。
現在、サポートにも問い合わせています。
その状況はまとまり次第、報告します。


以下が、Mbr.iniの内容です。

[MRB_ENV]
BrokerPort =5915
PasswordSupervisor = ****
PasswordQuery =

ReLoad = Y
;EnableFilters = Y
;Filters = HTTP_endusers:40% | SOAP_primary:10% | SOAP_secondary:5% | RemoteCalls:10% | COM:5%
;AllowReserve = N
QueueMaxSize = 1000
;ReqHistorySize = 20000
;ShutdownTimeout= 10
CommTimeout = 10
ServerTimeout =
;TerminateEnginesDuringShutdown=Y
;ActivityLog = BrokerActivity.log
;Log = (Broker.log F R)

[APPLICATIONS_LIST]
;Online = MgxpaRuntime.exe /DeploymentMode=R,C:\Program Files (x86)\Magicxpa\RIA Server 3.1,,,0,0
App1 = MgxpaRuntime.exe /DeploymentMode=B /StartApplication=C:\DM\MagicSample1.ecf,C:\Program Files (x86)\Magicxpa\RIA Server 3.1

[REMOTE_APPLICATIONS_LIST]
;RemoteApp1 = [remote server]/5915,,MyApp1,0,0
;RemoteApp2 = [remote server]/5915,,MyApp2,0,0

[APPLICATION_CLIENTS_MAP]

[APPLICATIONS_LIST]の最後の,,,0,0が設定されていないのでサンプルのオンラインと同じように設定されてみてはいかがでしょうか？

構文：エントリ名=<コマンド>,[<作業フォルダ>],[<ユーザ名>], [<パスワード>],[<MRB の初期化時に実行される回数>],[<起動されるエンジンの最大数>]

<MRB の初期化時に実行される回数>が「1」に設定された場合、定義されたアプリケーションの1つのインスタンスを読み込みます。

<起動されるエンジンの最大数>は、サーバに送られたリクエストが利用できるアプリケーションサーバを見つけることができない場合、MRBが追加で読み込むアプリケーションサーバ・エンジンを指定するために使用されます。

Tandaさん
大変、お世話になります。
サポートにも問い合わせています。結果はご報告します。

根本原因はともかく

まず初期画面（ログイン画面なんですけど）は表示されます。
そしてログインボタンを押すと、１回だけ落ちます。
アイコン再起動でうまく動作します。
落ちる時間は、最終利用から30分から40分の間です。


ですので、最終的には
・接続エラーをキャッチし、元のログイン画面を出したいんです。
・こんなこと、できますか？
・メイン部で記述するとのことで、エラーイベントは調べているんですが。

いろいろ、ありがとうございます。
大変、感謝しています。
名古屋近辺に出向くときは、あいさつに伺いたいです。
また、25日のMagic飲み会にも参加します。

みなさん、お騒がせしています。
中間報告します。

サポートに問い合わせたところ、「ネットワーク問題ではないか」とのことでした。ログ分析によるものと思いますが、根拠はわかりません。

で、本日は謙虚に以下の点を調査します。
仮説としては、Ａｚｕｒｅ環境における、動的アドレス付与との関係に問題があるのでは、ということです。
環境はVM＋SQLDatabaseです。

・TCP/IPの名前解決に於けるリゾルバキャシュとの絡み
-ipconfig /displaydnsとDNS側生存時間の関係で調査
・sqlcmdなどで定期バッチ処理（DB接続）による改善
‐定期的に接続/切断するリフレッシュ信号みたいなものを出してみる。
・初期DB接続に時間を要しているので（C#だとすぐに出来るんですが）
‐接続タイムの許容時間（Magicであるか否か）
‐リトライプログラミングの方法

ですかね。
結果はご報告します。
もし、改善が見られたら、クラウド上のアドレス解決、遅延などに考慮が必要ということになります。

最後に弊社は、業務システムの経験はありますが、ネットワーク、画面デザインなどは、素人です。
アタマから汁が出そうです。

onnetさん、

> 結果はご報告します。
> もし、改善が見られたら、クラウド上のアドレス解決、遅延などに考
> 慮が必要ということになります。

参考までですが、Amazon AWS では私のところでは今までそのようなこと
は一度も起こったことがありません。

onnetさん、

> 結果はご報告します。
> もし、改善が見られたら、クラウド上のアドレス解決、遅延などに考
> 慮が必要ということになります。

弊社でも、Amazon AWS EC2を利用して「おしえてスマホ」を動かしてます。
iPhone7で、今朝の07:07にloginしてメニューを出したままで20:58に再度、「おしえてスマホ」の操作は引き続き出てます。

みなさん、貴重な意見ありがとうございます。
特に、AWSで問題発生していな件、了解しました。

弊社の環境は
・Azure　VMからPaasであるSQLDatabaseを利用している関係です
・たぶん、VM自体にSQLDatabaseを載せれば問題が起きないかもしれません（環境準備が必要なのでまだ試験していません）。
・ただ、PaasであるSQLDatabaseは非常に便利で、
・弊社基幹業務（Magicではありません）を複数の会社に提供する場合、一台のVM内IIS側でSOAPで受けて、会社ごとのSQLDatabaseに接続しています。

さて、問題の件、サポートにも依頼して調査しています。
・動的DNSでの問題ではないと判断しました。
‐IPアドレスは変化していない
‐リゾルバキャシュの生存、クリアも関係なし
・次は
‐弊社プログラムの問題有無
‐VMとSQLDatabaseのセッション保持時間
‐MRBはセッション保持しているがSQLDatabaseのセッション保持が失われている可能性などを考えたいと思います。

その前に、対処方法が分り、問題再現しない場合は調査中止にしますが。
昨日までの報告でした。

皆さんのAWSは、VM内にDBですか？

onnetさん、

プログラムの問題なのか、あるいはインフラの問題なのかを切り分ける
ために私がよく使う手ですが、APGで作った程度のプログラムを一日
稼動させてみてはいかがでしょうか？

それでも止まるようであれば、明らかにインフラに問題があると言え
そうですね。

AWSはVM内にDBを持つこともできますし、別途RDSサービスでSQLを稼動
させることも可能です。非常に安定しています。

AWSの日本支社は、もともとは有志が集まってできた会社ですから、
きめの細かさと安定性には念が入っています。

tandaさん
色々とありがとうございます。AWSの件、了解です。

Azureも弊社は航空機内POS（C#とSOAP）にも使っていて問題ないんですよ。
今回は、多分MRB（ブラックボックス）とSQLDatabaseのセッション間の問題かも知れません。


１時間程度アンドロイドで画面表示（弊社のプログラムですが）して放置してみました。
再使用したらOpenエラーになりました。
でもこれってIISのセッション時間切れと思っていましたが、Magicの場合ずっと接続されるということですか？

−１９７のエラーが発生するのでは？
オープンエラーとは？

onnetさん、

前のコメントで環境設定がたいへんと書いておられましたが、やはり
VM内にDBを置いてテストしてみるのが一番なのではないでしょうか。

エラーで落ちても2回目の起動でつながると書いておられましたので、
ひょっとすると、DBとのセッションが切れたあと、再接続の処理で
タイムアウトを起こしている可能性もなきにしもあらずですね。

ISHIJIMAさん
お世話になります。

−１９７のエラー：
一度、APを動作させ、終了処理を行い、30分程度経過して、再度起動すると出ます。

オープンエラー：
弊社担当がMagic.ini内のログ出力するか、否かの設定を「出力する」に変えました。
その状態で、APを動作させたままにして（終了せずに）、再操作をしたら出ました。
説明足らずで、すみませんでした。

Tandaさん
そうですね。恐らくうまく行く感じがします。
ここを疑って、「接続許容時間の変更が出来るか？」とサポートに問い合わせたら「出来ない」とのことでした。

時間を見つけてDBを移して実験してみます。
ただ、弊社プログラム問題も疑っています。「教えてスマホ」を購入しましたので、作法も分析しようかと考えています。

同一VM内DBで出来ちゃったら、会社毎にDBを分離することをどうしようかとの課題も出ます。

皆さまに迷惑をかけていますので、恐縮しています。

だとするとTandaさんが言われているＤＢとの接続の関係だと思います。

Azureのアイドルタイムアウトって関係しますか？
使用した事がないのでわかりませんが・・・

https://blogs.msdn.microsoft.com/windowsazurej/2014/08/25/azure-load-balancer-2/

onnetさん、

ひょっとしたら、Azure側の対応でDBとのセッションを切らない方法
がないかどうかをMicrosoftに聞いて見られてはいかがでしょうか？

さすが、石島さん！

よくそのリンクを見つけられましたね！

こんにちは　azure推進派のＰｕです。

ロードバランサーの問題でしたら
試しにロードバランサーの無いbasicでｖｍのインスタンスを立ち上げて
テストしてみたらどうですか
azureなら1分程でvmを作成する事が可能なんで
でわ〜でわ〜

azureのタイムアウト等で検索するといろいろでできますね・・・
タイムアウト等の設定はいろんなところにあると思います。
これを１つ１つ検証すると大変な事にもなりますし長くしたとするとそれによる弊害も発生すると思います。
逆行するかもしれませんがイベント等で一定時間ごとに通信するような仕組みをしないといけないのかな・・・

みなさん、ありがとうございます。
Azureは、弊社は３年間、基幹業務で利用しています。接続時間の問題、エラーキャッチなど留意点はMSから報告されています。
ただ、C#＋SOAPで実施する限り問題が発生していません。


弊社のプログラム作法の問題については疑っています。
ただMRBとSQLDatabaseとのセッション保持の方法で発生している可能性もあります（良いとか、悪いとかの問題ではなく）。


現実的に回避する方法を模索したく考えています。
・エラーが出たらリトライ（弊社が未熟でプログラミング方法が不明）などプログラム作法の問題
・接続時間設定パラメータを50ms程度長く設定（これは、Magicでできないとサポートから回答、今後のバージョンに期待）

・最初のひとりだけ落ちるので、正直にユーザに説明し、許しを請う


それよりも、Azureを使う注意点は、DB内の時間がUTCであることです。JST変換が必要です。ただMAGICユーザは、DB時刻を使っていない感じもします。

現在、プログラミング作法で逃げる方式を探しています。

ＭＡＧＩＣのプログラミングでできる問題ではないような気がします。
この部分はブラックボックスでバージョンアップ等でＭＡＧＩＣ側がタイムアウトで切断される前提で修正していただかないとだめだと思います。

違っているかもしれませんが・・・

皆さま、大変お世話になります。Onnetです。
以下の内容でご報告します。
超ありがとうございました。

【原因】
・エラーの発生は、MRBとSQLDatabase間で発生している（サポート調査）。
・MRB（推測：遅延書き込みなど非同期通信のため）とSQLDatabaseサービス仕様の問題（推測：弊社のC#単純プログラムでは問題を生じないため）
・サポートからは、「MSにエラーを聞いて欲しい」とのこと

【弊社の対応】
・弊社側は、現状の前提で回避策を以下の通りとします。
・エラーイベントで適切なメッセージを表示「不本意ですが、再度起動をお願いします」的な意味合いで
・サーバ側で、任意のインターバルでDB接続するプログラムを作成（プログラミング方法は今から調べますが）

【皆さま方におかれましては】
・AzureでVM+SQLDatabaseを利用する場合は、約30分でセッションが切れる
・ただ、だれか一人でも利用すると問題は起きない。30分だれも利用しない場合に発生。
・同じVM内、Azure内同一LAN上でのDBアクセスは問題を生じないと考えられる、のでこの方式を考慮する。
・AWSは問題ないとのことなので、そちらを利用する。

【その他】
・弊社は、多くのサーバをAzureで稼働させているため、クラウド移行が難しい
・なので、今後もAzureで運用します。
・問題が発生するかも知れないので、その際は報告させていただきます。
・マイクロソフトサポートには本件を問い合わせます。が、２社が絡んでいますので解決は難しいと考えています。

onnetさん、

AWSのRDSですが、検証経験はあるのですが、セッションがタイムアウト
するかどうかの検証はまだ行ったことがありません。ですので、今の
時点ではタイムアウトが起こらないとは言い切れませんので、ご了承
ください。

その他、進展がありましたようでとりあえず良かったですね。

onnetさん、

憶測で申し訳ないのですが、MRBの問題というより、Magicの
SQLゲートウェイ（バックグラウンドのミドルウェア）の関連
かなあという気もします。

MRBはIISのリクエスタとMagicアプリを結び付ける役割ですので、
DB接続とは直接は関係しないはずです。

はずしていたらごめんなさい。

ＳＱＬゲートウエイの問題だと思います。
ＭＡＧＩＣの場合一度セッションをはったらＤＢサーバーが再起動等でセッションが切れていてもセッションが張られている状態が前提で処理がされています。
だからエラーが発生します。

このあたりのＳＱＬゲートウエイの改善がない限り無理だと思います。
今後ＭＳＪ様が改善してくれる事を願います。・・・