On Fri, Jul 28, 2017 at 2:56 PM, Johann Nallathamby <[email protected]> wrote:
> Do you think we can live with these two kind of caches only? I am not sure.
>
Above properties for only the caches which are in framework. Basically to
handle the end user's session related stuff.. I do not think we need
separate configuration for each caches in framework.
But; Yes. we can consider separate configurations for other caches in
different components.
+1 If above configurations ("SessionDataPersist") are used by other
components such as OAuth2 it is wrong. We need to fix with different
configuration.
Thanks,
Asela.
> May be others from IAM team can chip in. My objective is to use sticky
> sessions as much as possible and persist as less as possible, make the
> flows optimized. If there are no limitations in this I am fine
>
> E.g. SAML2 SSO and OAuth2 should work in a single setup without any issue
> and I want be able to disable all kind of temporary caches for SAML2 SSO
> because it can take advantage of sticky sessions, only having the user SSO
> session cache and SAML2 participant cache persisted, while for OAuth2 we
> need to persist some additional caches such AuthorizationGrantCache because
> it is used from Token endpoint which can't use sticky sessions. Is this
> possible now? If it's possible then it's fine and my thinking may be wrong.
>
> Regards,
> Johann.
>
> On Fri, Jul 28, 2017 at 2:13 PM, Asela Pathberiya <[email protected]> wrote:
>
>>
>>
>> On Fri, Jul 28, 2017 at 12:42 PM, Johann Nallathamby <[email protected]>
>> wrote:
>>
>>> Hi,
>>>
>>> What do you think about introducing $subject to selectively persist each
>>> and every cache we have? Right now I think all the caches are controlled by
>>> just two attributes "SessionDataPersist.Enabled" and
>>> "SessionDataPersist.Temporary". This classification is too broad I
>>> think with the recent performance issues we faced. So shall we do $subject?
>>>
>>
>> IMO; we have used above two properties when it comes to persist the end
>> user's SSO session. There may be few caches which governs by the
>> "SessionDataPersist.Temporary" property. Do we really need multiple
>> properties for each caches ? What is the actual use of it ? I suspect it
>> would make configuration more complex.
>>
>> Thanks,
>> Asela.
>>
>>
>>> I think the change won't take that much effort. May be about 30mins for
>>> Farasath :)
>>>
>>> Thanks & Regards,
>>> Johann.
>>>
>>> --
>>>
>>> *Johann Dilantha Nallathamby*
>>> Senior Lead Solutions Engineer
>>> WSO2, Inc.
>>> lean.enterprise.middleware
>>>
>>> Mobile - *+94777776950*
>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>>>
>>
>>
>>
>> --
>> Thanks & Regards,
>> Asela
>>
>> ATL
>> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>> +358 449 228 979
>>
>> http://soasecurity.org/
>> http://xacmlinfo.org/
>>
>
>
>
> --
> Thanks & Regards,
>
> *Johann Dilantha Nallathamby*
> Senior Lead Solutions Engineer
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+94777776950*
> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>
--
Thanks & Regards,
Asela
ATL
Mobile : +94 777 625 933
+358 449 228 979
http://soasecurity.org/
http://xacmlinfo.org/
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev
