I believe the default session scope in axis2 for the server side is "request" and that might explain why so many sessions are being created. Also I believe the notification producer uses axis2 to send the messages out to the notification consumer in effect using an axis2 based "client". In this case, if the same stub is not used everytime axis2 will create a separate session for that.
So the answer might be, 1) explicitly specify the soapsession or application scope for the muse services in services.xml 2) Muse could hold on to the client used to send the message. It will have to use a separate client for each consumer though. Balan Subramanian Autonomic Computing, IBM, RTP, NC 919.543.0197 | [EMAIL PROTECTED] Daniel Jemiolo/Durham/[EMAIL PROTECTED] 04/11/2007 02:57 PM Please respond to [email protected] To [email protected] cc Subject RE: Too many sessions To me that implies the problem is related to Axis2, since the only difference between your two sets of applications would be the code that takes the SOAP envelope and passes it to Muse's resource router (one uses Axis2 APIs to do the task, the other doesn't - either way, we're just loading a DOM tree). Perhaps Axis2 enables some kind of session activity? Have you tried configuring sessions at a Tomcat level (or whatever you're using)? Dan "Callner, David A." <[EMAIL PROTECTED]> wrote on 04/11/2007 02:51:18 PM: > I found one way around this by creating my same producer/consumer as a > mini instead of an axis2. Could this possibly be a bug with Muse? > > -----Original Message----- > From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 11, 2007 11:20 AM > To: [email protected] > Subject: RE: Too many sessions > > Muse doesn't use sessions in any way, but the servlet container > (Tomcat, > etc.) it runs in is configured to make a new session for each new > client > that contacts it. I'm assuming that because your client (the producer) > is > not keeping any session/cookie data (like a browser might), the servlet > > container is treating each request (wsnt:Notify) like it's coming from > a > new client. > > Dan > > > "Callner, David A." <[EMAIL PROTECTED]> wrote on 04/11/2007 11:11:04 > AM: > > > Thanks, but why is Muse creating a session for every > > publish(_TOPIC_NAME, element); call or who is creating the session? > > I'm completely confused by this. I only deploy a publisher and a > > consumer so why would many sessions be created on the Consumer end to > > receive the publishes? > > > > -----Original Message----- > > From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, April 11, 2007 10:36 AM > > To: [email protected] > > Subject: Re: Too many sessions > > > > If you're running Muse as a J2EE app, the answer lies in the > > configuration > > of your HTTP/J2EE container. If that's Tomcat, I think the > > maxActiveSessions parameter can be used to limit the number of > sessions > > > > created: > > > > http://ontoweb.med.yale.edu/tomcat-docs/monitoring.html > > > > I'm not entirely sure about this - shutting off sessions is > > well-documented for JSPs, but for servlets (SOAP engines) it was a > > little > > harder to find. > > > > Dan > > > > > > > > "Callner, David A." <[EMAIL PROTECTED]> wrote on 04/11/2007 09:54:57 > > AM: > > > > > I'm using the WSN-Notification and every time do a publish a > session > > is > > > created in the Consumer. I'm sending thousands of messages. How > can > > I > > > create just one Consumer session to handle all the publishes? > > > > > > Thanks, > > > > > > David Callner > > > Senior Software Systems Engineer > > > The MITRE Corporation > > > Center for Advanced Aviation System Development > > > 7515 Colshire Dr. > > > McLean, VA. 22102 > > > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > > 703.983.6431 (work) > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
