Проблема с JavaMail и Exchange Server 2007 — ПЛОХОЙ аргумент команды

В приложении, над которым я работаю, есть функция, которая подключается к почтовому серверу через IMAP с помощью JavaMail. У одного из наших клиентов была следующая трассировка стека:

javax.mail.MessagingException: A13 BAD Command Argument Error. 11; 
nested exception is: 
com.sun.mail.iap.BadCommandException: A13 BAD Command Argument Error. 11 
at com.sun.mail.imap.IMAPMessage.setFlags(IMAPMessage.java:847) 
at javax.mail.Message.setFlag(Message.java:565) ...

Теперь то, что он пытался сделать, это следующее:

messages[i].setFlag(Flags.Flag.RECENT, false);

Где messages[i] это javax.mail.Message.

Эта ошибка никогда не возникала ни у одного из наших клиентов, использующих Exchange Server 2003, и, поскольку этот клиент использует Exchange Server 2007, я предполагаю, что это как-то связано с этим (ошибка?). Я также убедился, что они обновили его до последнего пакета обновления и накопительного обновления (пакет обновления 1, обновление 8 на момент написания этой статьи) и последней версии JavaMail (1.4.2 на момент написания этой статьи), и это не повлияло. Мой вопрос в том, что мне нужно ждать, пока Microsoft исправит? Есть ли обходной путь, который я могу использовать?

Для справки, причина, по которой я устанавливаю для последнего флага значение false, заключается в том, что данное сообщение не будет обрабатываться снова во втором проходе (т. е. оно обрабатывает только последние или новые сообщения).


person Avrom    schedule 26.06.2009    source источник


Ответы (1)


Мое прочтение API для Flags.Flag. RECENT указывает, что он доступен только для чтения из клиентского приложения. Реализация папки должна установить его, когда «сообщение является новым для этой папки». Поэтому, если вы не пишете реализацию папки, вам не следует изменять этот флаг.

Это заставляет задуматься, почему другие ваши клиенты не получают ошибку. Возможно, в некоторых случаях это рассматривается как NOOP? Возможно, есть что-то особенное в папке этого конкретного клиента? Возможно, общая папка или папка, к которой у пользователя тоже есть доступ для чтения? Я не готов размышлять о тайнах хранилища сообщений Exchange.

person Dave Smith    schedule 30.06.2009
comment
У одного другого клиента на Exchange Server 2007 была такая же проблема. Они самостоятельно решили проблему, удалив и воссоздав почтовый ящик, и списали это на проблему обновления с 2003 по 2007 год. Этот другой клиент все еще имеет проблему, несмотря на воссоздание почтового ящика. Ни один клиент, в настоящее время использующий 2003, еще не жаловался. - person Avrom; 01.07.2009
comment
Если я правильно понимаю Javadocs, на которые вы указали, если я правильно закрою почтовую папку, а затем снова открою ее позже, флаг последних должен быть отключен для всех сообщений, которые были там в предыдущий раз, когда она была открыта. Если да, то это должно удовлетворить мои потребности. - person Avrom; 01.07.2009
comment
@Avrom: Я так понимаю. При закрытии и повторном открытии все новые сообщения должны быть отмечены как ПОСЛЕДНИЕ. Но только ли ваше приложение имеет доступ к папкам? Если нет, я подозреваю, что у вас возникнут проблемы, если какое-либо другое приложение откроет/закроет папку. Я сомневаюсь, что Exchange (или любой другой сервер IMAP) сохранит флаг ПОСЛЕДНИЕ только для вашего приложения. Если для вашего приложения важно знать, какие сообщения оно обрабатывает, вам, вероятно, придется установить пользовательский флаг для сообщений. - person Dave Smith; 01.07.2009
comment
Это должно быть единственное приложение, которое имеет доступ к этому конкретному почтовому ящику, и если нет, мы подчеркиваем нашим клиентам, что это может быть проблемой. (Другими словами, мы рекомендуем выделить для этого процесса отдельный почтовый ящик.) - person Avrom; 02.07.2009