Home » Modeling » EMF » [CDO] Timeout in ChangeCredentialsRequest
| [CDO] Timeout in ChangeCredentialsRequest [message #1711856] |
Tue, 20 October 2015 03:46  |
Eclipse User |
|
|
|
Hi,
when using the
session.changeCredentials()
method I typically get a timeout. The reason for this is that the session timeout is set to 10s by default. But to enter the required credentials in the dialog typically (or sometimes) takes longer than 10s.
Actually I would expect that the dialog could stay open "forever" without getting a timeout. Has anyone encountered the same problem with changeCredentials or the login dialog and has a solution for this?
Regards,
Thorsten
|
|
| |
| Re: [CDO] Timeout in ChangeCredentialsRequest [message #1711972 is a reply to message #1711877] |
Tue, 20 October 2015 09:31  |
| Eclipse User |
|
|
|
Hi,
This protocol was modeled after the login/authentication protocol,
which also employs a dialog for user input. If the monitor doesn't
keep the timeout bumping along, then I don't have any idea why that's
not working. In any case, when I initially tested this a few years
ago, I'm fairly certain that I was never fast enough to beat a
10-second deadline, and I didn't see timeouts ... But my memory is not
reliable.
Is this timeout absolutely reproducible? How does the behaviour of the
login dialog compare with the password change dialog?
Cheers,
Christian
On 2015-10-20 08:35:46 +0000, Eike Stepper said:
> Am 20.10.2015 um 09:46 schrieb Thorsten Schlathölter:
>> Hi,
>> when using the
>>
>> session.changeCredentials()
>>
>>
>> method I typically get a timeout. The reason for this is that the
>> session timeout is set to 10s by default. But to enter the required
>> credentials in the dialog typically (or sometimes) takes longer than
>> 10s.
>>
>> Actually I would expect that the dialog could stay open "forever"
>> without getting a timeout. Has anyone encountered the same problem with
>> changeCredentials or the login dialog and has a solution for this?
> I briefly looked at the involved signals and they're all "with
> monitoring", which should reset the timeouts on monitor ticks. Both
> ChangeCredentialsIndication.responding() and
> CredentialsChallengeIndication.responding() properly use
> monitor.forkAsync() to create the needed monitor ticks. So I have
> currently no explanation for your timeouts.
>
> The changeCredentials protocol was implemented by Christian (cc'ed).
> Maybe he has an idea...
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
|
|
| |
| Re: [CDO] Timeout in ChangeCredentialsRequest [message #1712028 is a reply to message #1712013] |
Tue, 20 October 2015 18:04 |
| Eclipse User |
|
|
|
Hi,
I can reproduce the problem on the latest master.
I've never seen this before; quite certain that it did not happen two
years ago when I first implemented the password change and reset
functions. And I don't think I changed the way login works, so I
suspect something more fundamental has changed in the timeout behaviour
(although I can't imagine anyone having made such changes). Eike?
Oddly, if I let the login dialog timeout and then complete it with the
correct credentials, the session is not connected (nothing happens).
But, if I let the password change dialog time out and then complete it
with the correct old and new passwords, it does successfully effect a
change of my password in the server. The next time I login, I have to
use the new password set in the dialog that timed out.
I don't really have much else to say without digging into the code and
debugging it ... In any case, it would be useful if you could raise a
bug in the bugzilla database.
Cheers,
Christian
On 2015-10-20 18:04:33 +0000, Thorsten Schlathölter said:
> It happens all the time if login time is longer than 10s. Login,
> Changepassword (ContextMenu), ResetPassword in the Editor same
> behaviour. Reproducibility 100%.
|
|
|
| Re: [CDO] Timeout in ChangeCredentialsRequest [message #1712797 is a reply to message #1712028] |
Wed, 28 October 2015 06:17 |
| Eclipse User |
|
|
|
Hi,
Hi thinks it is a regression from commit c6511790, i.e. Bug 441136.
With this commit the MonitorProgressRequest/MonitorProgressIndication
signals are make optionals if IProgressMonitor is not used, for example
on CDOTransaction.commit(IProgressMonitor).
To fix your issue about ChangeCredentialsRequest, we could either revert
the commit about Bug 441136 or force ChangeCredentialsRequest use a
monitor. What do you think?
Best Regards
Le 21/10/2015 00:04, Christian W. Damus a écrit :
> Hi,
>
> I can reproduce the problem on the latest master.
>
> I've never seen this before; quite certain that it did not happen two
> years ago when I first implemented the password change and reset
> functions. And I don't think I changed the way login works, so I
> suspect something more fundamental has changed in the timeout behaviour
> (although I can't imagine anyone having made such changes). Eike?
>
> Oddly, if I let the login dialog timeout and then complete it with the
> correct credentials, the session is not connected (nothing happens).
> But, if I let the password change dialog time out and then complete it
> with the correct old and new passwords, it does successfully effect a
> change of my password in the server. The next time I login, I have to
> use the new password set in the dialog that timed out.
>
> I don't really have much else to say without digging into the code and
> debugging it ... In any case, it would be useful if you could raise a
> bug in the bugzilla database.
>
> Cheers,
>
> Christian
>
>
> On 2015-10-20 18:04:33 +0000, Thorsten Schlathölter said:
>
>> It happens all the time if login time is longer than 10s. Login,
>> Changepassword (ContextMenu), ResetPassword in the Editor same
>> behaviour. Reproducibility 100%.
>
>
|
|
|
| Re: [CDO] Timeout in ChangeCredentialsRequest [message #1712810 is a reply to message #1712797] |
Wed, 28 October 2015 08:07 |
| Eclipse User |
|
|
|
Am 28.10.2015 um 11:17 schrieb Esteban Dugueperoux:
> Hi,
>
> Hi thinks it is a regression from commit c6511790, i.e. Bug 441136.
> With this commit the MonitorProgressRequest/MonitorProgressIndication signals are make optionals if IProgressMonitor
> is not used, for example on CDOTransaction.commit(IProgressMonitor).
Thanks for the heads up!
>
> To fix your issue about ChangeCredentialsRequest, we could either revert the commit about Bug 441136 or force
> ChangeCredentialsRequest use a monitor. What do you think?
I think the latter sounds promising. Thorsten, can you please submit a bugzilla?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> Best Regards
>
> Le 21/10/2015 00:04, Christian W. Damus a écrit :
>> Hi,
>>
>> I can reproduce the problem on the latest master.
>>
>> I've never seen this before; quite certain that it did not happen two
>> years ago when I first implemented the password change and reset
>> functions. And I don't think I changed the way login works, so I
>> suspect something more fundamental has changed in the timeout behaviour
>> (although I can't imagine anyone having made such changes). Eike?
>>
>> Oddly, if I let the login dialog timeout and then complete it with the
>> correct credentials, the session is not connected (nothing happens).
>> But, if I let the password change dialog time out and then complete it
>> with the correct old and new passwords, it does successfully effect a
>> change of my password in the server. The next time I login, I have to
>> use the new password set in the dialog that timed out.
>>
>> I don't really have much else to say without digging into the code and
>> debugging it ... In any case, it would be useful if you could raise a
>> bug in the bugzilla database.
>>
>> Cheers,
>>
>> Christian
>>
>>
>> On 2015-10-20 18:04:33 +0000, Thorsten Schlathölter said:
>>
>>> It happens all the time if login time is longer than 10s. Login,
>>> Changepassword (ContextMenu), ResetPassword in the Editor same
>>> behaviour. Reproducibility 100%.
>>
>>
|
|
| |
Goto Forum:
Current Time: Fri Nov 07 11:14:43 EST 2025
Powered by FUDForum. Page generated in 0.25482 seconds |
Home