Return-Path: Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org Received: (qmail 8033 invoked by uid 500); 12 Mar 2002 08:48:38 -0000 Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@xml.apache.org Received: (qmail 8022 invoked from network); 12 Mar 2002 08:48:37 -0000 Subject: Re: deploy problem. would notwork. To: axis-dev@xml.apache.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Glyn Normington" Date: Tue, 12 Mar 2002 08:51:02 +0000 X-MIMETrack: Serialize by Router on d06ml007/06/M/IBM(Release 5.0.9a |January 7, 2002) at 12/03/2002 08:47:56 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N I could imagine scenarios where each of the alternative behaviours is acceptable. Allowing existing sessions to continue while preventing new sessions from starting is less disruptive to clients and would allow a server to be 'quiesced' once the number of existing sessions had decreased to zero. On the other hand, there may be a need to break existing sessions to perform some kind of urgent upgrade. Perhaps the former behaviour should be the default and the other should be available as an option (via a parameter). Glyn Russell Butek/Austin/IBM@ To: axis-dev@xml.apache.org IBMUS cc: Subject: Re: deploy problem. would 11/03/02 15:26 notwork. Please respond to axis-dev OK, folks, what do y'all think? Since the session info ultimately resides in HTTPTransport, even though there are multiple services/stubs/Call objects, the cookie info is preserved. So if you turn on sessions, turn them off, and turn them back on again, you're still in the original session. Is this the proper behavior? Or should we get a new session each time we call setMaintainSession? Russell Butek butek@us.ibm.com Akira Hirose on 03/10/2002 07:49:13 PM Please respond to axis-dev@xml.apache.org To: axis-dev@xml.apache.org cc: Subject: Re: deploy problem. would notwork. Mr. Russell Butek, Thank you for your prompt reply. Although the behavior is bit different from I expected, but it worked fine. A new client program, and its result are attached below. Russell Butek wrote: > > It isn't sufficient to tell the server that the service is session scope. > The client must be aware of it as well. > > locator.setMaintainSession(true); > > Russell Butek > butek@us.ibm.com > The output of my test program. Third call block starts with 3, though I expected 1. So, it must be the same session of the first call block. test start (1): 1 (2): 2 test end test start (1): 1 (2): 1 test end test start (1): 3 (2): 4 test end test start (1): 5 (2): 6 test end /* Client.java */ package localhost; public class Test1 { private static void test(boolean maintainSession) { try { int i; LifeSpanTestServiceLocator locator = new LifeSpanTestServiceLocator(); locator.setMaintainSession(maintainSession); LifeSpanTest svc = locator.getLifeSpanTest(); System.out.println("test start"); System.out.println("(1): "+ String.valueOf(svc.getNext()) ); System.out.println("(2): "+ String.valueOf(svc.getNext()) ); System.out.println("test end"); } catch ( Exception e ) { System.err.print(e); } } public static void main(String [] args) throws Exception { test(true); test(false); test(true); test(true); } } /* akira.hirose */