Closed NeoVance closed 9 years ago
This looks the same as #36 .
It should be checking the precision as soon as the router starts. I don't have a windows system with me right now but will try to reproduce the problem within the next day or two.
Does your router say "Changing PHP precision from 12 to 16" when you start it?
Hi @NeoVance ,
I tried this on my windows 8 machine with php 5.6.1 and was not able to reproduce the issue.
Do you have a link to the php that you installed on your system? Mine appears to be different from yours. Your version appears to be built in a cygwin environment.
Thanks.
I do not currently see any messages saying that it is changing the precision setting, but it is currently set to 16. Here is a mirror for the cygwin PHP packages, and source http://mirrors.kernel.org/sourceware/cygwin/x86_64/release/php/
Actually.. Now looking, it appears that the PHP version has been released recently. The older version has been replaced. Should I consider upgrading, to see if this may be fixed by the new version of PHP?
The issue persists in the latest version. I think that it may be the way the numbers are stored specifically in Cygwin.
Hi @NeoVance ,
I have tried this on my windows 8.1 machine with both 64 bit and 32 bit cygwin php as well as the 32-bit VC11 php and was not able to reproduce. It should not be an ini problem either as Thruway now sets precision if it is not big enough.
I can't think of anything that would make that difference.
Are you able to see the frames in your browser to see if they are coming back from the router like that.
Another oddity is that the number returned on the subscribed message (9.223372036854776e+18) is not even close to the number 4016700523544576. In previous issues with integer precision, the numbers got converted to the equivalent floating point.
Let me know what you see in the frames if you have a chance.
Hi @mbonneau just noticed this is happening on my install of PHP5.6 on CentoOS 6. Im going to try and play around with the precision. My router does say that its changing the precision from 14 to 16.
I've noticed that in my frames for the socket it happens every time the router sends this from what I can tell. Its when I'm trying to unsubscribe.
[34,3121968693903360,6696403640804607] (client)
[35,3121968693903360] (router)
[8,34,3121968693903360,{},"wamp.error.no_such_subscription"] (router)
I'll do some more digging :+1:
Hi @adamlc ,
Are you have the same issue with floating point numbers showing up?
@mbonneau I don't appear to be. Heres my AB debug
WebSocket transport send [34,8816509960847360,4575818069412666]
autobahn.min.js:33 WebSocket transport receive [35,8816509960847360]
autobahn.min.js:33 WebSocket transport receive [8,34,8816509960847360,{},"wamp.error.no_such_subscription"]
autobahn.min.js:33 failing transport due to protocol violation: UNSUBSCRIBE-ERROR received for non-pending request ID 8816509960847360
autobahn.min.js:115 Uncaught InvalidAccessError: Failed to execute 'close' on 'WebSocket': The code must be either 1000, or between 3000 and 4999. 1002 is neither.
For me anyway its something to do with unsubscribing
If I'm reading the spec right it looks like it unsubs successfully but then the router sends back a no subscription error back immediately for some reason.
This might be a different issue. What version of Thruway are you using?
@mbonneau I'm using 0.3.6. It looks like it could be something different from whats going on above!
Can you open a new issue for this? I will check it out and see if I can reproduce.
Will do!
Hi @NeoVance ,
I am closing this issue as I am not able to reproduce. If you do get any more information on how to reproduce this, please reopen the issue.
All attempts to fix using solutions from existing issues has not succeeded.
Server
PHP Info
Autobahn.js Debugging Output
Thruway Debugging Output