コンテンツへスキップ

‘the server did not provide a meaningful reply; this might be caused by a contract mismatch, a premature session shutdown or an internal server error.

突然、

‘the server did not provide a meaningful reply; this might be caused by a contract mismatch, a premature session shutdown or an internal server error.

わけわかりません。

Windows Azure Service Bus でNetTcpリレーバインディングやってます。

エラーメッセージで検索したら、結構HITしました。

サービス側のコンフィグで

      <serviceBehaviors>
<behavior name=””>
<serviceDebug includeExceptionDetailInFaults=”true” />
          <dataContractSerializer maxItemsInObjectGraph=”1000000″ />
</behavior>
</serviceBehaviors>

これで解決しました。

原因とか全くわかりませんが。。。

WCFでWebInvoke属性にPUTメソッドを設定したら、IISが受け付けてくれない

HTTP/1.1 404 Not Found がレスポンスされてしまいます。

PUTメソッドも実装しているのですが、こちらは全く問題なしなんですよね。

IISマネージャーのハンドラーマッピングでExtensionlessUrl-Integrated-4.0 を確認したら下記の通りでした。

確かに、VerbsにPUTは含まれていないです。

PUTを追加すりゃいいって話なんですが、デプロイ先がAzureのWebロールなのでIISマネージャで変更するわけにもいかないですし。

最悪、AzureのスタートアップでIISを操作しなきゃならないのかなとガックリきたのですが、よくよく考えたら、IISの設定はWeb.configでできるんですよね!

  <system.webServer>
<handlers>
<!–PUTメソッドを有効に–>
<remove name=”ExtensionlessUrl-Integrated-4.0″/>
<add name=”ExtensionlessUrl-Integrated-4.0″ verb=”GET,HEAD,POST,PUT,DEBUG” path=”*” type=”System.Web.Handlers.TransferRequestHandler”/>
</handlers>
</system.webServer>

こんな風に、verb以外は全く同じになるように書いたらPUTも受け付けるようになってくれました。

iPad2のiOSを4.3.5にアップグレードしたらxcodeでデバッグ実行できなくなった。unable to load symbol file:

unable to load symbol file: unable to load symbol file: unable to load symbol file: unable to load symbol file: unable to load symbol file:

ってデバッガコンソールに出しまくってフリーズしました。

ぶっ壊れたか?と不安になりましたが、検索してると、/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.3.5 (8L1) を削除してxcodeを再起動してみなよ、という策を見かけたので試してみました。

xcodeを再起動してiPadを繋いだらオーガナイザがコレクトし直して動くようになりました。よかったよかった。

狂ったように同じ語句 unable to load symbol file: を繰り返していたので、気持ち悪かったです。

MembershipのIsApproved

Membership.ValidateUserメソッドで、ユーザー名・パスワードが完璧に一致しているのにどうしても結果がTrueにならなくて悩んでいました。でも、Trueになるユーザーもいます。Trueになるユーザの違いはなんだろうなーと思いを巡らせてていたら、ユーザー登録の方法が違うことに気が付きました。Trueになる方はWEBページのCreateUserWizardで、Trueにならない方はMembership.CreateUserメソッドで作った奴。

ふと気が付きました。Membership.CreateUserメソッドのオーバーロードにisApproved、、、認可?こ、これはと思ってMembershipデータを見てみると片やtrue、片やfalse。trueにしてあげたら認証通りました。

cscfgのSettingに設定した日本語が文字化けする。Base64で回避。

cscfgのSettingに設定した日本語をプログラムで読み込んでレスポンスに設定している箇所があるのですが、文字化けします。

なぜかはわかりませんが、Azure開発では度々文字化けの問題に遭遇します。

そんな時の常套手段がBase64エンコードです。

cscfgにはエンコード済みの値を設定しておいて、プログラム内では例えば下記のようなメソッドを使用してデコードします。

なお、ネット上にはBase64エンコード・デコードサイトがありますから、それを利用するとエンコード値を得るのに便利です。

    public class Base64Converter
{

public static string Encode(string encStr, string str)
{
return Convert.ToBase64String(Encoding.GetEncoding(encStr).GetBytes(str));
}

public static string Decode(string encStr, string str)
{
return Encoding.GetEncoding(encStr).GetString(Convert.FromBase64String(str));
}
}

Service Busで公開するWCFサービスは、IISではなくWindowsサービス、Webロールではなくワーカーロールでホストすべきのようだ

WEBロールでService Bus経由で公開するWCFサービスをホストしてるんですが、どうもアプリケーションプールがリサイクルされているっぽく、しばらく放置するとクライアント側でチャネルがオープンできなくなる現象に遭遇しました。WCFサービスは、Application_StartでSeviceHostをオープンしています。

さて、リサイクルされてもすぐに起動させるべく調べていたところ、下記のフォーラムスレッドにたどり着きました。

How do I Host an app fabric service under IIS?

http://social.msdn.microsoft.com/Forums/en-US/netservices/thread/8b6a16ba-c8e0-4323-8cb9-1eec31a4632d

ふむふむ、「Windowsサービスでホストしましょう」、

「アプリケーションのリサイクルに注意しましょう」、そうそう、そこなのよ。コネクションが切断されっぱなしになっちゃうんですよね。

Appwarmup module というIIS7.5向けの拡張があって、それを使うと回避できるようなことがボチボチと見受けられたのですが、どうもダウンロードできなくなっているんですよね。

定期的にワーカーロールからWEBロールの適当なページにアクセスさせて、アプリケーションプールを起こしっぱなしにするように細工しようかな・・・。

あるいは、ワーカーロールでWCFサービスをホストするか・・・。

現時点から最も修正が少なくて済むのは前者、スマートなのは後者、ううーん悩みます。

Host WCF in an Azure worker role (CSAzureWCFWorkerRole)

http://code.msdn.microsoft.com/CSAzureWCFWorkerRole-38b4e51d

Service Busのクライアントで、ChannelFactoryのオープンでタイムアウト

Windows Azure の Application_Start で Response is not available in this context. では、Application_Start以外の場所でやればOKと書きましたが、サービスをAzureに配置する場合、Application_Start以外の場所でホストをオープンすると、クライアントにおいてChannelFactoryのオープンでタイムアウトするという事象に見舞われました。この因果関係を見つけるのに2日掛かりました。。。orz

どうにかしてResponse is not available in this context. をクリアせにゃならん!

そりゃもう必死に探しました。だって、ただでさえスケジュール押しているものですから。

そして、こんなん見つけました。

Azure and Response is not available in this context

どうやらこの方は、Application_StartでブロブにアクセスしようとしてResponse is not available in this context. に遭遇したそうです。ブロブアクセスではURLエンコードを使うでしょうから、根本は同じ原因と判断し、提示されているソリューションをまねしたところ! 見事に解消しました!

ちきしょー、オレの二日間返してくれ~

PS. このソリューション、いったい何をしているのか分かりません。分かる方、誰か教えてください。