jingb
jingb
代理问题
shadowsock代理正常 可以打开墙外网站 shadowsock监听着1087端口 代理设置了127.0.0.1:1087 还是下载失败 2019-04-27 21:04:03.449 |-INFO [DOWNLOAD-pool-0] club.bluetroy.crawler.util.HttpClient [36] -| getNow http://91porn.com/view_video.php?viewkey=f9f505bea42ef942b6a9&page=1&viewtype=basic&category=hot 2019-04-27 21:04:04.467 |-INFO [DOWNLOAD-pool-0] club.bluetroy.crawler.DefaultDownloader [50] -| 下载失败 java.lang.NullPointerException: null at club.bluetroy.crawler.tool.Selector.getDownloadUrl(Selector.java:63) ~[default-crawler-0.0.1-SNAPSHOT.jar!/:0.0.1-SNAPSHOT] at club.bluetroy.crawler.tool.ScannerTool.scanDownloadUrl(ScannerTool.java:64) ~[default-crawler-0.0.1-SNAPSHOT.jar!/:0.0.1-SNAPSHOT]...
target type( func(*serverless.realServerlessControl, context.Context, string) error) and double type( func(*serverless.ServerlessControlInterface, context.Context, string) error) are different 其中 realServerlessControl实现了ServerlessControlInterface 这个interface，这种如何处理，望回复 感谢 type realServerlessControl struct { } type ServerlessControlInterface interface { CreateFunction(ctx context.Context,...
jim-framework-rpc和jim-framework-rpc-api已经构建成功，本地仓库也已经有了jar包 但构建jim-framework-rpc-consumer和jim-framework-rpc-provider的时候就是引不到上面两个模块的类，是打开姿势有什么不正确嘛....求解答
请教楼主，如题。 或者说这个项目的基础上，要支持websocket的代理，改造主要是哪里。（已测试支持不了ws）
如题，启动docker的时候带了代理的参数 > docker run ……………… > -e HTTP_PROXY=192.168.0.148:7890 \ > -e HTTPS_PROXY=192.168.0.148:7890 \ > --restart=always \ > novicezk/midjourney-proxy:1.4 容器里访问discord的主页，是可以通的 > docker exec 89d67b21764693e curl https://discord.com > % Total % Received...
there has a program and it consumes massive message from kafka. then it will trans the message to metrics format and use the vm metrics sdk to push to victoriametrics....
在layotto的一个视频里面看到有提过mosn会支持istio1.1X新版本，这块当前进度如何呀，没有找到相关的issue 看istio 社区这个 https://github.com/istio/istio/issues/23753 issue已经没有更新了
楼主好 一直思考着怎么搭建一套稳定的开发环境，一个是方便一个也是环境一致各种奇怪问题会少。 所以长时间以来也零碎了解过一些这方面的东西包括vagrant、docker。 个人了解的比较浅，不知道您有没有尝试过用docker搭建开发环境以及和vagrant的比对
楼主好，你在两篇长连接网关里的描述有一段ws-api找ws-gateway的描述 用户连接 当ws-gateway向ws-api发布连接事件（带上gatewayIP、socketId以及uid），ws-api系统会保存以下几种关联。 关系一：socketId: gateway关联。将socketId与gatewayIP信息保存在redis中，数据结构为String，通过心跳维持key的TTL，一个连接会占用一个redis key。 关系二：uid: socketId关联。存储在redis，一个用户可能会维持多个websocket连接，比如pc的多窗口。数据结构为Set，存储socketId集合。一个用户会占用一个redis key。 根据业务可以衍生出更多的关系，比如群ID、直播间ID等。 但又有下面这个图  第七步写的是广播，我理解根据上面的描述 ws-api已经可以找到要推送的连接在哪一台 ws-gateway上面，直接grpc通知它去推送消息就可以了。 我理解的广播是 比方ws-api给所有的ws-gateway说我要给某个socketId连接推消息，然后所有的ws-gateway自己检查下这个socketId归不归自己管理再去处理 这块感觉有点前后没对上
太特么难了……我找个go的哪怕一点go都不会也能搞起来 么得netty搞个4层代理太难了艹