Transport.send hangs indefnitely
2 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   Mark_Wrynn
Posted On:   Tuesday, July 12, 2005 04:26 PM

Using JavaMail I have made a method which sends an email with an attachment. A URL is passed to the method as a parameter, which indicates where to find the attachment. So, if you pass it the URL "http://www.mywebsite.com/doc.pdf", then doc.pdf will be downloaded and attached to the email that goes out. I run into problems when the specified URL is a particular JSP which dynamically generates a PDF. Not all PDFs, mind you, cause a problem. In most cases, the PDF is retrieved and mailed out as expected. However if the generated PDF exceeds a certain size - and so it takes a few minutes to generate - the Transport.send(message) call hangs indefinitely. The interesting part is that this problem only occurs when t   More>>

Using JavaMail I have made a method which sends an email with an attachment. A URL is passed to the method as a parameter, which indicates where to find the attachment. So, if you pass it the URL "http://www.mywebsite.com/doc.pdf", then doc.pdf will be downloaded and attached to the email that goes out.



I run into problems when the specified URL is a particular JSP which dynamically generates a PDF. Not all PDFs, mind you, cause a problem. In most cases, the PDF is retrieved and mailed out as expected. However if the generated PDF exceeds a certain size - and so it takes a few minutes to generate - the Transport.send(message) call hangs indefinitely.



The interesting part is that this problem only occurs when the JSP contains the directive <%@ page isThreadSafe="false" %> (this serializes all requests for the page). If I set this directive to true, the method works just fine. (Unfortunately I can't leave the directive set to true for other reasons.) I am making sure that there is no other access to the JSP going on - only my test program is calling it. Therefore, it seems to me that this method is somehow accessing the JSP twice, but only when the generated PDF is big.



To reiterate, my tests indicate that the retrieving/mailing of the PDF works as expected when:

- the URL indicates a static PDF (or any other type of file), regardless of size

- the PDF-generating JSP - having isThreadSafe set to true - is called, regardless of the generated PDF's size.

- the PDF-generating JSP - having isThreadSafe set to false - is called, and the generated PDF is small (or it doesn't take too much time to generate - not sure which is the exact issue - but it is true that PDF size directly relates to time to generate)



My tests indicate that the method hangs on Transport.send(message) when:

- the PDF-generating JSP - having isThreadSafe set to false - is called, and the generated PDF is big (or it takes too long to generate)



I'm rather puzzled. Below you'll find a snippet of the method containing only the relevant lines of code. If anyone has any pointers or suggestions, I would love to hear them.



Thanks,

Mark

			
Properties props = new Properties();
props.put("mail.smtp.host", emailIP);
Session session = Session.getInstance(props);

MimeMessage message = new MimeMessage(session);
InternetAddress iaFrom = new InternetAddress(from);
message.setFrom(iaFrom);
InternetAddress iaTo = new InternetAddress(to);
message.setSubject(subject);
message.setSentDate(new Date());
// Create the body text
Multipart multipart = new MimeMultipart();
MimeBodyPart mainBodyPart = new MimeBodyPart();
if (body == null) {
mainBodyPart.setText(" ");
}
else {
mainBodyPart.setText(body);
}
// Part two is attachment
URL url = new URL(attachmentUrl);
BodyPart attachmentBodyPart = new MimeBodyPart();

DataSource source = new URLDataSource(url);
message.addRecipient(Message.RecipientType.TO, iaTo);
multipart.addBodyPart(mainBodyPart);
attachmentBodyPart.setDataHandler(new DataHandler(source));
attachmentBodyPart.setFileName(attachmentName);
multipart.addBodyPart(attachmentBodyPart);

message.setContent(multipart);

Transport.send(message);
   <<Less

Re: Transport.send hangs indefnitely

Posted By:   Mark_Wrynn  
Posted On:   Friday, July 22, 2005 01:54 PM

The verdict: It seems there is a problem with either URLDataSource or JavaMail.



One of these classes wants to "GET" request the URL three times for every call to Transport.send. I verified this through my application server logs. For this particular non-threadsafe JSP, the logs show that while Transport.send is hanging, only the first JSP request ever runs. If the URL points to any other (threadsafe) JSP, the logs show that it gets requested three times.



So, after replacing URLDataSource with another class which implements DataSource, my problem is solved.



Below is the retrieveData method of the implementing class. Note that at the very beginning, if data is not null the method just returns out. This means that if called multiple times, only the data retrieved from the first request will be used. The data is effectively cached. Why three requests are made I do not understand, so for my purposes, forbidding more than one request to the JSP solves the problem.




private void retrieveData() throws IOException {
if (data != null)
return;
URLConnection connection = url.openConnection();
connection.setAllowUserInteraction(false);
connection.setDoInput(true);
connection.setDoOutput(false);
//connection.setIfModifiedSince(false);
connection.setUseCaches(false);
connection.connect();

contentType = connection.getContentType();
int contentLength = connection.getContentLength();
if(contentLength == -1) contentLength = 2048;
InputStream in = connection.getInputStream();
ByteArrayOutputStream out = new ByteArrayOutputStream(contentLength);
byte buff[] = new byte[BUFF_SIZE];
int count;
while((count=in.read(buff)) >= 0)
out.write(buff, 0, count);
data = out.toByteArray();
}



If anyone has any insight as to why three requests are made, I'd love to hear it.



Thanks,

Mark

Re: Transport.send hangs indefnitely

Posted By:   Mark_Wrynn  
Posted On:   Wednesday, July 13, 2005 04:54 PM

New information:



After doing some debugging, it turns out that only one request to the JSP is made when the problem occurs.
About | Sitemap | Contact