Это проблема для нас, используя vlin go -http с поддержкой vlin go -wire , который напрямую использовал Java NIO. Мы думали, что сталкиваемся с печально известной ошибкой Netty Java NIO epoll , которая была исправлена Netty, поэтому мы применили исправление Netty к vlingo-wire. Это не сработало. Мы, наконец, отказались от попыток решить эту проблему с прямым NIO и даже с учетом исправления Netty. Таким образом, мы переключились на Netty вместо NIO, который работает везде, но не на Heroku.
Используя Netty и некоторые подробные журналы, мы увидели, что на каждый запрос определенно отвечает сервер. Но по какой-то причине ответ не проходит мимо маршрутизатора Heroku. Например:
2020-04-06T20:50:13.896574+00:00 app[web.1]: 20:50:13.896 [nioEventLoopGroup-3-4] DEBUG i.v.w.f.b.n.s.NettyInboundHandler - Request received
2020-04-06T20:50:13.896929+00:00 app[web.1]: 20:50:13.896 [nioEventLoopGroup-3-4] DEBUG i.n.handler.logging.LoggingHandler - [id: 0x1efddaa2, L:/172.18.27.14:59829 - R:/10.11.43.12:20716] READ COMPLETE
2020-04-06T20:50:13.897026+00:00 app[web.1]: Retrieving operations and...
2020-04-06T20:50:13.898394+00:00 app[web.1]: 20:50:13.898 [nioEventLoopGroup-3-4] DEBUG i.n.handler.logging.LoggingHandler - [id: 0x1efddaa2, L:/172.18.27.14:59829 - R:/10.11.43.12:20716] WRITE: 148B
2020-04-06T20:50:13.898395+00:00 app[web.1]: +-------------------------------------------------+
2020-04-06T20:50:13.898396+00:00 app[web.1]: | 0 1 2 3 4 5 6 7 8 9 a b c d e f |
2020-04-06T20:50:13.898397+00:00 app[web.1]: +--------+-------------------------------------------------+----------------+
2020-04-06T20:50:13.898397+00:00 app[web.1]: |00000000| 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b 0a |HTTP/1.1 200 OK.|
2020-04-06T20:50:13.898397+00:00 app[web.1]: |00000010| 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 61 70 |Content-Type: ap|
2020-04-06T20:50:13.898399+00:00 app[web.1]: |00000020| 70 6c 69 63 61 74 69 6f 6e 2f 76 6e 64 2e 63 61 |plication/vnd.ca|
2020-04-06T20:50:13.898400+00:00 app[web.1]: |00000030| 6c 63 75 6c 61 74 69 6f 6e 2b 6a 73 6f 6e 3b 76 |lculation+json;v|
2020-04-06T20:50:13.898400+00:00 app[web.1]: |00000040| 65 72 73 69 6f 6e 3d 31 2e 31 0a 43 6f 6e 74 65 |ersion=1.1.Conte|
2020-04-06T20:50:13.898400+00:00 app[web.1]: |00000050| 6e 74 2d 4c 65 6e 67 74 68 3a 20 35 33 0a 0a 5b |nt-Length: 53..[|
2020-04-06T20:50:13.898401+00:00 app[web.1]: |00000060| 0a 20 20 22 41 44 44 49 54 49 4f 4e 22 2c 0a 20 |. "ADDITION",. |
2020-04-06T20:50:13.898401+00:00 app[web.1]: |00000070| 20 22 53 55 42 54 52 41 43 54 49 4f 4e 22 2c 0a | "SUBTRACTION",.|
2020-04-06T20:50:13.898401+00:00 app[web.1]: |00000080| 20 20 22 4d 55 4c 54 49 50 4c 49 43 41 54 49 4f | "MULTIPLICATIO|
2020-04-06T20:50:13.898402+00:00 app[web.1]: |00000090| 4e 22 0a 5d |N".] |
2020-04-06T20:50:13.898402+00:00 app[web.1]: +--------+-------------------------------------------------+----------------+
2020-04-06T20:50:13.898467+00:00 app[web.1]: 20:50:13.898 [nioEventLoopGroup-3-4] DEBUG i.n.handler.logging.LoggingHandler - [id: 0x1efddaa2, L:/172.18.27.14:59829 - R:/10.11.43.12:20716] FLUSH
2020-04-06T20:50:13.898847+00:00 app[web.1]: 20:50:13.898 [nioEventLoopGroup-3-4] TRACE i.v.w.f.b.n.s.NettyInboundHandler - Reply sent
Был сделан вывод, что, возможно, мы неправильно закрывали клиентский сокет (хотя при использовании curl возникают те же проблемы). В любом случае мы пытались закрыть сокет сервера, чтобы закрыть сокет сразу после ответа на HTTP-запрос. Предполагалось, что, возможно, при закрытии будут буферы сокетов гриппа sh (небольшие ответы). Это также не сработало для нас.
Все вышеперечисленное с самого начала работало на прямом AWS использовании и продолжает там работать.
В настоящее время мы рассматриваем некоторые идеи, которые мы о тайм-аутах и настройке DNS, но пока что это не происходит.
На данный момент мы застряли и не знаем, что делать или пытаться делать дальше. Мы обязательно хотели бы поддержать Heroku. Если у вас есть какие-либо подсказки, мы будем очень благодарны.