Расследование первопричины, лежащей в основе «запроса, не найденного в TrackedRequests»

Question

В нашей системе отслеживания ошибок существует давняя проблема, связанная с ужасающим сообщением " ОШИБКА: запрос не найден в TrackedRequests. Возможно, мы создаем и закрываем веб-страницы в разных потоках. " в журнале трассировки SharePoint .

Поскольку мы разрабатываем Программное обеспечение для рабочих процессов для рынка SharePoint, мы время от времени изучаем эту проблему, чтобы убедиться, что она не вызвана нашими продуктами. Я лично пришел к выводу, что это проблема в SharePoint, но, возможно, кто-то еще может доказать, что я не прав.

Вот что я знаю:

1. Согласно сотням результатов поиска, возвращаемых Google по этой теме, эта проблема, по-видимому, в основном связана с рабочими процессами SharePoint, как на основе SharePoint Designer, так и на основе Visual Studio.

2. Если для ведения журнала ULS установлено значение Monitorable, самый простой способ воспроизвести эту проблему - создать новый рабочий процесс SharePoint Designer, присоединить его к библиотеке документов, установить автоматический запуск при добавлении / обновлении, но не добавьте любые действия, сохраните рабочий процесс и загрузите файл в библиотеку документов.

3. Ошибка видна только в журнале трассировки SharePoint, она не влияет на выполнение рабочего процесса под рукой.

4. Я подтвердил, что проблема возникает в 32-разрядных и 64-разрядных системах, Win2K3 и 2K8, WSS и MOSS с версиями SharePoint вплоть до Декабрь 2009 г. Накопительное обновление (6524).

5. Проблема не возникает при ручном запуске рабочего процесса.

6. На форумах MSDN имеется десятков связанных сообщений, сотен в Google, один в StackOverflow и ни одного в SharePoint Overflow. Там, кажется, нет ответа.

Кто-нибудь имеет представление о том, что происходит, что вызывает это, и если мы должны беспокоиться или подать это под ' Red Herrings '.

Обновление: Microsoft подтвердила, что это известная проблема, которую можно безопасно игнорировать. Это не будет исправлено в SP2007, но больше не является проблемой в SP2010.

Answer 1

Когда я смотрю на stacktrace (я предполагаю, что человек, отправивший это сообщение, ссылается на ту же ошибку), он выглядит как получатель события OOTB (Microsoft.SharePoint.Workflow.SPWorkflowAutostartEventReceiver) отвечающий за автозапуск рабочих процессов, использует SPSite, который, возможно, не был создан кодом получателя события.

К сожалению, метод AutoStartWorkflow () запутан, поэтому я не вижу в Reflector, какой SPSite находится в распоряжении. Вы можете поэкспериментировать с написанием своего собственного EventReceiver, который располагает любым существующим SPSite, который он может получить в свои руки, и посмотреть, не приводит ли это к регистрации той же ошибки.

Answer 2

Подайте его под Red Herrings. Вы говорите: «Ошибка видна только в журнале трассировки SharePoint, она не влияет на выполнение рабочего процесса под рукой». В журнале ULS зарегистрировано так много ошибок, которые находятся вне нашего контроля и не оказывают непосредственного влияния на нашу среду. Если вы хотите улучшить продукт, вы можете попробовать обратиться в службу поддержки, которая может быть увеличена как ошибка. Однако что, если это не ошибка, а подробное сообщение журнала ULS?

На самом деле, это многословие не ограничивается только журналами ULS. Вы видели пакет управления Microsoft Office SharePoint Server 2007 для System Center Operations Manager 2007 ? Он отфильтровывает шумовые события из журналов событий на вашей ферме, чтобы вы могли сосредоточиться на событиях, обозначающих реальную проблему.

Answer 3

Это действительно хороший вопрос, и я жажду увидеть хорошие ответы на это. Я видел эту ошибку в моих рабочих процессах в самых разных контекстах.

Например, в моем случае это происходит в домашней выпечке, когда я ловлю событие «задача создана» и пытаюсь «прервать наследование» SPListItem (новая задача).

Мое пользовательское действие получает контекст рабочего процесса через свойство wfActProps, которое имеет тип SPWorkflowActivationProperties. Затем я обычно использую wfActProps.Web для доступа к веб-объекту.

Первая мысль, которая у меня возникла, - возможно, это плохой тон для передачи SPWorkflowActivationProperties между различными действиями, однако я пока не нашел другого пути.

Я настраиваю "сообщество вики" на мой ответ, поскольку это не фактический ответ, а пример ситуации, когда эта ошибка может быть замечена.