| デバッグのしようが無い |
|
|
25日に起こった障害が27日にも起こりました。どうも出来高が異常に推移している状態のときにマケスピのチャートを開くと一瞬固まることがあって、そのときに停止してしまうようです。どうやらこのアプリケーションを動かしている間はマケスピに触らないほうがいいみたいです。
ただ、この場合の原因はマーケットスピードでもRSSでもなく、私の作ったアプリケーションにあるようです。先物の板が動いていないときにExcelのDDEを使ってRSSにリクエストしてみると、ちゃんと値を取得できました。
私の作っているアプリケーションのDDEへのアクセスにはNDDEというDLLを利用させてもらっているのですが、これのせいなのかも知れません。
対処方法を一応考えてみたのですが、処理がかなり重くなると思われるのでこの点に関してはあきらめます。何度も頻繁に起こるような現象でもないので、デバッグのしようが無いのが現状です。最近頻繁に起こっているとはいえ、現在時系列データのログを保存するのに使っているリリースビルドは結構前のバージョンなので、つい最近の変更でこの障害が生じるようになったわけではないので。
消極的に、この障害が起こってしまった銘柄は売買しないことにしようと思います。
(´･ω･`)ｼｮﾎﾞｰﾝ
| |
|
7月28日（金） | コメント(0) | 日記 | 管理
|
| ●／ ＜ ナンデ ショリ オソインダヨ |
|
|
以前書いた、プロセス内で新規にHTTPWebRequestオブジェクトを構築した場合に限ってWebへのアクセスが異様に遅いという点については、結局解決策は見つかりませんでした（きちんと調べていないけど、環境依存っぽいので取っ掛かりが見つからない）。変数スコープに関係なく、同一プロセス内で別のHTTPWebRequestを新たに作ってWebにアクセスすると、それ以降は速くなります。サイトのURLとかサーバーとかは関係ないようです。HTTPWebRequestの中にグローバルなオブジェクトがあってそれが悪さをしているのか、あるいはネットワークリソースをプロセスに与える際に時間がかかっているのか、よくわかりません。
仕方が無いので、起動時にメインとは別のスレッドを作って、ダミーのURLを読み込ませるという処理を追加しました。起動時にはマケスピのRSSにDDEリクエストをするのに時間がかかるので、何か他のことをやらせるのにはちょうどいいのかも知れません。でもテスト中にはマケスピのRSSを利用しないことも多いので、結局今の段階ではあまりいい解決策にはなっていません。
●／ ＜ ナンデ ショリ オソインダヨ バカ！！
＜■
／ ＞
| |
|
7月26日（水） | コメント(0) | 日記 | 管理
|
| 排他制御 |
|
|
自動売買の注文処理は、売買シグナル発生時にスレッドを作成して、そのスレッド中で発注をしようと考えています。そこで、同時に発注をするときにオブジェクトの同期がうまくかみ合うかどうかを調べるため、試しに５つのスレッドを作って、５つ同時に発注をしてみました。するとページ遷移のエラーが返されてきました。
そこで、synclockでWEBにアクセスするクラスを排他制御してみると、エラーは発生しなくなりました。でもこれではHTTPWebRequestやHTTPWebResponseを使う意義がさらに薄れてしまいます＿|￣|○（昨日触れたように、WebBrowserよりもむしろ遅いので）。まあ、もともと株価のログをとったり売買アルゴリズムを計算させているスレッドと発注のスレッドは別スレッドなので、あまり影響は無いといえば無いのですが。
ページ遷移のエラーの問題はクッキーの問題だろうと考えて、HTTPWebResponseで得られたクッキーをHTTPWebRequestのCreate時に渡して、クッキーをインスタンス化してみようと考えたのですが、色々やってみてもちょっとうまく行きませんでした（というかCookieContainerオブジェクトを複製する方法がみつからなかった）。もしクッキーを複製できれば、ログイン時に得られたクッキーと同じものを持つ複数のHTTPWebRequestオブジェクトを構築して、スレッド１つごとにそれらのオブジェクトを割り当てて同時に発注できそう……とか考えたのですが、ダメっぽいです。となると、同時に発注するには複数回ログインしなければならないのか？ということになりますが、あほらしいのでやめておきます。
マケスピはこのごろあまり停止しないのですが、今日はマケスピもRSSも停止していないのに、ごく一部の銘柄（日経先物と株価指数）の取得が9時26分に停止してしまいました。このように何故か先物だけが止まるケースがたまにあるのでちょっと困っています。マケスピ全体が止まるのならば、netstat等に相当する処理を適用すればマケスピ停止を発見できそうなのですが、ごく一部の銘柄のみとなると、本当に止まっているのか、それとも実際に売買されていないだけなのかという区別がつきません。DDEのイベントによる取得処理のほかに、RSSに直接アクセスして値をとってくるような処理も必要なのかもしれません。
チャーハン！！チャーハン！！
ﾟ･ ｡ ･｡ ﾟ･ ｡ ･｡ ﾟ･ ｡ ･｡ ﾟ･ ｡ ･｡
ﾟ･ ｡ ｡･ﾟ･⌒ヽ ｡･ﾟ｡･ ﾟ･ ｡ ｡･ﾟ･⌒）
...................... －＝≡ (( ヽニニフ━o _ _ ｏ━ヽニニフ )) ･｡
...................... －＝≡((ヽニ（⌒｡･ﾟ｡･ ミ ( ﾟ∀ﾟ)彡｡･ﾟ｡･⌒） ニフ ))
....................... －＝≡ ((ヽニニフ━o ｏ━ヽニニフ )) ﾟ･
............................ －＝≡((.ヽニ（⌒･ﾟ･。彡 （ ⌒) ミ ｡･ﾟ･⌒）フ ))
ﾟ･ ｡ ･｡ ﾟ･ ｡ －＝≡((ヽニニフ━o c し' ｏ━ヽニニフ ))
| |
|
7月25日（火） | コメント(0) | 日記 | 管理
|
| 発注のテストをやってみた |
|
|
ウダウダとルーチンワークを繰り返していたら一応プログラムから証券会社への発注をすることができるようになりました。とはいっても今の段階ではまだ、テスト用に用意した一種類の銘柄に対して決まった数量で決まった値段で買い注文を出せるようになったという程度の段階で、洒落た機能どころか銘柄を選ぶことすらできない状態ですが。
証券会社のサイトにアクセスするのにHTTPWebRequestとHTTPWebResponseを使っていますが、発注の全体的な処理としてはブラウザで1回アクセスするのと同程度の時間がかかります。遅いですが、これには原因があります。
ブラウザでPC用サイトでの発注をすると、銘柄検索や発注内容の確認が無い分、アクセス１回で発注できます。それに対して、HTTPWebRequestを使う方法だと、複雑なJavaScriptが存在するPC用サイトで発注処理をするのは難しいので、携帯サイトを使って発注するということになります。携帯サイトの方を使うと、銘柄検索も発注内容確認もあって、３回くらいアクセスしなければなりません。さらに、ページの読み込みごとに変化する項目があって、これを拾う処理をすると（多分不要な処理だと思いますが一応やっておく）、合計で４回アクセスしなければならなくなります。上記で「同程度の時間がかかる」と記述したのは、この４回分のアクセスを含めてのことです。
全体の時間は同じでも、証券会社のサーバーに注文が届くまでの時間で考えれば、ブラウザの方がかえって有利な結果になってしまいます＿|￣|○。まあAPI化されればHTTPWebRequestを使う方法にもそれなりに有利な点が出てくるとは思うので、これはこのままにしておきます。でも色々遠回りをしてしまったかも。
今日は、現物株を保有していたり、信用建玉がある場合にどういう約定履歴になるのかを確認する意味で、はじめてGMOインターネット証券で株を買ってみました。物凄い少額で。
本当は信用全力使い切ったあとでどうなるのかとか、色々調べてみたい部分もあるのですが、リスクが高すぎるので、そういう実験はあえてやらないことにします。
. ☆ |＼＿／￣￣＼_／| + *
＼＿| ▼ ▼|_／ ψ ♪
＼ 皿 ／´ / ゜ ☆
､_ <´ヽWﾉﾌつ
. ミ≡=_､＿(,ﾉ(,, _,-､ゝ＿＿_＿ -､
. 彡≡=-'´￣￣｀~し'ヽ)￣ ￣￣ﾞ"′
´
☆
. ☆
| |
|
7月24日（月） | コメント(0) | 日記 | 管理
|
| うがああああ～またくだらないバグだあああ～ |
|
|
うげぇええぇぇぇぇえまたくだらないミスで時間を費やしちゃった……。２日連続。
なんというか、バグの箇所を類推する能力が著しく落ちてきている……というよりは、その点の能力が元から著しく酷いということを今更認識し始めたというか。
ログイン直後のトップページから各ページへのURLを抜き出す処理を書いていたら、ローカルではうまく行くのに実際に本物のWEBサイトで試してみるとうまく行かない。何でだろうと思って2時間ぐらい悩んでデバッグしまくり。ローカルではページ全体を検索対象に入れていたのに対して、本物のWEBサイトの方ではその一部分のみを切り出して調べていたのですが、どうも全く関係のない部分を切り出していた模様。普通だったら簡単に気付くミスなのですが、HTMLソースの文字列を全部タグに分解してから処理しているので、どの辺りを切り出しているのかがわかりにくいという状況になっていました。てっきりまた証券会社のサイトがバージョンアップしたのかよ～と思ってた。
あと、指定した属性を持つタグを検索してその部分を切り出すという処理をしていたのですが、そのタグの検索ロジックにもバグが潜んでいて、これまではうまく行っていたのに特定のページではうまく行かないという状況になっていました。
これらのバグを直しても、今度は何故かトリミングがうまく行ってない、と思って悩んでいたら、今度はせっかくトリミングした文字列を新しく代入するのを忘れていたというこれまたくだらないミス。hoge=hoge.Trim()と書くべきところをhoge.Trim()としか書いていなかった。うがああああ～
まあ、潜んでいたバグを早期に潰すことが出来たと考えればいいか……
ところで、HTTPWebRequest、HTTPWebResponseを実行すると、何故か私の環境では１回目のアクセスにかなり時間がかかります。2回目以降はまあまあなのですが、１回目は10秒くらいかかってしまいます。
どうも.NET Framework 1.1では大丈夫らしいのですが（試してない）、.NET Framework 2.0だと環境によっては滅茶苦茶遅くなるみたいです。何か解決策ないのかな？
,.-─-、
/ /_wゝ-∠l
ヾ___ノ,. - >
/|／（ヽY__ノﾐ
.{ rｲ ノ
パトラッシュ、疲れたろう。僕も疲れたんだ……
| |
|
7月23日（日） | コメント(0) | 日記 | 管理
|
フォトログ表示
