stalefruits / gniazdo Goto Github PK

View Code? Open in Web Editor NEW

208.0 208.0 38.0 68 KB

A WebSocket client for Clojure

License: Apache License 2.0

Clojure 100.00%

gniazdo's People

Contributors

Stargazers

Watchers

gniazdo's Issues

Configurable max message size?

I'm getting a Jetty exception:

2017-07-30 11:31:05.514:WARN:oejwc.Parser:WebSocketClient@1487230025-10: 
org.eclipse.jetty.websocket.api.MessageTooLargeException: Text message size [67527] exceeds maximum size [65536]
	at org.eclipse.jetty.websocket.api.WebSocketPolicy.assertValidTextMessageSize(WebSocketPolicy.java:140)
	at org.eclipse.jetty.websocket.common.Parser.assertSanePayloadLength(Parser.java:127)
	at org.eclipse.jetty.websocket.common.Parser.parseFrame(Parser.java:480)
	at org.eclipse.jetty.websocket.common.Parser.parse(Parser.java:252)
	at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.readParse(AbstractWebSocketConnection.java:675)
	at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onFillable(AbstractWebSocketConnection.java:505)
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
	at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:186)
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
	at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
	at java.lang.Thread.run(Thread.java:748)

Wondering if there's a way I can currently configure this max message size using gniazdo?

Websocket Ping and Pong messages

How do I tell Gniazdo tot tell Jetty to keep the websocket connection alive with ping & pong messages every N seconds?

My websocket client connections to a server expecting pings are being forceably closed (code: 1006) because I'm not keeping the connection alive with ping/pong messages.

Strange JVM crash with WebSocket Client

I've been trying for a couple days to track down why the entire JVM is crashing when I use this library sometimes (but not all times). I get error logs that start like this:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (sharedRuntime.cpp:834), pid=4715, tid=4103
#  fatal error: exception happened outside interpreter, nmethods and vtable stubs at pc 0x000000011e6b736f
#
# JRE version: Java(TM) SE Runtime Environment (8.0_45-b14) (build 1.8.0_45-b14)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.45-b02 mixed mode bsd-amd64 compressed oops)
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0x00007f887cce4800):  JavaThread "WebSocketClient@931427653-45" [_thread_in_Java, id=4103, stack(0x000070000fcd4000,0x000070000fdd4000)]

Stack: [0x000070000fcd4000,0x000070000fdd4000],  sp=0x000070000fdd2130,  free space=1016k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x58e7ba]  VMError::report_and_die()+0x3f8
V  [libjvm.dylib+0x1e037f]  report_vm_error(char const*, int, char const*, char const*)+0x54
V  [libjvm.dylib+0x4c923f]  SharedRuntime::continuation_for_implicit_exception(JavaThread*, unsigned char*, SharedRuntime::ImplicitExceptionKind)+0x195
V  [libjvm.dylib+0x46fd57]  JVM_handle_bsd_signal+0x368
V  [libjvm.dylib+0x46c137]  signalHandler(int, __siginfo*, void*)+0x2f
C  [libsystem_platform.dylib+0x2b3a]  _sigtramp+0x1a
C  0x0000000136c7fd80
J 6250 C2 com.sun.crypto.provider.GaloisCounterMode.decryptFinal([BII[BI)I (256 bytes) @ 0x000000011f4c968f [0x000000011f4c8c00+0xa8f]


---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
  0x00007f887db85800 JavaThread "clojure-agent-send-pool-3" daemon [_thread_blocked, id=4363, stack(0x000070000cbb8000,0x000070000ccb8000)]
  0x00007f887def1000 JavaThread "clojure-agent-send-pool-2" daemon [_thread_blocked, id=71951, stack(0x00007000104ec000,0x00007000105ec000)]
  0x00007f8879154800 JavaThread "async-dispatch-8" daemon [_thread_blocked, id=72451, stack(0x00007000105ef000,0x00007000106ef000)]
  0x00007f887ea00800 JavaThread "async-dispatch-7" daemon [_thread_blocked, id=71427, stack(0x00007000103e9000,0x00007000104e9000)]
  0x00007f887ed69800 JavaThread "async-dispatch-6" daemon [_thread_blocked, id=70915, stack(0x00007000102e6000,0x00007000103e6000)]
 0x00007f887c93f800 JavaThread "clojure-agent-send-pool-1" daemon [_thread_blocked, id=70403, stack(0x00007000101e3000,0x00007000102e3000)]
  0x00007f887d82b000 JavaThread "WebSocketClient@931427653-scheduler" [_thread_blocked, id=69891, stack(0x00007000100e0000,0x00007000101e0000)]
  0x00007f8879384000 JavaThread "WebSocketClient@931427653-48" [_thread_in_native, id=69379, stack(0x000070000ffdd000,0x00007000100dd000)]
  0x00007f8879383000 JavaThread "WebSocketClient@931427653-47" [_thread_blocked, id=41223, stack(0x000070000feda000,0x000070000ffda000)]
  0x00007f887e94a800 JavaThread "WebSocketClient@931427653-46" [_thread_blocked, id=40975, stack(0x000070000fdd7000,0x000070000fed7000)]
=>0x00007f887cce4800 JavaThread "WebSocketClient@931427653-45" [_thread_in_Java, id=4103, stack(0x000070000fcd4000,0x000070000fdd4000)]
  0x00007f887cce4000 JavaThread "WebSocketClient@931427653-44" [_thread_in_native, id=47627, stack(0x000070000fbd1000,0x000070000fcd1000)]
  0x00007f887f10e000 JavaThread "WebSocketClient@931427653-43" [_thread_in_native, id=62483, stack(0x000070000face000,0x000070000fbce000)]
  0x00007f887e969800 JavaThread "WebSocketClient@931427653-42" [_thread_in_native, id=60963, stack(0x000070000f9cb000,0x000070000facb000)]
  0x00007f88794ac000 JavaThread "WebSocketClient@931427653-41" [_thread_blocked, id=62727, stack(0x000070000e280000,0x000070000e380000)]
  0x00007f887ed13800 JavaThread "async-dispatch-5" daemon [_thread_in_Java, id=68615, stack(0x000070000f8c8000,0x000070000f9c8000)]
  0x00007f887e8c9800 JavaThread "clojure-agent-send-pool-0" daemon [_thread_blocked, id=68099, stack(0x000070000f7c5000,0x000070000f8c5000)]
  0x00007f887b078000 JavaThread "XNIO-1 Accept" daemon [_thread_in_native, id=67587, stack(0x000070000f6c2000,0x000070000f7c2000)]
  0x00007f887b077000 JavaThread "XNIO-1 I/O-8" daemon [_thread_in_native, id=67075, stack(0x000070000f5bf000,0x000070000f6bf000)]
  0x00007f887deeb000 JavaThread "XNIO-1 I/O-7" daemon [_thread_in_native, id=66563, stack(0x000070000f4bc000,0x000070000f5bc000)]
  0x00007f887e86b000 JavaThread "XNIO-1 I/O-6" daemon [_thread_in_native, id=66051, stack(0x000070000f3b9000,0x000070000f4b9000)]
  0x00007f887971d000 JavaThread "XNIO-1 I/O-5" daemon [_thread_in_native, id=65539, stack(0x000070000f2b6000,0x000070000f3b6000)]
  0x00007f887e8af800 JavaThread "XNIO-1 I/O-4" daemon [_thread_in_native, id=65027, stack(0x000070000f1b3000,0x000070000f2b3000)]
  0x00007f887e818800 JavaThread "XNIO-1 I/O-3" daemon [_thread_in_native, id=64515, stack(0x000070000f0b0000,0x000070000f1b0000)]
  0x00007f887924b800 JavaThread "XNIO-1 I/O-2" daemon [_thread_in_native, id=64003, stack(0x000070000efad000,0x000070000f0ad000)]
  0x00007f887ecbd000 JavaThread "XNIO-1 I/O-1" daemon [_thread_in_native, id=63491, stack(0x000070000eeaa000,0x000070000efaa000)]
  0x00007f8878c11800 JavaThread "async-dispatch-4" daemon [_thread_blocked, id=5639, stack(0x000070000eda7000,0x000070000eea7000)]
  0x00007f88787ba800 JavaThread "async-dispatch-3" daemon [_thread_blocked, id=45083, stack(0x000070000eca4000,0x000070000eda4000)]
  0x00007f887e080000 JavaThread "async-dispatch-2" daemon [_thread_blocked, id=28939, stack(0x000070000eba1000,0x000070000eca1000)]
  0x00007f887e32f800 JavaThread "async-dispatch-1" daemon [_thread_blocked, id=61195, stack(0x000070000ea9e000,0x000070000eb9e000)]
  0x00007f887f05c800 JavaThread "clojure-agent-send-off-pool-4" [_thread_in_native, id=59395, stack(0x000070000e795000,0x000070000e895000)]
  0x00007f887f10b800 JavaThread "clojure-agent-send-off-pool-3" [_thread_blocked, id=58883, stack(0x000070000e692000,0x000070000e792000)]
  0x00007f887a8e3000 JavaThread "clojure-agent-send-off-pool-2" [_thread_in_native, id=58371, stack(0x000070000e58f000,0x000070000e68f000)]
  0x00007f887dbe0000 JavaThread "AWT-AppKit" daemon [_thread_in_native, id=775, stack(0x00007fff506ee180,0x00007fff50f3f000)]
  0x00007f8879e3c800 JavaThread "clojure.core.async.timers/timeout-daemon" daemon [_thread_blocked, id=22275, stack(0x000070000dff7000,0x000070000e0f7000)]
  0x00007f8879812800 JavaThread "Service Thread" daemon [_thread_blocked, id=21251, stack(0x000070000ddf1000,0x000070000def1000)]
  0x00007f8878031800 JavaThread "C1 CompilerThread3" daemon [_thread_blocked, id=20739, stack(0x000070000dcee000,0x000070000ddee000)]
  0x00007f8879826800 JavaThread "C2 CompilerThread2" daemon [_thread_blocked, id=20227, stack(0x000070000dbeb000,0x000070000dceb000)]

I thought I'd post this here in case you've seen this before using gniazdo or can advise where I might look?

on-close callback fails silently when it's not set properly

Callbacks fail silently when they are not set properly

Reproduce like this:

(def socket
  (ws/connect
     "ws://localhost:10081"
     :on-close #( prn "expecting two arguments, but receiving one" %1)
     :on-receive #( do-something %)))

I would expect something like this to be logged:
ArityException Wrong number of args (2) passed to: core$eval1346$fn clojure.lang.AFn.throwArity (AFn.java:437)

But is not.

Is this logged somewhere else?
Or where can I see the "Wrong number of args" exception?

problematic SslContextFactory configuration?

On simple upgrade requests such as (ws/connect "ws://0:9010"), I'm seeing log warnings such as:
2019-08-13 08:20:06.295:WARN:oejusS.config:nRepl-session-c40a622b-bbc0-42d7-84a6-b22f8ac7da9e: No Client EndPointIdentificationAlgorithm configured for SslContextFactory@4a9bb654[provider=null,keyStore=null,trustStore=null]

It seems to my naive eyes that it might be related to this issue with jetty:
jetty.project issue 3049, warn on problematic configurations

Max Request Size Issue

                                                        java.lang.Thread.run                       Thread.java: 748
                        org.eclipse.jetty.util.thread.QueuedThreadPool$3.run             QueuedThreadPool.java: 572
                       org.eclipse.jetty.util.thread.QueuedThreadPool.runJob             QueuedThreadPool.java: 654
            org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run        ExecuteProduceConsume.java: 156
  org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun        ExecuteProduceConsume.java: 246
                            org.eclipse.jetty.io.SelectChannelEndPoint$2.run        SelectChannelEndPoint.java:  93
                                  org.eclipse.jetty.io.FillInterest.fillable                 FillInterest.java:  95
              org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded           AbstractConnection.java: 273
                           org.eclipse.jetty.io.ssl.SslConnection.onFillable                SslConnection.java: 186
                                  org.eclipse.jetty.io.FillInterest.fillable                 FillInterest.java:  95
              org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded           AbstractConnection.java: 273
org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onFillable  AbstractWebSocketConnection.java: 505
 org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.readParse  AbstractWebSocketConnection.java: 675
                             org.eclipse.jetty.websocket.common.Parser.parse                       Parser.java: 252
                        org.eclipse.jetty.websocket.common.Parser.parseFrame                       Parser.java: 480
           org.eclipse.jetty.websocket.common.Parser.assertSanePayloadLength                       Parser.java: 127
  org.eclipse.jetty.websocket.api.WebSocketPolicy.assertValidTextMessageSize              WebSocketPolicy.java: 140
org.eclipse.jetty.websocket.api.MessageTooLargeException: Text message size [225970] exceeds maximum size [65536]
    statusCode: 1009

Possible to make the WebsocketPolicy exposable?

Jetty 10/11

Jetty 10 and 11 has been released for a while and it is recommended to upgrade to the newer version.

Missing license

Hi,
it looks like you are missing the license in the project config file.

https://www.versioneye.com/Clojure/stylefruits:gniazdo/1.0.0

Thanks

http_proxy support

Is there any support for proxies?

Proxy Support

Current status of http_proxy support in Gniazdo

As of 11/2016, it is not supported in gniazdo due to limitations of Jetty 9 (see jetty/jetty.project#117). It seems they plan to fix it in Jetty 9.4.x.

However, you can use gniazdo-jsr356 instead of Gniazdo. It has outwardly the same API but internally it uses the standard Java EE websockets API and its Tyrus implementation (while also supporting Jetty). Tyrus does support http_proxy (and other settings).

More discussion can be found in #16.

Sending a cookie along with UpgradeRequest

Hi,
For some reason (may be Jetty related) if I add a headers map that looks like this:

{"Cookie" "somethinghere" "Bla" "blabla"}

I can see only the second one being sent ("Bla") and the cookie get stripped.

I need the cookie sent for authentication purposes, how can I do it?

Thanks.

Custom WebSocketClients require manual stop

After working with the websockets for a while, I noticed that in order to create a websocket with an adequate buffer size, I have to manually create a websocket client (or use the provided client function from gniazdo), but when I close the websocket, that client isn't stopped. That may be intended behavior, but the result is that it keeps applications alive after all other non-daemon threads have stopped, and it's difficult to determine the reason because it's not mentioned in the documentation.

I'd love to see the documentation related to the client function specify that the client must have .stop called on it in order to exit the application.

Send headers or params, with send-msg?

I'm taking a look at the spec for WS data frames. And I just see a way to pass a generic payload.

Is there any way to send headers or params, along with send-msg? I don't see one. But I'm hoping I'm wrong.

Text message size [146765] exceeds maximum size [65536]

Hi, I have the error mentioned in the title. I looked for that error in Jetty in google, and found that there's a function setMaxTextMessageBufferSize that could be used in the policy of the websocket client to increase this size, but it didn't work.

I am quite new to java interop, so if there is any mistake, please correct me.

Does anyone know how to solve it?

This is the code I'm currently using, taken from different ns

(defprotocol IWebSocketActions
  (connect [this] [this wsclient])
  (send-msg [this msg])
  (close [this]))

(defrecord WebSocketClient [url conn handlers]
  IWebSocketActions
  (connect [this]
    (let [new-conn (apply ws/connect url (flatten (into [] handlers)))]
      (reset! conn new-conn)))
  (connect [this wsclient]
    (println (flatten (into [:client wsclient] handlers)))
    (let [new-conn (apply ws/connect url (flatten (into [:client wsclient] handlers)))]
      (reset! conn new-conn)))
  (send-msg [this msg]
    (when-let [wsc @conn]
      (ws/send-msg wsc (json/generate-string msg))))
  (close [this]
    (ws/close @conn)
    (reset! conn nil)))

(def client (ws/map->WebSocketClient {:url bitmex-url
                                      :conn (atom nil)
                                      :handlers handlers}))

(def ws-client (let [client (websocket/client (new URI bitmex-url))]
                           (.setMaxTextMessageBufferSize (.getPolicy client) Integer/MAX_VALUE)
                           (.start client)
                            client))

(ws/connect client ws-client)
;; (ws/close client)
(ws/send-msg client {:op "subscribe", :args ["orderBookL2:XBTUSD"]})

The handlers is just a map, and the connect works properly, and with small messages also works fine.

pls add support for configuring websocket extensions

for example, configuring the "permessage-deflate" extension in the ClientUpgradeRequest object. The object has an addExtension (or similar) method.

Async nature of websockets

Quick question, if you know. Does the websocket listener run in a background thread, and if it does, is it calling my receiving functions also on another thread, or does it dispatch directly to the main thread? I'm trying to understand what, if any, consideration I should have for asynchronous activity when processing socket messages, since it is important I process them in the order they are received.

Turn off logging of all incoming messages

All incoming socket messages are logged to the repl (if running lein repl) or to nrepl in my case, when using cider. I'm wondering if there is a way to turn that off? Logging is a time-consuming activity and I have a hunch it is responsible for some latency in my app, since I can't find any latency when timing things in my code. Plus it would just be nice not to see all the bytes streaming by.

stalefruits / gniazdo Goto Github PK

gniazdo's People

Contributors

Stargazers

Watchers

Forkers

gniazdo's Issues

Current status of http_proxy support in Gniazdo

Recommend Projects

Recommend Topics

Recommend Org