The GSI Secure Conversation is a mechanism where the security context created during handshake is stored as a resource object. The security context and hence the resource, by default has the lifetime of the credential used to create the security context. So if you used your proxy with default lifetime, the security context resource will not be destroyed for about 12 hours. Changing the sweeper delay does not affect this, since the resources don't expire in time for sweeper to delete them.
You can configure the lifetime of the context by setting an Integer property for this constant on the stub. org.globus.wsrf.impl.security.authentication.Constants.CONTEXT_LIFETIME Rachana > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of andrea manzi > Sent: Tuesday, November 13, 2007 6:19 AM > To: [email protected]; [EMAIL PROTECTED] > Subject: [gt-user] GSISecureConversation and memory overflow > > Hi all, > We already posted my problem to the mailing list, but we didn't receive > any reply. > we try again by giving you some more accurate information. In our > project we are experiencing a serious (and blocker for us) issue with > the memory consumption related to the adoption of the > GSISecureConversation as security mechanism. The Java WS Core container > crashes after a while when such a mechanism is enabled and used among > our service's invocations. > Just to give you an idea, We have tested a service operation (it does > not perform any task, just returns) using GSISecureConversation with and > without delegation (test 1 and 2) and using GSITransport (test 3). Here > below you can find the related outcomes: > > Test 1: > Service configuration: > Mechanism: GSISecureConversation > Run-As: Caller-identity > Client configuration: > Mechanism: GSISecureConversation (privacy) > Delegation: full delegation > After about 7500 invocations (two seconds of delay between each > invocation), the server crashes (OutOfMemoryError) > > Test 2: > Service configuration: > Mechanism: GSISecureConversation > Run-As: Service-identity > Client configuration: > Mechanism: GSISecureConversation (privacy) > Delegation: no delegation > After about 12000 invocations (two seconds of delay between each > invocation), the server crashes (OutOfMemoryError) > > Test 3: > Service configuration: > Mechanism: GSITransport > Run-As: Service-identity > Client configuration: > Mechanism: GSITransport (privacy) > Delegation: no delegation > After more than 20000 invocations (no delay between each invocation), > the memory consumption remains stable. > > This is the configuration of the host on which my services are running: > > Host: CPU Xeon 2800Ghz (2x), RAM 1Gbyte > OS: Scientific Linux 3.0.4 > Java Version: 1.5.0_06 > Java WS-Core version : 4.0.4 > JVM: started with an upper limit of 512 Mb memory > > In the container configuration, we tried to set the Security context > sweeper delay to 10 mins, but nothing changed. > > Is someone else experiencing the same problem? > > Thanks in advance for any help, > > Andrea Manzi & Paolo Roccetti
