Perl 6 - the future is here, just unevenly distributed

IRC log for #openam, 2016-02-25

| Channels | #openam index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:05 aldaris1 joined #openam
00:19 MegaMatt joined #openam
00:20 techtenk joined #openam
00:34 MegaMatt joined #openam
06:53 aldaris joined #openam
07:15 aldaris joined #openam
07:32 jjpp hi.
07:44 aldaris1 joined #openam
08:05 jjpp aldaris1: do you know of a way to signal openam that one of the openam nodes in failover cluster is going to go down and should be removed from pool?
08:05 aldaris1 there is no such thing
08:06 jjpp hm. so.. there is a chance that there is a stale connection in pool and something fails because of that?
08:08 aldaris what pool?
08:09 jjpp for some historic reason i usually have datastore and userstore in on instance. so in any of the connection factories that connect to it. (yes, i know that they should be separate. we have managed to move cts out and that is a win:)
08:09 jjpp s/in on/in one/
08:11 jjpp i tried to test it last night. we have a script that creates-checks-and-ends sessions (it keeps some configurable number of sessions open and with some timeouts replaces them and checks if they are still alive)
08:12 aldaris when you say datastore did you mean configstore?
08:12 jjpp configuration was haproxy + 2 dauinodes + 2 openam nodes + (2+2) opendj nodes ("main" and cts clusters)
08:13 jjpp yeah.
08:13 aldaris but how is any of this related to openam instances going down
08:13 aldaris surely openam is not the same as opendj
08:13 jjpp oh,
08:14 jjpp i meant   aldaris1: do you know of a way to signal openam that one of the openDJ nodes in failover cluster is going to go down and should be removed from pool?
08:14 jjpp i keep mixing them up.
08:14 jjpp :(
08:14 jjpp sorry
08:14 aldaris no, there is no such thing
08:14 aldaris AM monitors the connections
08:16 jjpp so.. there is a race -- if the connection is "OK" when it is fetched from factory and not so much when the user of connection tries to send request?
08:16 jjpp (if it is not ok before returning from factory, it is closed and the new one is aquired, i understand?)
08:29 daveloper joined #openam
08:44 aldaris joined #openam
08:52 aldaris probably a new one won't be acquired for those cases
08:52 aldaris but the frequency of the heartbeat searches should make sure that stale connections don't stay in the system for too long
08:55 jjpp so.. during transition in a system with some load, there might be (openam-) requests that fail because of opendj connections being stale and not yet cleaned up?
08:55 jjpp transition -- situation where one of opendj nodes is just left the picture
09:01 [1]techtenk joined #openam
09:23 aldaris joined #openam
09:25 aldaris jjpp that assumes that the connection isn't closed properly by DJ/LB when the node disappears
09:26 jjpp aldaris: ok, that might happen when the hw or network dies. but it is probably okay to lose some of connections then (and we have much larger problems then anyway:)
09:27 jjpp and the normal use that was i was worrying about was the regular "let's shut one side of cluster down for upgrade" or something like that
09:29 aldaris upgrade is usually not a *regular* thing to do :)
09:33 jjpp well. martin fowler or someone said that "if it hurts, you should do it more often" :)
09:33 jjpp opendj upgrade/reconfigure is quite rare indeed.
09:35 HelgeO joined #openam
09:35 aldaris joined #openam
09:37 jjpp and.. on completely unrelated topic.. entitlements. i kind of remember you mentioning that there is a problem with cacheing those in 11?
09:58 HelgeO joined #openam
10:05 aldaris hard to tell what you are referring to jjpp :)
10:07 aldaris joined #openam
10:23 HelgeO joined #openam
11:00 orriols joined #openam
11:01 orriols Hi. I need to migrate user data from OpenAM to another IAM, including password. Should I continue with my search?
11:12 HelgeO joined #openam
11:43 HelgeO joined #openam
11:54 MegaMatt joined #openam
12:33 [1]techtenk joined #openam
12:58 HelgeO joined #openam
13:00 mckeanbs joined #openam
13:36 aldaris joined #openam
13:52 jjpp aldaris: the context for entiltments and cache'ing is that something does a lot of identical entitlement-queries. most of the requests in opendj are entitlement-related. and half of those are exactly the same query
13:53 jjpp it seems to be a web agent. one that has sso.only=true so it should not be interested in authorization information?
13:54 aldaris web agents perform policy requests to obtain profile attribute values
13:55 jjpp and it is actually a service in openam that should cache that information but does not?
14:36 aldaris1 joined #openam
15:53 daveloper joined #openam
16:29 aldaris joined #openam
16:58 orriols joined #openam
17:02 techtenk joined #openam
17:06 aldaris joined #openam
17:35 aldaris joined #openam
18:22 aldaris joined #openam
18:48 aldaris joined #openam
19:26 techtenk joined #openam
19:36 daveloper joined #openam
20:12 daveloper1 joined #openam
20:20 daveloper joined #openam
20:24 daveloper1 joined #openam
20:29 orriols joined #openam
20:42 daveloper joined #openam
21:01 mckeanbs joined #openam
21:06 aldaris joined #openam
21:31 aldaris joined #openam
21:58 MegaMatt joined #openam

| Channels | #openam index | Today | | Search | Google Search | Plain-Text | summary