Hi Michael, you are right - Scott pointed to the same direction.
Do you (or anybody else here) has enough experience with forking and can show me a a way to share at least some vital cache information between forks?
Background: I am migrating the Smartcard Personalization Workflow to use the new Connector Style Config. We need to create "cross references" on the config which requires to walk thru the whole tree and that is extremly slow, so we urgently need to cache the info.
A workaround would probably be to create this reference tree once on Server init, so the cached info is in the "root" context and gets inherited by each child. But that blows up the amount of data that needs to be copied on each fork.
Oliver On 30.03.2012 22:35, Michael Bell wrote:
Hi Oliver, well a singleton is not easy to implement if we use the usual Unix fork method. The class does not use IPC. If I understand it correctly then a workflow runs in a forked child process. This means that it gets a copy of the parent environment (which is called context). The class OpenXPKI::Server::CTX has a hash named who_forked_me. The key is the workflow ID and the value is an array which consists of the parent process ID (PPID) and the process ID (PID). If I see such terms in an old style Unix environment (without threads) then I would assume that the most variables where cloned on fork. If you look into OpenXPKI::Server then you see that all database and log handles are disconnected before the server loop is started. So a newly forked process/activity/workflow must open a fresh database connection. This connection must be and is invisible for other processes. So I personally think the database object must and should be a copy of an already initialized object. This is of course only a heuristic approach ;) Best regards Michael Am 30.03.2012 16:50, schrieb Oliver Welter:Hi, I hit a strange problem that I cannot explain... I use CTX('config') from inside a Workflow Action to access the new config layer (Instance of OpenXPKI::Config). I added a cache property to the config class which works fine as long as I am processing the same "workflow execution". If I now come back with another workflow action, the cache is empty again. I added a "create" and "lastaccess" timestamp to the class - the create time is always the same, the last access date is empty on every new workflow, so it looks like I get a new copy of the object on each new connect to the server. As far as I understand the Context class, its just a singleton holding a reference to the instance which should not get copied on access. Anybody has an idea whats going on? Oliver This body part will be downloaded on demand. This body part will be downloaded on demand.------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ OpenXPKI-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-devel
-- Protect your environment - close windows and adopt a penguin! PGP-Key: 3B2C 8095 A7DF 8BB5 2CFF 8168 CAB7 B0DD 3985 1721
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________ OpenXPKI-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-devel
