Config/Settings to ApplicationRunner (openHandshakeTimeout) #838
Comments
|
+1 struggling to find where to change this as well. |
|
Some here some developers to answer? |
|
This isn't currently exposed at the |
|
To clarify, there is currently no access via ApplicationSession or ApplicationRunner? Is there a single place to hard-patch at the module level? |
|
@michael-wise monkey patching will not work, as the underlying factory is a locally scoped variable: https://github.com/crossbario/autobahn-python/blob/master/autobahn/twisted/wamp.py#L256 |
|
I'm kinda stuck waiting for this fix to be able to work with a server under heavy load that usually takes longer to complete handshake. The hard-coded values in https://github.com/crossbario/autobahn-python/blob/master/autobahn/twisted/wamp.py#L256 would still override the fix in #844? Would love it if you would correct that before doing the next release. I tried using the head of master after #844, and passing the options to the |
|
@myth curious, what server exactly? could you describe your setup? |
|
Hi and thanks for the fast reply! I'm attempting to connect to I'm just prototyping the application for now, hence using the ApplicationRunner convenience, but my setup is just: And i start using the runner: To figure out what I needed to set the timeout to to make sure the connection would finish before being preemtively terminated, I patched the hardcoded numbers in https://github.com/crossbario/autobahn-python/blob/master/autobahn/twisted/wamp.py#L256 and set both to 60 just to test. I also had to increase the ping timeout, as that also happened a couple of times. This is the debug output from the runner, where my attempt at passing in an option dict to the As you can see, the handshaking took a very long time, 28s in this case. It varies greatly, and sometimes it will connect just after a few seconds. I'm unaware of what is the root cause of these huge swings in delay, but a means to control the protocol parameters here is required to make it work... |
|
Interesting! They must be running a quite old version of Crossbar.io, which you can tell from the WebSocket upgrade header: We (Crossbar.io GmbH) are offering commercial support for Crossbar.io and all Autobahn client libraries, and as they are running a commercial venture, we'd be happy to address these issues under a support contract. We currently are working with a couple of companies already, and because of limited resources, we prioritize paying customers. |
|
That is understandable!
I'll just override the setting manually for the time being then. Thank you
for your time!
|
|
If I may add an unsolicited opinion from someone who's knowledge of this library extends only to what was necessary to handle the poloniex feed: Groking the code to change a timeout parameter should not be this hard. The heavy use of OOP here makes it very difficult to understand what the code base is doing if you didn't write it. Generally speaking if you're writing automated trading systems you can RTFM. I've rarely encountered a code base that was as difficult to parse as this one. |
|
Have you looked at the (in-progress) For your use-case that would look something like this: Is this API easier to understand? Although you can still use an |
|
Note you can also do |
|
@meejah Thanks, i'll look into that! I was probably going to try to replicate the basics of what ApplicationRunner does, but was unsure of how much was needed. That example looks simple enough to get me started working with the Component API! |
|
@jonathanstrong there are 3 main reasons for the relative complexity of the code base:
There are more reasons:
The code is very well factored to allow that. Eg adding another serializer is trivial. But the price is a relative complexity in the classes involved, and how they interact. |
|
The simple answer is that you shouldn't need to delve into the code just to change an option. This is addressed by the "component" API, but is a shortcoming of the If you are interested in making Ping me in IRC (#autobahn) if you need some help |
|
@meejah I tried your example using the following setup, but keep getting some errors: Errors: I've tried looking at the source for the Component class, but can't seem to find exactly where this hiccup is coming from. EDIT (Added trace): |
|
Ah, thanks! See #848 Meantime, you should be able to just put |
|
@meejah Ty for the fast response, really appreciate it! |
|
The I also tried constructing the endpoint dict manually, like it is done here: https://github.com/crossbario/autobahn-python/blob/master/autobahn/wamp/component.py#L148 but that just triggered the same error as in #848 |
|
Sorry, the |
|
@meejah is there an aproximate date when we can expect the component API to work with asyncio? I am suffering the same problem and my program is written all in asyncio. |
|
@subiol pls see my comment here #838 (comment) |
|
@oberstet Sure, I understand, but as far as I can see this is also an open source project, so I dont see how asking for an approximate date when an API in development will be ready is bad or disrespectful. If the answer is you dont know, so be it, but I dont see how it hurts to ask. |
|
Nothing disrespectful about asking! The answer is: unknown. What @oberstet is getting at is that having a paying customer who wants this would speed it up dramatically :) The reason I've been doing "Twisted only" side first is to make sure the API is right so that if it's not, we only have to change one framework's code. Also I know Twisted better than asyncio. Of course, if you're interesting in helping by making a All that said, this API has decent consensus I think so I don't expect any major changes -- more like "possibly some tweaks". |
|
Yeah, IMO the component API is definitely the way forward. The ApplicationRunner was basically a quick hack to collect the low-level boilerplate on top of ApplicationSession and the raw transport factory classes. On a sidenote, the new AutobahnJava is following some crucial design improvements that the component API has, eg the session lifecycle can be tapped into from user code using the observer pattern. |
|
Hey, i'm having the exact same problem. Adding
EDIT: I think I figured it out. For those wondering, the correct code is: component = Component(
realm=u'realm1',
transports=[{
'endpoint': {
'type': 'tcp',
'host': u'api.poloniex.com',
'port': 443,
'tls': True
},
'type': 'websocket',
'url': u'wss://api.poloniex.com',
'options': {
'open_handshake_timeout': 60.0
}
}]
) |
|
I just tried that with a fresh install, getting this error: any chance you ran into the same thing? Appreciate the help! Update: dug into the source a bit and found this:
So I changed to and am now getting ticker prices. |
|
Nice! Ya, using |
|
You almost certainly do not want threads for what you're asking for. Are you doing some very CPU-intensive things somewhere? |
|
Nope, no CPU-intensive work. What I want is to be able to have multiple websocket clients running simultaneously, connected to different servers. And then I want code running 'above' them in the logical sense to be able to manage them (i.e. subscribe/unsubscribe to different channels, add event listeners for messages, etc..). You're certainly probably right that i'm doing it wrong, I haven't really messed with concurrency or asynchronous I/O in Python before. |
|
@ashaffer there is no point on using threads since the python GIL does not allow for two threads to run at the same time and the library already uses asyncio/twisted to deal with blocking calls. So using threads will (most likely) slightly decrease performance. But if you still wanted to do it just because, you just need to pass messages between the threads, for example using a asyncio thread queue like janus https://github.com/aio-libs/janus . |
|
@ashaffer you don't need threads for that when using Twisted (or asyncio) |
|
@meejah Ya, I kind of suspected that. It didn't feel right, but it's not clear to me how else to do it, since the |
|
@ashaffer you have two options:
Note that in case 2 your program will still use only one core since the python GIL does not allow two threads to run at the same time. The difference is that in case 1 you decide in which order your code executes, while in case 2 the python thread scheduler will switch between the threads as its see fit, so it should be slightly less efficient. This should solve your doubts, since I think we have already dirtied the issue with enough of topic. |
Hi,
How can I override default openHandshakeTimeout param?
I am going run ApplicationRunner with greater handshake timout in python code.
I have tried, but nothing:
subscriber = ApplicationRunner(url=u"wss://api.....", realm=u"realm1",extra={'openHandshakeTimeout':10})The text was updated successfully, but these errors were encountered: