In order to simulate most modern client, it would be useful to have options in the sampler to: a- read only the headers (inside a mailbox); b- read only the last (i.e. most recent) N headers; c- read a specific message (using an index returned from previous call; Using feature b- I could iterate calling feature c-. TIA
a) The code already fetches the header separately from the body, so it should be easy enough to suppress fetching the body. Just means adding an option checkbox to the GUI. b) The code already has the option to fetch N messages - does this not work for you? Or does it fetch the earliest N messages? c) That should be easy enough to do. One possible approach to providing the message ids via the GUI: The number field currently expects a positive number. This could be extended to support a negative number, meaning to count back from the highest numbered message. So if there are 100 messges in the folder: 10 would mean msgs 1-10 (same for +10) -10 would mean msgs 91-100 In both cases, the sampler would return 10 messages, i.e. the absolute value of the number. [This would support option (b) if it does not already] One possible way to indicate a single message number would be to prefix the number with '=', for example: =42 This would avoid needing to change the GUI, and personally I would find it easier to use than having to enter the numbers in a different field or select an additional check-box. But others may think otherwise!
a) using a checkbox to avoid downloading the bodies seems ok for me. b) yes, at the time being, when you set the interface to download N messages it downloads the oldest ones. The point is, we need a way to know how many messages there are in the mailbox: what happens if I try to download 10 messages, but only 5 are present? I think we need an optional field with the name of the variable where to put this info. c) the solutions you are proposing work well for me. The actual case I'm thinking of is where I am simulating a user reading his mail. Every time one logs on, he downloads only the new messages, which can be done if one knows how many messages there were previously (with some simple math).
(In reply to sergio from comment #2) > a) using a checkbox to avoid downloading the bodies seems ok for me. OK > b) yes, at the time being, when you set the interface to download N messages > it downloads the oldest ones. > The point is, we need a way to know how many messages there are in the > mailbox: > what happens if I try to download 10 messages, but only 5 are present? It will only download 5. > I think we need an optional field with the name of the variable where to put > this info. Sorry, put what info? > c) the solutions you are proposing work well for me. > The actual case I'm thinking of is where I am simulating a user reading his > mail. > Every time one logs on, he downloads only the new messages, which can be > done if one knows how many messages there were previously (with some simple > math). Assuming no messages are removed in the meantime... I think MUAs normally use some kind of UID to keep track of the last message they read, but I'm not sure this is supported fully by JavaMail for all server types.
(In reply to Sebb from comment #3) > (In reply to sergio from comment #2) > > a) using a checkbox to avoid downloading the bodies seems ok for me. > > OK > > > b) yes, at the time being, when you set the interface to download N messages > > it downloads the oldest ones. > > The point is, we need a way to know how many messages there are in the > > mailbox: > > what happens if I try to download 10 messages, but only 5 are present? > > It will only download 5. > > > I think we need an optional field with the name of the variable where to put > > this info. > > Sorry, put what info? I meaned, the number of messages present i the mailbox. > > > c) the solutions you are proposing work well for me. > > The actual case I'm thinking of is where I am simulating a user reading his > > mail. > > Every time one logs on, he downloads only the new messages, which can be > > done if one knows how many messages there were previously (with some simple > > math). > > Assuming no messages are removed in the meantime... yes, but, for the test purpose, I can safely assume that only one user at a time actually accesses the maibox. I think that these features can simulate the behaviour of most MUA, for the load testing purpose. However I will go deeper into IMAP features in the next few days...
(In reply to sergio from comment #4) > (In reply to Sebb from comment #3) > > (In reply to sergio from comment #2) ... > > > I think we need an optional field with the name of the variable where to put > > > this info. > > > > Sorry, put what info? > I meaned, the number of messages present i the mailbox. > You mean that if a variable name is provided, then the sampler will store the total message count in it?
(In reply to Sebb from comment #5) > (In reply to sergio from comment #4) > > (In reply to Sebb from comment #3) > > > (In reply to sergio from comment #2) > ... > > > > I think we need an optional field with the name of the variable where to put > > > > this info. > > > > > > Sorry, put what info? > > I meaned, the number of messages present i the mailbox. > > > > You mean that if a variable name is provided, then the sampler will store > the total message count in it? yes
The code currently uses -1 to mean all messages, so cannot use -N to mean starting from the end, and compatibility concerns mean that the value -1 cannot ever be changed. However, the value is stored as text, so a different prefix could be used, for exampe '~' or '!' or '_'.
Implemented part a) URL: http://svn.apache.org/r1588596 Log: MailReaderSampler enhancement: read message header only Bugzilla Id: 56427 Modified: jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties jmeter/trunk/src/protocol/mail/org/apache/jmeter/protocol/mail/sampler/MailReaderSampler.java jmeter/trunk/src/protocol/mail/org/apache/jmeter/protocol/mail/sampler/gui/MailReaderSamplerGui.java jmeter/trunk/xdocs/changes.xml jmeter/trunk/xdocs/usermanual/component_reference.xml
Hi, I tested new flag on night build r1592138. It works properly. Given the way statistics are produced, probably option c) is the most flexible, as it allows to get detailed info on each message. As timings are strongly related to message size, a single sample averaging multiple operations is not meaningful.
(In reply to Sebb from comment #7) > The code currently uses -1 to mean all messages, so cannot use -N to mean > starting from the end, and compatibility concerns mean that the value -1 > cannot ever be changed. > > However, the value is stored as text, so a different prefix could be used, > for exampe '~' or '!' or '_'. coming back again on the issue... What about putting on the UI a flag that selects "earliest" or "most recent" messages. This way, we do not break compatibility, and it should be easy to implement. Another alternative would be to allow the message number in the form: m,n This would mean: read from message m upto n (both included, starting from 1, 1 is the oldest). This is more powerful, but more complex to test (lot of marginal conditions). Also, in the end, you will need to know the number of messages in the mailbox. Let me know.
I had no feedback on this thread. I checked on several night build and the "read message header only" works properly, so the single object of this enhancement is satisfied. I'm going to create a new enhancement request for a flag thats allows to download most recent file (at the time being it downloads the oldest ones).
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/3361