Getting UID of deleted message
Asked Answered
D

3

6

I have an IMAPFolder with MessageCountListener that listens to messages being added / removed from the folder. Inside my messageRemoved(MessageCountEvent ...) I need to get the UID of the message that was just removed so that I can reflect those changes in my local cache.

The issue is that if i try to execute IMAPFolder.getUID(Message ...) on a deleted message I get

    javax.mail.MessageRemovedException
        at com.sun.mail.imap.IMAPMessage.checkExpunged(IMAPMessage.java:220)
        at com.sun.mail.imap.IMAPFolder.getUID(IMAPFolder.java:1949)
        at (...).IdleWatcher$1.messagesRemoved(IdleWatcher.java:64)
        at javax.mail.event.MessageCountEvent.dispatch(MessageCountEvent.java:152)
        at javax.mail.EventQueue.run(EventQueue.java:134)
        at java.lang.Thread.run(Thread.java:856)

How can I determine the UID of the deleted message? I could go through all cached messages and check which ones still exist, however this is too resource intensive to be doing each time a message is deleted.

Disjoint answered 19/12, 2014 at 11:48 Comment(0)
A
2

You cannot get the UID of something after it has been deleted. Deleting is deleting.

The classic way to solve this is to use the UID as cache key and design your program so you can cache deleted messages for a while without ill effect. For instance, if you want to display unseen mail, ask the server what's unseen right now, then ask your cache for those messages.

Amphiarthrosis answered 19/12, 2014 at 12:18 Comment(0)
C
2

If you prefetch the UIDs for all messages (using the Folder.fetch method) you should be able to get the UID of a message using the Folder.getUID(Message) after it's been deleted/expunged.

Carangid answered 19/12, 2014 at 20:27 Comment(4)
I have similar issue. I have prefetched all messages. But in MessageCountListener.messagesRemoved come MessageCountEvent from separate thread ("JavaMail-EventQueue") and message have no UID but expunged flag set. How @İlker-korkut said, it is documented behaviour. By what I should search that message in cache? As also stated there only Message.getMessageNumber(), but doc also state it is not stable on messages add/removal. So, it mean there are no robust way understand what exactly message(s) deleted??Compressibility
Message numbers are stable while the folder is open, unless you call the expunge method. If you're caching information while the folder is open, message number should be enough. If you're caching information when the folder is not open, you'll want to keep track of the message UID, which means you'll probably want to fetch the UID for the messages when you open the folder. If you prefetch the UID, you can access it when you get the messagesRemoved event.Carangid
Again, I call expunge method! And get several messageRemoved events, but can't then distinguish what exactly message removed. And I also stated what messages fetched, I have UID and all headers, but message in event come sometimes fully uninitialised!Compressibility
The message numbers in the messageRemoved event should be the message numbers from before your call to expunge. If you think you're prefetching the UIDs for all messages, but the messages in the messageRemoved event can't find their UIDs, I would need to see more details (e.g., the protocol trace). One way this can happen is if a new message arrives, you haven't fetched the UID for it yet, and then it's expunged. If you want more help, contact me at [email protected].Carangid
H
1

Here is IMAPFolder source code. You can see what is happening in getUID method.

API Doc says :

The exception thrown when an invalid method is invoked on an expunged Message. The only valid methods on an expunged Message are isExpunged() and getMessageNumber().

I think you should cache messages UID while deletion in your MessageCounterListener may be, after when you need , you will be able to chech and get UID.

Hillel answered 19/12, 2014 at 12:30 Comment(1)
By what attribute you are suggest search that mail in cache? (please read my comment to previous message)Compressibility

© 2022 - 2024 — McMap. All rights reserved.