Serge, thanks for your comments! I think you're right about the McAfee; we do expect it to be bad news on the performance side, and I too think that in these tests Windows SMTP is not showing problems because there is a lot of CPU % available. We have tested without logging, and it did not make any real difference. I have asked the test department to run the tests suggested, with the latest release and the dbfile spool. The size of messages is a real problem. The release of the product I'm working on will routinely send voice mails, and those of course tend to be pretty big. The small, text messages will be just a small percentage of the traffic we'll need to handle. The CPU is a problem as well. If we want to run James on servers that run our sw, and not only on dedicated servers, then we cannot afford it to consume so much CPU. I am a Java newbie, and I'd be grateful if one of you guys could give me an idea about what part of the JVM/runtime/james you think is responsible, and if this is kind of expected of such a framework. As for the exception, if you can view a Windows Word doc I can send you a very detailed doc about these tests, with more info about results and configuration. Also, if there is any specific info you'd like me to collect, let me know what and how and I'll see what I can do.
> -----Original Message----- > From: Serge Knystautas [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 03, 2003 2:51 PM > To: James Users List > Subject: Re: James load test causes several exceptions > > > Paola, > > Noel already addressed each point, but just to highlight the two > quickest things are to leave debugging at error and to upgrade to the > latest 2.2 release. I would bet (hope) that James would be > faster than > Windows SMTP server on the smaller messages, though would > probably still > consume more CPU. > > I'm a bit suspicious about McAfee not slowing down the throughput for > Windows SMTP. I guess since there is available CPU, it means > McAfee can > crunch as much as possible without affecting SMTP throughput. > However, > usually the forking and checking for viruses/spam will increase the > processing time. > > One note below... > > Bungaro, Paola wrote: > > First the errors. We enabled DEBUG logging; note that for > each of the following errors, the frequency of errors > increased with traffic. Here are some examples: > > - In mailet log: > > Could not connect to SMTP host: > jdccisco-000003.ecsbu-lab-sea.cisco.com, port: 25; > > nested exception is: > > java.net.BindException: Address already in use: connect > > at > com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:911) > > at > com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport. > java:158) > > at javax.mail.Service.connect(Service.java:233) > > at javax.mail.Service.connect(Service.java:134) > > at javax.mail.Service.connect(Service.java:86) > > at > com.sun.mail.smtp.SMTPTransport.connect(SMTPTransport.java:95) > > at > org.apache.james.transport.mailets.RemoteDelivery.deliver(Remo > teDelivery.java:305) > > at > org.apache.james.transport.mailets.RemoteDelivery.run(RemoteDe > livery.java:758) > > at java.lang.Thread.run(Unknown Source) > > I've never seen this error before. Any further information > about this > would be very appreciated. > > -- > Serge Knystautas > President > Lokitech >> software . strategy . design >> http://www.lokitech.com > p. 301.656.5501 > e. [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]
