Re: Hang in WOMailDelivery.sendEmail
Re: Hang in WOMailDelivery.sendEmail
- Subject: Re: Hang in WOMailDelivery.sendEmail
- From: Chuck Hill <email@hidden>
- Date: Wed, 21 Sep 2005 19:57:11 -0700
On Sep 21, 2005, at 5:16 PM, Allen Cronce wrote:
Thanks Chuck. Our timer based e-mail code is really simple and just
queues up strings to send during timer execution. There's no rendering
or EO fetches in the timer itself. So as long as WOMailDelivery
works in
a non-WOTimer, we should be OK, should we decide to move to java
timers
instead.
Yes.
The weird thing here is that our home brew e-mailer's been working
great
for two years. And it's only in the last couple of weeks that we've
been
seeing this problem. We're starting to suspect something is up with
our
main e-mail server and have switched our instances to point at a
reserved one for now.
I think are your correct in your suspicions, or in the direction of
them. It could also be a network error resulting in a dropped
connection that is not detected on the WOMailDelivery end. Not
really my area of expertise. But it is definately waiting for
something that is not happening:
[1] java.net.SocketInputStream.socketRead0 (native method)
[2] java.net.SocketInputStream.read (SocketInputStream.java:129)
[3] java.io.BufferedInputStream.fill
(BufferedInputStream.java: 183)
[4] java.io.BufferedInputStream.read
(BufferedInputStream.java: 201)
[5] sun.net.TransferProtocolClient.readServerResponse
(TransferProtocolClient.java:49)
Moving this to a java.util.Timer won't fix the underlying problem but
it will prevent your app from hanging.
As far as moving to ERJavaMail, I don't think that's going to be
faster
for us. Currently we don't use Project Wonder, so bringing it in and
reworking our code to use its emailer, updating our build to include
Project Wonder in the deployment installer, plus all the retesting
that
our QA department will require, is just a little too much to bite off
right now. I do want us to move to Project Wonder, but we'll have to
schedule it in for a later release.
Well, you don't need to drag in the entire Project Wonder. It is
only a couple of classes that you need and they are pretty easy to
rip out, not too much blood and gore dripping from them. But I do
understand your concerns. And it appears that the real problem that
needs effort applied lies elsewhere.
Chuck
Chuck Hill wrote:
WO calls out of the main thread or request/response loop that take
proper care to lock the necessary are just fine. I have several apps
that make use of threads running on a timer to EOF and WO things.
You won't have a session, you will need to create your own editing
context if you use one, and your own WOContext if you are using
component based mail. I don't foresee any problems.
All that said, I use a derivative of ERJavaMail for all of my mailing
functionality. You could probably switch quicker than you can get
what you have now working.
Chuck
On Sep 21, 2005, at 4:12 PM, Allen Cronce wrote:
Thanks for getting back to me Chuck. But is it safe to call
WOMailDelivery.sendEmail from another thread? I've found that more
often
than not, WO calls out of the main thread or request/response
loop lead
to "ahem", undefined behavior.
Best,
--
Allen Cronce
Chuck Hill wrote:
The first thing I would do is to use java.util.Timer and a separate
thread. That way, at least the app won't hang if the mail thread
stalls out waiting for a server response.
Chuck
On Sep 21, 2005, at 10:54 AM, Allen Cronce wrote:
Hi all,
We're trying to debug a hang that happens sporadically when
sending
e-mails. Currently we send e-mails using WOMailDelivery.sendEmail
from a
WOTimer in our application instance. This centralizes all e-mail
sends
for the application. In the future we'd like to use Project Wonder
ERJavaMail framework, but we can't do that short term.
The really weird thing is that the stack trace indicates that the
underlying socket code is waiting forever for data back from the
e- mail
server. I would have expected instead to see some sort of
threading
deadlock, but that doesn't seem to be the case. We control both
the
e-mail server and the application server but we can see no obvious
problem in any of our logs.
Here's the stack trace (note that I've edited out most of the
worker
threads since they're all the same):
--snip--
WorkerThread0:
[1] java.net.PlainSocketImpl.accept (PlainSocketImpl.java:351)
[2] java.net.ServerSocket.implAccept (ServerSocket.java:448)
[3] java.net.ServerSocket.accept (ServerSocket.java:419)
[4] com.webobjects.appserver._private.WOWorkerThread.run
(WOWorkerThread.java:238)
[5] java.lang.Thread.run (Thread.java:552)
Thread-0:
[1] java.lang.Thread.sleep (native method)
[2] com.webobjects.appserver.WOApplication$_LifebeatThread.run
(WOApplication.java:1,233)
Session Timeout Thread:
Current thread isn't suspended.
Signal Dispatcher:
Finalizer:
[1] java.lang.Object.wait (native method)
[2] java.lang.ref.ReferenceQueue.remove (ReferenceQueue.java:
111)
[3] java.lang.ref.ReferenceQueue.remove (ReferenceQueue.java:
127)
[4] java.lang.ref.Finalizer$FinalizerThread.run (Finalizer.java:
159)
Reference Handler:
[1] java.lang.Object.wait (native method)
[2] java.lang.Object.wait (Object.java:429)
[3] java.lang.ref.Reference$ReferenceHandler.run
(Reference.java: 115)
main:
[1] java.net.SocketInputStream.socketRead0 (native method)
[2] java.net.SocketInputStream.read (SocketInputStream.java:129)
[3] java.io.BufferedInputStream.fill
(BufferedInputStream.java: 183)
[4] java.io.BufferedInputStream.read
(BufferedInputStream.java: 201)
[5] sun.net.TransferProtocolClient.readServerResponse
(TransferProtocolClient.java:49)
[6] sun.net.smtp.SmtpClient.issueCommand (SmtpClient.java:46)
[7] sun.net.smtp.SmtpClient.openServer (SmtpClient.java:112)
[8] sun.net.smtp.SmtpClient.<init> (SmtpClient.java:135)
[9] com.webobjects.appserver.WOMailDelivery.sendEmail
(WOMailDelivery.java:201)
[10] com.paceap.ilok.Application.timer (Application.java:832)
[11] sun.reflect.GeneratedMethodAccessor12.invoke (null)
[12] sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
[13] java.lang.reflect.Method.invoke (Method.java:324)
[14] com.webobjects.foundation.NSSelector.invoke
(NSSelector.java:
354)
[15] com.webobjects.foundation.NSSelector.invoke
(NSSelector.java:
381)
[16] com.webobjects.appserver.WOTimer.fire (WOTimer.java:190)
[17] com.webobjects.appserver._WORunLoop._nextTimerInterval
(_WORunLoop.java:179)
[18] com.webobjects.appserver._WORunLoop._limitDate
(_WORunLoop.java:84)
[19] com.webobjects.appserver._WORunLoop.runBeforeDate
(_WORunLoop.java:63)
[20] com.webobjects.appserver.WOApplication._runOnce
(WOApplication.java:775)
[21] com.webobjects.appserver.WOApplication.run
(WOApplication.java:900)
[22] com.webobjects.appserver.WOApplication.main
(WOApplication.java:324)
[23] com.paceap.ilok.Application.main (Application.java:106)
[24] sun.reflect.NativeMethodAccessorImpl.invoke0 (native
method)
[25] sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
[26] sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
[27] java.lang.reflect.Method.invoke (Method.java:324)
[28] com.webobjects._bootstrap.WOBootstrap.main
(WOBootstrap.java: 71)
--snip--
Any ideas as to how to resolve this would be much appreciated.
Best regards,
--
Allen Cronce
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40global-village.net
This email sent to email@hidden
--
Coming in 2006 - an introduction to web applications using WebObjects
and Xcode http://www.global-village.net/wointro
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden