NAKAMURA Minoru の日記 (2019年7月)

先月の日記(2019年06月) 今月の日記(2019年07月)
2002 | 10 | 11 | 12
2003 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2004 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2005 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2006 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2007 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2008 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2009 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2010 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2011 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2012 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2013 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2014 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2015 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2016 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2017 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2018 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2019 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11
ホームページ | 最新のコメント50
インデックス: 食べ歩き | Java | プログラム | UNIX | 画像
最新の日記へのリンク | この日記ページをはてなアンテナに追加 この日記ページをはてなブックマークに追加
はてな ダイアリー アンテナ ブックマーク ブログ
Twitter | mixi | Facebook | Google+
slideshare | github | Qiita



7/28 (日)

[Movie] ペット2

チネチッタで『ペット2』(原題: The Secret Life of Pets 2)を観る。


7/24 (水)

Kong でリトライを止める

API アグリゲーションの Kong は、クライアントからの API リクエストに対してデフォルトで 60 秒タイムアウトで 5 回までのリトライを行う。 Kong 自体の設定ではタイムアウト時間(connect_timeout、write_timeout、read_timeout)を伸ばすことがはできるが、リトライ自体を切ることはできない。 リトライ回数(retries)の設定は retries=0 の場合は無限リトライになる。

色々調べた限り Kong 自身にはリトライ切ることはできないが、nginx は proxy_next_upstream を off に設定することで、リトライをオフにすることができるようだ。 この場合、タイムアウト時間が来るとリトライなしでコネクションが切断される。

Kong は nginx_http_nginx_proxy_nginx_admin_ のようなプレフィックスを付けた Injecting Nginx directives の設定を書くことで Nginx 側の設定を変更することができる。 kong.conf に対して以下のように設定を行う。

nginx_proxy_proxy_next_upstream = off

Kong のコンテナを使う場合、kong.conf に書いた設定を大文字にした環境変数を記述することで指定できる。

export KONG_NGINX_PROXY_PROXY_NEXT_UPSTREAM=off

追記: 11/14

Kong はデフォルトではクライアントからの API 呼び出しをリクエストボディまで含めて保存している。 これを off にしないと、ファイルアップロードのようなリクエストではエラーが出ることがある。 この制御も Nginx 側のオプション proxy_request_buffering で行う。

同様に API サーバーからのレスポンスも Nginx はバッファリングしている。 これは off にしないとファイルダウンロードのような場合にエラーがでることがある。 この制御は proxy_buffering で行う。

Kong を立ち上げる際の環境変数で設定できる。

export KONG_NGINX_PROXY_PROXY_REQUEST_BUFFERING=off
export KONG_NGINX_PROXY_PROXY_BUFFERING=off

7/19 (金)

[Movie] 天気の子

109 シネマズ川崎で『天気の子』を観る。


7/18 (木)

[Java] JAXB と JSON-B のアノテーションの違い

JAXB と JSON-B で似たようなアノテーションに挙動の違いがあって、バグを踏む。

import javax.json.bind.annotation.JsonbTransient;
import javax.xml.bind.annotation.XmlTransient;

public class Foo {

    public String foo;
    public String bar;

    @JsonbTransient
    @XmlTransient
    public String getFoo() {
        return bar;
    }
}

JAXB にとって XmlTransient アノテーション の効果は以下の通り。

@XmlTransient注釈は、JavaBeanプロパティ名とフィールド名の間の名前の競合を解決したり、フィールドまたはプロパティのマッピングを禁止したりするときに便利です。小文字に変換されたJavaBeanプロパティ名とフィールド名が同じ場合、名前の競合が発生する可能性があります。JavaBeanプロパティがフィールドを参照している場合、@XmlTransient注釈を使用してフィールドまたはJavaBeanプロパティのマッピングを禁止することによって、名前の競合を解決できます。

上のプログラムで言えば、foo フィールドと getFoo メソッドを競合を回避し、マーシャリングした JSON 文字列には foo フィールドの結果だけが含まれるようになる。

一方、JsonbTransient アノテーションには同名競合のような記述はなくなっている。 実際の JsonbTransient アノテーションの効果は getFoo メソッドと foo フィールドの両方に適用され、JSON 文字列から "foo" のフィールドが消えてしまう。 南無三。


7/11 (木)

OpenAPI の記述能力で不満なところ

REST API の定義を OpenAPI Specification で記述しているが、いろいろストレスが溜る。

$ref で定義した部分に description を書きたい

モデルを定義を $ref 使って入れ子にした場合などに、参照元に description を付けたい場合がある。 つまり下のように書きたい。

ItemList:
  type: object
  properties:
    item:
      descritpion: ここに item の説明を記述することもできない
      $ref: '#/components/schemas/Item'

これは OpenAPI の仕様的にダメらしい。 OpenAPI のこの仕様は JSON Schema から来ており、余分なプロパティが書けないようだ。

ここに強制的に allOf を入れる、description を書けるようになる。 非常にかっこ悪いが…

ItemList:
  type: object
  properties:
    item:
      descritpion: ここに item の説明を記述することはできる
      allOf:
        - $ref: '#/components/schemas/Item'

OpenAPI で同一ステータスコードで複数の理由が書き辛い

REST API の定義を OpenAPI Specification で記述しているが、同一のステータスコードに異なるエラー定義を記述したいということがある。 つまり下のように書きたい。

'204':
  description: a dog is not found
  content: 
    application/json:
      schema:
        $ref: '#/components/schemas/DogError'
'204':
  description: a kennel is not found
  content: 
    application/json:
      schema:
        $ref: '#/components/schemas/KennelError'

これが仕様的に許されるかどうかは微妙だが、Swagger が提供するツール類は対応していないようだ。

替りにこちらも oneOf を使うのがセオリーらしいが、その場合は複数の description がひどく書き辛い(Swagger; specify two responses with same code based on optional parameter)。


7/10 (水)

Cloudera が自社ソフトの OSS 化を宣言

2018年10月に Cloudera と Hortonworks が合併した。 Hortonworks は全製品を OSS として公開する企業だったが、Cloudera は OSS ソフトに貢献するもの自社の中核ソフトはソース公開していなかった。 しかし Cloudera 側のソフトを今後6ヵ月のうちに AGPL ライセンスで公開すると宣言した。 Cloudera Manager、Cloudera Navigator、Cloudera Data Science Workbench などの公開されることになる。


先月の日記(2019年06月) 今月の日記(2019年07月)
2002 | 10 | 11 | 12
2003 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2004 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2005 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2006 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2007 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2008 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2009 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2010 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2011 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2012 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2013 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2014 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2015 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2016 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2017 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2018 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2019 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11
ホームページ | 最新のコメント50
インデックス: 食べ歩き | Java | プログラム | UNIX | 画像
最新の日記へのリンク | この日記ページをはてなアンテナに追加 この日記ページをはてなブックマークに追加
はてな ダイアリー アンテナ ブックマーク ブログ
Twitter | mixi | Facebook | Google+
slideshare | github | Qiita


Written by NAKAMURA Minoru, Email: nminoru atmark nminoru dot jp, Twitter:@nminoru_jp