Yes, there do seem to be some problems. At present each message is handled as a single sample which is added as a child of the parent sample result.
If the message is a multipart message, then this causes problems, because each part of a multi-part message has its own Content-Type, but of course a single result can only have one content-type. At present the result content-type is taken from the multipart container, which does not have an encoding, and anyway the content itself is assumed to be in the default encoding. Not ideal. Maybe multipart messages should be handled as one child per part? These would then become grandchildren of the original sample. If there is only a single part it could be stored as at present, but with the content-type taken from the part rather than the multi-part container. Does that sound reasonable? Any better ideas? On 15/02/2010, Noel O'Brien <[email protected]> wrote: > Using JMeter 2.3.4, there is more attachment related information and the > multi-part messages seem to be decoded once the "Store the message using > MIME" checkbox is ticked. There's still a UTF-8 issue though; > > • Subject sent: " Méðíá Sénd Téßþ " > • Subject received (not decoded): "MéðÃá Sénd Téßþ" > • Subject received (decoded): > "=?utf-8?B?TcOpw7DDrcOhIFPDqW5kIFTDqcOfw74=?=" > • Body sent: " Tesþ Bóð¥ " > • Body received (decoded): "Tes=C3=BE B=C3=B3=C3=B0=C2=A5=20" > > Regards, > Noel > > > ----- "Noel O'Brien" <[email protected]> wrote: > > Sure, I'll give it a go and report my findings > > > > Regards, > > Noel > > > > ----- "sebb" <[email protected]> wrote: > > > On 15/02/2010, Noel O'Brien <[email protected]> wrote: > > > > Apologies, forgot to attach the useful information ;) > > > > > > > > • OS: Ubuntu 9.10 (Linux olympia 2.6.31-19-generic-pae #56-Ubuntu SMP > Thu Jan 28 02:29:51 UTC 2010 i686 GNU/Linux) > > > > • Java: Sun version "1.6.0_18" > > > > • Javamail: 1.4.1 (mail.jar only) > > > > • JMeter: 2.3.2 r665936 > > > > > > Can you try JMeter 2.3.4? > > > There are a lot of fixes since 2.3.2. > > > > > > > • Sampler: Mail Reader Sampler > > > > > > > > > > > > • Server Type: IMAP > > > > • Server: <set correctly> > > > > • Username: <set correctly> > > > > • Password: <set correctly> > > > > • Folder: INBOX > > > > • Number of messages to retrieve: All > > > > • Delete messages from the server: false > > > > > > > > Regards, > > > > Noel > > > > > > > > > > > > ----- "sebb" <[email protected]> wrote: > > > > > On 15/02/2010, Noel O'Brien <[email protected]> wrote: > > > > > > Hi all, > > > > > > > > > > > > I've two questions regarding the mail sampler: > > > > > > > > > > > > 1. Is it possible to have JMeter decode multi-part messages? > > > > > > 2. Is it possible to have JMeter force UTF-8 encoding when > reading/displaying the mail > > > > > > > > > > Which version of JMeter and Javamail are you using? OS? > > > > > > > > > > Which sampler are you using? Which options? IMAP(S) ? POP3(S) ? > > > > > > > > > > > As part of my tests I'm using my product to send emails and using > JMeter to confirm that the emails arrive and contain the correct information. > However I've found that when I use UTF-8 characters in the mail subject, it > appears scrambled in JMeters View results tree listener and assertions > against the value fail. Using several mail clients (thunderbird, etc.), the > mail appears fine in terms of character encoding. Can JMeter handle UTF-8 > chars in emails? > > > > > > > > > > > > The emails I've sent have a message bady and attachment, though > when the mail is sampled in JMeter it shows up as: > > > > > > > > > > > > Multipart. Count: 2 Type: multipart/ALTERNATIVE; > boundary="----=_Part_60_10050345.1266233578389" > javax.mail.internet.mimemultip...@1852958 Type: IMAGE/JPEG; > name=6149b5b039ac499baeaf70a02d1d7a37.jpg > com.sun.mail.util.base64decoderstr...@15d585d > > > > > > I can assert on the attachment, but the message body is not > displayed. Is it possible for JMeter to decode multi-part message by, e.g. a > parameter? > > > > > > > > > > > > Regards, > > > > > > > > > > > > Noel > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > 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]
