Ping browser

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Ping browser

radhakrishnan.mohan
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Ping browser

Mike Wilson
Administrator
> What will happen to the call to update If the browser is killed or
> closed ? If there is a exception handling mechanism I can use it to
> invalidate my session.

No, DWR puts the update on queue and waits for the connection with the
browser to come back up again. When the browser comes back, the update is
sent. If the browser doesn't come back for a time interval corresponding to
the ScriptSession timeout, the ScriptSession is destroyed, which you can
detect with a ScriptSessionListener.

Thus there is no need for you to send pings to the browser. DWR will destroy
the ScriptSession independently of whether there is data on queue or not.

Mohan wrote:

> Hi,
>       I would like to open a new thread because the older
> thread 'Using
> DWR to detect browser close events' is not properly
> explaining my test.
> I am a new user.
>
> I am interested in using DWR to ping my browser using reverse ajax.
> This could be simple 'div' update.
>
> What will happen to the call to update If the browser is killed or
> closed ? If there is a exception handling mechanism I can use it to
> invalidate my session.
>
> How many threads should I start to ping one user session in
> one browser
> ?
>
> The application will run in a cluster of two machines. Is there any
> change in the basic DWR implementation due to this ?
>
> Doesn't the JEE spec. explicitly forbid the usage of threads in a
> managed environment ?
>
> Thanks,
> Mohan

Reply | Threaded
Open this post in threaded view
|

Re: Ping browser

radhakrishnan.mohan
In reply to this post by radhakrishnan.mohan
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Ping browser

radhakrishnan.mohan
In reply to this post by radhakrishnan.mohan
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Ping browser

radhakrishnan.mohan
In reply to this post by radhakrishnan.mohan
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Ping browser

Mike Wilson
Administrator
In reply to this post by radhakrishnan.mohan
> But I want to explain the use case. I maybe on the wrong track.

I understand your use case and I already suggested a solution to it
in a previous mail:

    You could do the same kind of solution based on the HttpSession
    if you configure the appserver to use a short timeout and then
    use Ajax heartbeats to keep it alive as long as the user has
    the site open.

There is no need for using threads to send pings from the server
for your use case.
Reverse Ajax handles the "pings" for you but you are probably better
off  basing yourself on HttpSession handling. As I suspect you have
not fully understood your own use case I'll ask these questions:

1) Obviously you want to protect something in your system, by
   restricting access when the browser disappears. Are you talking
   about protecting a standard user login, or something else?

2) When a user gains access to the page, is his access only valid
   for this page load, or can he navigate over multiple pages and
   still have access? Does he still have access after hitting
   refresh (F5) on the current page?

Mohan wrote:

> Hi Mike,
>
>   I have a basic setup here and ScriptSessions are created and
> destroyed. But I want to explain the use case. I maybe on the wrong
> track.
>
> I am trying to send a regular ping' update to the browser. This could
> be a simple text string that updates a hidden text field. Now when the
> browser goes down the data is queued. I would like to set a timeout on
> this reverse ajax call so that when it is not able to send it within a
> minute it automatically destroys the ScriptSession(or another
> notification on the server side).
>
>
> Thanks,
> Mohan

Reply | Threaded
Open this post in threaded view
|

Re: Ping browser

Mike Wilson
Administrator
In reply to this post by radhakrishnan.mohan
Sort of. The mentioned bug affects cases with streaming modes
together with scriptSessionTimeout < 60s, which is not what I am
suggesting for your use case.
I will not reply to this topic again until you answer the questions
I sent in my previous mail. Please respect that the help given on
this list is offered in other people's unpaid time. Make sure you
do your homework, or pay someone to do it for you.

Mohan wrote:

> http://dwr.2114559.n2.nabble.com/DWR-Reverse-Ajax-works-as-mes
> saging-td
> 6245322i20.html
>
> http://directwebremoting.org/jira/browse/DWR-503
>
> These are the two threads that seem to be about the same question.
>
>
>
> Mohan

Reply | Threaded
Open this post in threaded view
|

Re: Ping browser

radhakrishnan.mohan
In reply to this post by radhakrishnan.mohan
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Ping browser

radhakrishnan.mohan
In reply to this post by radhakrishnan.mohan
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Ping browser

Mike Wilson
Administrator
In reply to this post by radhakrishnan.mohan
Right, so you are protecting state associated with the session and
not the page. That means that you can't invalidate the user's login
as soon as the Reverse Ajax connection is terminated because this
happens at every page navigation. The page you are leaving closes
its Reverse Ajax connection and the next page opens up a new
connection.
Thus you need to give the user's system time to load the next page,
let its Javascript execute, which will restore the Reverse Ajax
connection. That's why you need to think in timeouts, and picking a
too short timeout would log out users with slow systems on page
navigation. I would be hesitant to choose a timeout below 60s and
definitely not below 30s.

If you want to use a shorter timeout then you need to hack your
page so the user will never navigate away from it, ensuring that
the heartbeat logic doesn't have to be restarted. One way of doing
that is using frames, where you put the heartbeat stuff in a top
frame that is never reloaded, and then let the user navigate between
different pages inside a child frame.

Nothing of what I have written above is specific to DWR but is
rather general web development knowledge. That is why I am
asking you to do your homework and think about how your use case
should actually work before trying to configure DWR in various
ways that probably don't make sense in the end.

So I repeat:

Your best and easiest solution is to
1) Find a timeout which is long enough to don't risk that your
   slowest users are logged out on page navigation or refresh.
2) Configure your HttpSession invalidation timeout to this value.
3) Let your pages use a JavaScript heartbeat to keep their session
   alive. This could be done through an explicit DWR no-op call,
   implicitly through DWR Reverse Ajax in Polling Mode for any
   timeout value, or through DWR Reverse Ajax streaming modes (if
   the timeout >= 60s due to bug DWR-503).

Mohan wrote:

> I understand that I could extend JSESSIONID's validity.
>
> 1) Obviously you want to protect something in your system, by
>    restricting access when the browser disappears. Are you talking
>    about protecting a standard user login, or something else?
>
> I am trying to protect our bank's user who uses the site. Closed or
> crashed browsers should not reinstate cookies or caches. But sometime
> they do. So we want a new design in addition to cookies.  
>
>
> 2) When a user gains access to the page, is his access only valid
>    for this page load, or can he navigate over multiple pages and
>    still have access? Does he still have access after hitting
>    refresh (F5) on the current page?
>
> Users navigate to many pages after logging in. Pages refreshes don't
> log the user out.
>
> Thanks.