Determine Push transport before re-connect (#11884)
onConnect was allways called with websocket = false. I think this is wrong, since if there was connection loss in websocket, now connection cannot be re-established in websocket mode.
Fixes: https://github.com/vaadin/framework/issues/11299
This bug may have been manifesting in other ways as well
Recently similar fix was done in Flow as well, see: https://github.com/vaadin/flow/pull/7489
* Initialize Atmosphere in a context listener as JSR-356 requires
* Do not run JSR-356 or websocket tests on servers without support
* Adds /run-jsr356/ for testing JSR-356 websockets with uitest.war
* Change push path to /PUSH (from /PUSH/) to be compatible with JSR 356
endpoint mappings in Atmosphere (#14381)
Change-Id: Iec43f26df8c7b2bd347a713623a5298cc9e7b2cd
Ensure refresh message is sent on invalid CSRF (#17042)
If we create an AtmospherePushConnection and a broadcaster like before we would
need to suspend the connection to ensure the AtmosphereResource is actually
added to the broadcaster
Change-Id: I7265ac0594b7a4da2c7a49fa34ebfbb27e1abdff
* The resource should not be closed when the client disconnects
* Removed "automatic" disconnection which was needed when onresume was not handled
* Don't call disconnect twice for cancelled connections
Change-Id: Id5ad9924b56c8810f759d6f9dc1da6e83e53d75b
Do not call requestStart/end multiple times when using push (#14228)
All HTTP request based push request invoke onRequestStart/End in the servlet.
We need to trigger start/end separately in push handler only for websocket messages
Change-Id: I16064ea88b0c70812f247028ddb23560536db70d
removes extra VaadinSession.setCurrent() from PushHandler. (#14222)
The setCurrent call on VaadinSession is not needed. the one extra call
can be saved because service.findVaadinSession will already set it.
Added a comment like it is done for UI (service.findUI will also set the
UI).
Change-Id: Ic24d922554d1316aae310813ef5d00a0bbfd418a
Fix improper merge of 3d0ff32b from 7.1 to master (#13620)
Correctly call PushConnection.disconnect instead of setting to null.
Also remove the obsolete PushHandler.disconnectCallback.
Change-Id: Ied055d489a269b016318947cd89cf0b46003c596
Prevent duplicate detach() calls with push (#13261)
This used to happen when push was disconnected due to a UI or session
expiring. requestStart() and requestEnd() were called on disconnect
even though a disconnection is not a request.
Change-Id: I31d9cae65ec75b5046802a54bbe4564d6e44b29f
UIs now always have a PushConnection object if push is enabled,
and push reconnections do not create and set a new instance.
PushConnection.push can always be called; it internally handles
deferring the push until (re)connection if it is currently
disconnected. This is very desirable when using long polling,
as it reconnects after each push.
Change-Id: I478748cc940da86f34a5f55266f6b325682d4585
Minimal fix for error handling with streaming (#12578)
There are still issues in PushHandler where the wrong resource is used but these should not be as critical. They will be fixed in #12920
Change-Id: Ife8d3694bdb6ee29c5b4adbd8988cc0346c4fe3f
Handle push disconnections and reconnections more reliably (#11831, #11922)
Client-side:
* Call onOpen() also after a successful reconnection
* Reliably call onClose() and try to reconnect after disconnection
* Don't try to reconnect if !isApplicationRunning() after push
* Queue messages while trying to reconnect (state CONNECT_PENDING)
Server-side:
* Implement AtmosphereResourceEventListener.onDisconnect()
* Push marked as pending until client reconnects (if ever)
Change-Id: I1783eb72eb7005b07cae786d8ec8371da3903108
Make UI.pushConnection transient to prevent null resource after deserialization (#11809)
* PushConnection is not Serializable anymore
* AtmospherePushConnection fields are not transient
* UI.setSession calls setPushConnection(null) instead of pushConnection.disconnect()
* pushConnection.disconnect() asserts isConnected()
* If UI has a push connection, it should now always have isConnected() == true
Change-Id: I3c2e877b8e723b7cc2993cacd620920aecdef5fb
It appears that iOS6 will not make new request (at least for images) to a server to which there is already a connection open which possibly will be kept alive after the current request is done (Connection: Keep-alive asked by the client and not denied by the server)
Change-Id: If4e6233457fced3760a931b7953fa1713fee3452