|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
>One more thing while we are trying to reproduce the issue, could you check if going through regular port 443 for XHR works or fails similarly?
Absolutely, I'll try this out and report back.
>I just tested https://github.com/ramr/pacman setting transports to just "xhr-polling" in server.js and it seems to work fine. I enabled logging in the proxy server to verify that it used xhr-polling.
The above uses a nodejs cartridge as far as I can tell and also it uses socket.io and we are using SockJS. When we stared out testing WebSockets with AS7 cartridge we discovered issues that were not present when using a nodejs cartridge. So because it works with a nodejs cartridge does not guarantee that it will work with ours (which is based on AS7).
xhr_polling is not as interesting as xhr_streaming in the case I think, as polling only uses a simple request reply model. xhr_streaming (SockJS) on the other hand will use a persistent connection and send chucks of data as they become available on the server side. I'm thinking that there is something wrong with how these connections are handled somewhere (our code, or perhaps a proxy).