Ошибка Sitecore 8.1: не найдены менеджеры идентификаторов сеансов для управления идентификатором сеанса для текущего запроса.

Я пытаюсь настроить и запустить базовый макет в Sitecore 8.1, и я столкнулся с ошибкой, о которой я могу найти очень мало информации. При попытке просмотреть любую страницу (даже внутренний интерфейс или подключение с Sitecore Rocks) я получаю сообщение «Не найдены менеджеры идентификаторов сеансов для управления идентификатором сеанса для текущего запроса».

Некоторые гуглы предполагают, что это связано с некоторыми проблемами со стандартным поставщиком сеансов, и рекомендуют заменить его для сохранения сеансов в Mongo. Документация Sitecore содержит описание этого как для общий и частный сессии. Я попытался реализовать их, но продолжаю получать ту же ошибку.

Вот мой код в его нынешнем виде:

App_Config/Include/MongoSessionProvider.config

<?xml version="1.0"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <tracking>
      <sharedSessionState>
        <providers>
          <clear/>
          <add name="mongo" type="Sitecore.SessionProvider.MongoDB.MongoSessionProvider, Sitecore.SessionProvider.MongoDB" connectionString="session" pollingInterval="2" compression="true" sessionType="shared"/>
        </providers>
      </sharedSessionState>
    </tracking>
  </sitecore>
</configuration>

App_Config/Include/ConnectionStrings.config (отрывок)

<add name="session" connectionString="mongodb://localhost/sharedsession" />

Web.config (отрывок)

<sessionState mode="Custom" cookieless="false" timeout="20" sessionIDManagerType="Sitecore.FXM.SessionManagement.ConditionalSessionIdManager" customProvider="mongo">
  <providers>
    <add name="mongo" type="Sitecore.SessionProvider.MongoDB.MongoSessionStateProvider, Sitecore.SessionProvider.MongoDB" sessionType="Standard" connectionStringName="session" pollingInterval="2" compression="true" />
    <add name="mssql" type="Sitecore.SessionProvider.Sql.SqlSessionStateProvider, Sitecore.SessionProvider.Sql" sessionType="Standard" connectionStringName="session" pollingInterval="2" compression="true" />
  </providers>
</sessionState>

Обратите внимание, что это на моей локальной машине разработки. У меня работает Mongo (и подтверждено его подключение к Sitecore), и я создал в нем базы данных сеанса и общего сеанса, используя use session и use sharedsession, что, как я понимаю, является способом создания БД в Mongo.

Я что-то упустил здесь? Или ошибка просто не означает то, что я думаю, что это означает?


person Michael Smith    schedule 10.12.2015    source источник


Ответы (2)


На случай, если это поможет кому-то еще, мы столкнулись с этой проблемой после обновления до Sitecore 8.1 rev. 151003.

В нашем конкретном случае проблема была связана с изменением пространства имен в этой строке в Web.config:

<sessionState mode="InProc" cookieless="false" timeout="20"
 sessionIDManagerType="Sitecore.FXM.SessionManagement.ConditionalSessionIdManager">

Это должно быть следующее:

<sessionState mode="InProc" cookieless="false" timeout="20"
 sessionIDManagerType="Sitecore.SessionManagement.ConditionalSessionIdManager">

Возможно, мы что-то упустили в руководстве по обновлению, но в конце концов нашли это, вытащив копию Sitecore 8.1 rev. 151003.zip на странице загрузок.

person James Skemp    schedule 20.04.2016

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

Почему обычно появляется это предупреждение

В Sitecore.config под <pipelines> определен конвейер getSessionIdManager.

<getSessionIdManager>
</getSessionIdManager>

В Sitecore.FXM.config для этого конвейера настроен процессор:

<getSessionIdManager>
  <processor type="Sitecore.FXM.Pipelines.ChooseSessionIdManager.FXMSessionIdManagerProcessor, Sitecore.FXM" />
</getSessionIdManager>

Этот конвейер позволяет динамически выбирать диспетчер идентификаторов сеансов для запроса. В конфигурации Sitecore по умолчанию нестандартный Session ID Manager будет использоваться только для запросов с явным параметром sessionId URL, т. е. только для запросов FXM.

Для всех остальных запросов диспетчер идентификаторов сеансов не будет явно выбран, и будет использоваться значение по умолчанию System.Web.SessionState.SessionIDManager; это отражено в предупреждающем сообщении, которое вы видите. В этой ситуации как таковой нет ничего плохого, это по умолчанию и по замыслу.

Просмотр сообщения как ошибки при каждом запросе страницы

Это определенно звучит как недостаток для меня. Предполагается, что это сообщение регистрируется один раз за время существования приложения, а не генерируется как исключение на каждой странице.

Вы должны сообщить об этом в службу поддержки Sitecore.

Попытка исправить

Я не могу отладить вашу систему, поэтому мне придется делать это с завязанными глазами. Я бы попытался создать вам собственный селектор Session ID Manager:

public class CustomSessionIdManagerProcessor
{
    public void Process(GetSessionIdManagerArgs args)
    {
        if(args.SessionIdManager == null)
        {
            args.SessionIdManager = new System.Web.SessionState.SessionIDManager();
        }
    }
}

Настройте его как последний процессор в конвейере getSessionIdManager. Это гарантирует, что всегда есть явно выбранный диспетчер идентификаторов сеансов, и, надеюсь, предотвратит возникновение ошибки.

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <pipelines>
      <getSessionIdManager>
        <processor type="YourNamespace.CustomSessionIdManagerProcessor, YourAssembly" />
      </getSessionIdManager>
    </pipelines>
  </sitecore>
</configuration>
person Dmytro Shevchenko    schedule 10.12.2015
comment
Это не предупреждение, это исключение, которое предотвращает рендеринг чего-либо (в частности, Sitecore.Exceptions.ProviderConfigurationException, если это вообще полезно). На самом деле он вообще не отображается в журналах, поэтому у меня так много проблем с его отслеживанием. Я попробую ваше временное исправление и сообщу. - person Michael Smith; 10.12.2015
comment
@MichaelSmith Я неправильно понял вас об ошибке. Пожалуйста, предоставьте скриншот или, что еще лучше, полную трассировку стека как часть вашего вопроса. Сообщение, которое вы видите, действительно должно быть предупреждением журнала и ничем иным: i.imgur.com/UH3W3yb.png - person Dmytro Shevchenko; 11.12.2015
comment
Я думаю, что мне удалось решить это, на самом деле. Я удалил sessionIDManagerType="Sitecore.FXM.SessionManagement.ConditionalSessionIdManager"[1] из узла sessionState в web.config, и ошибка исчезла. Однако сейчас у меня другая проблема[2], и я пытаюсь определить, не связана ли она или вызвана моим исправлением. [1] Я думаю, что поместил это туда, когда имел дело с более ранней проблемой, связанной с FXM. [2] В настоящее время ни у чего нет макета, даже у панели запуска. Все ищет макет со всеми нулями в качестве GUID, которого не существует. - person Michael Smith; 11.12.2015
comment
@MichaelSmith ха, да, ConditionalSessionIdManage‌r нельзя использовать ни с чем, кроме сеанса FXM. - person Dmytro Shevchenko; 11.12.2015
comment
@MichaelSmith, ваша вторая проблема не связана с конфигурацией вашего сеанса ... - person Dmytro Shevchenko; 11.12.2015
comment
Да, я полагаю, что, вероятно, нет, но я не решаюсь называть это исправленным, пока не узнаю наверняка, что происходит. - person Michael Smith; 11.12.2015
comment
@MichaelSmith, вы смогли решить проблему в конце концов? - person Dmytro Shevchenko; 16.12.2015
comment
Да, мы исправили. Как появится немного свободного времени, напишу подробности. Спасибо за проверку. - person Michael Smith; 18.12.2015
comment
@MichaelSmith Привет, Майкл, не могли бы вы поделиться своим решением, как вы его исправили. Большое спасибо - person Temaska; 30.12.2015
comment
@MichaelSmith Мне любопытно, написали ли вы еще о возможных деталях исправления? - person James Skemp; 19.04.2016
comment
@JamesSkemp Решение этой проблемы заключается в том, о чем я упоминал выше: удаление атрибута sessionIDManagerType из узла sessionState. Другой вопрос, который я собирался написать, не имел отношения к делу (и на данный момент я даже не помню его подробностей). Вероятно, мне следовало поместить это как отдельный ответ, чтобы я мог его принять, но ваш кажется более полным, поэтому вместо этого я воспользуюсь им. - person Michael Smith; 20.04.2016