Обнаруженные дубликаты FlexSessions на основе HTTP, как правило, из-за того, что удаленный хост отключил файлы cookie сеанса
описание сцены: моя программа реализована с помощью flex+java+blazeDS+activeMQ, она подписывает сообщение jms от activeMQ от Flex Consumer, в настоящее время я поставляю два томата на одном сервере, все они содержат мою программу, а ActiveMQ находится в другом сервер, теперь я открываю два приложения в одном и том же браузере, например, IE или Chrome, что угодно, URL-адрес, такой как http: // localhost:8080/HelloWord/index.html, http: // localhost:8181/ HelloWord / index.html
Проблема: URL первого приложения http: // localhost:8080/HelloWord/index.html, я открываю его в ie, и он может очень хорошо подписаться на сообщение, но когда я открываю второе второе приложение, URL которого http: // localhost: 8181 /HelloWord/index.html, т. е. происходит авария, два приложения не могут подписать сообщение.
журнал ошибок:1.flex клиентский журнал (flash.log):обнаружены дубликаты FlexSessions на основе HTTP, как правило, из-за того, что удаленный хост отключил файлы cookie сеанса. Сеансовые куки должны быть включены для правильного управления клиентским соединением. 2.java консольный журнал: flex.messaging.client.FlexClientNotSubscribeedException: у клиента нет активных подписок через конечную точку my-polling-amf. по адресу flex.messaging.client.FlexClient.throwNotSubscribeedException(FlexClient.java:1789) по адресу flex.messaging.client.FlexClient.pollWithWait(FlexClient.java:967) по адресу flex.messaging.endpoints.BasePollingHlift.PlayEntPleE) в flex.messaging.endpoints.AbstractEndpoint.handleFlexClientPollCommand(AbstractEndpoint.java:1151) в flex.messaging.endpoints.AbstractEndpoint.serviceMessage(AbstractEndpoint.java:965) в flex.messaging.endpoints.y00.B0B.EB invoke() в net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:191) в org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2ava.op.as.op.fo.69.pro.pro.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) в org.springframework.flex.core.MessageInterceptionAdvice.invoke(MessageInterceptionAdvice.java:66) в org.springframework.aop.finme iveMethodInvocation.java:172) в org.springframework.aop.framework.adapter.ThrowsAdviceInterceptor.invoke(ThrowsAdviceInterceptor.java:124) в org.springframework.aop.framework.ReflectiveMethod.aop.framework.Cglib2AopProxy$FixedChainStaticTargetInterceptor.intercept(Cglib2AopProxy.java:576) по адресу flex.messaging.endpoints.AMFEndpoint$$EnhancerByCGLIB$$3ae4b8ad.serviceMndagekerBerMekerFBF Java:103) на flex.messaging.endpoints.amf.LegacyFilter.invoke(LegacyFilter.java:158) на flex.messaging.endpoints.amf.SessionFilter.invoke(SessionFilter.java:44) на flex.messaging.endpoints.amf.BatchProcessFilter.invoke(BatchProcessFilter.java:67) в flex.messaging.endpoints.amf.SerializationFilter.invoke(SerializationFilter.java:166) в flex.messaging.endpoints.BaseHTTPEndpoint.service(BaseHTTPEndpoint.j). messaging.endpoints.AMFEndpoint $$ EnhancerBy CGLIB $$ 3ae4b8ad..web.servlet.DispatcherServlet.doService(DispatcherServlet.java:716) в org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:647) в org.springframework.web.servletvralet:563) в javax.servlet.http.HttpServlet.service(HttpServlet.java:641) в javax.servlet.http.HttpServlet.service(HttpServlet.java:722) в org.apache.catalina.core.FilinFilter ApplicationFilterChain.java:304) по адресу org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) по адресу org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.cat.ina.at2: orina2.cat.at.core.StandardContextValve.invoke(StandardContextValve.java:164) в организации.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462) в org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) в org.apache.catalina.valve.Revein.Revein.Reve.Error.java:100) в org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563) в org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) в org.apache.cat Connector.CoyoteAdapter.service(CoyoteAdapter.java:403) в org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:286) в org.apache.coyote.http11.Http11AprProTPHHPHT 272) в org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:1730) в java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) в java.util.cun.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
тест, который я сделал: 1.FlexClient.getInstance (). id = UIDUtil.createUID (); неверный 2.FlexClient.getInstance().id = null; неверно 3. использовать разные типы браузеров, один использовать Ie, другой использовать Chrome, чтобы открыть два приложения, они в порядке; 4. один сервер один кот, используйте тот же вид браузера, т.е. чтобы открыть их, они в порядке; 5. использовать пользовательский AMFChannel в flex MXML или определение AMFChannel по умолчанию в flex-config.xml, недействительно;
успехидрузей в сети: 1.http: //blogs.adobe.com/lin/2011/05/duplication-session-error.html 2.http: //stackru.com/questions/7659775/duplicate-session-error-when-perform-proxy-lookup оба недопустимы;
кто-нибудь встречался с такой ситуацией раньше? Любой совет я буду признателен.
1 ответ
Сегодня я столкнулся с проблемой Flex Session и столкнулся с таким SO вопросом.
Ну, вопрос довольно старый, поэтому я думаю, что оригинальный постер, вероятно, больше не нуждается в какой-либо помощи, но для любого, кто наткнется на этот пост, я, возможно, следующая информация могла бы вам помочь.
Для приложения Flex требуется действительный идентификатор сеанса из контейнера веб-приложения (в данном случае tomcat), и он привязывает идентификатор clientOID, найденный в фактическом запросе AMF, к этому идентификатору сеанса.
Таким образом, проблема первоначального автора, вероятно, заключалась в том, что он пытался использовать один и тот же идентификатор сеанса в двух экземплярах tomcat, что не будет работать, поскольку каждый экземпляр tomcat сохраняет сеансы для себя и в памяти.
Моя проблема заключалась в том, что у меня был записанный тест jmeter, и он не принял комбинацию clientID в записанном сообщении AMF и session ID в URL. Однако возвращаемое сообщение об ошибке AMF содержит действительный новый идентификатор сеанса в разделе заголовка. Заголовок AMF этого сообщения об ошибке выглядит так (по крайней мере, для меня):
Version: 3
(Header #0 name=AppendToGatewayUrl, mustUnderstand=true)
";jsessionid=OLD_SESSION_ID;jsessionid=NEW_SESSION_ID"
Поэтому я извлек новый идентификатор сеанса из заголовка AMF и использовал его для остальных запросов.
надеюсь, что это полезно для всех...