（本文档仅供参考）
问题说明
现象一：
在同一个服务器上部署了两个应用，分部以不同的端口号区分，这时候在同一个浏览器同时访问着两个环境，发现会导致出现会话超时的现象，一直无法正常登陆使用系统。
...
如在浏览器上访问了http://10.10.202.17:18620/smartbi/vision/index.jsp，同时在这个浏览器另一个标签访问 http://10.10.202.17:18600/smartbi/vision/index.jsp ，然后会无法正常登陆使用系统：
现象二：
系统集成环境，有可能会在一个集成环境中同时传递多个报表，并都传递了用户名和密码，这时候也会造成访问的时候出现会话混乱，导致系统报表访问会话超时的现象。系统集成环境，有可能会在一个集成环境中同时传递多个报表，这时候如果没有有用的JSESSIONID 也会造成访问的时候出现会话混乱，导致系统报表访问会话超时的现象。
机理说明
Smartbi的会话保持原理：
Smartbi的会话保持机制和其他应用一样都是遵循浏览器对于cookie持有机制的，浏览器cookie原理可以查看网上相关介绍文档 ： https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies：
...
对于浏览器cookie更详细的原理说明也可通过网上的文档进一步了解：https://blog.csdn.net/wangjun5159/article/details/52312737
Cookie中的JSESSIONID与Smartbi的关系
第一：Cookie中的JSESSIONID 是浏览器请求服务器时，服务器生成返回给浏览器的会话ID，一个JSESSIONID对应一个会话。Smartbi是会话的使用方，会将一些报表信息、用户信息等放到会话当中，本身无法控制会话的生成和消费，会话的生成和消费是由服务器和浏览器决定的。
...
第三：当浏览器同时加载多个报表时，由于请求中的cookie中都没有带有JSESSIONID，此时服务器会生成多个不同的JSESSIONID给浏览器。而Smartbi对于同一个浏览器，只会保留最后一个会话的信息。所以当浏览器再次向Smartbi发起报表请求时，浏览器带过来的JSESSIONID是属于未被服务器保留的会话，则无法找到相关的报表信息和用户信息而提示报错。
采取JSESSIONID 进行维持会话的主要和报表类型有关系，比如说电子表格、旧透视分析、旧即席查询，这些报表类型都是早期产品架构设计选定了JSESSIONID的逻辑。V11版本对于交互仪表盘、新即席查询、新透视分析，已重构成无状态设计，如果是在V11版本进行此类报表集成，可避免会话冲突问题，但电子表格/web电子表格功能设计原因，如回写功能，必须要和JSESSIONID绑定存储状态，无法变成无状态架构。
解决方案
现象一解决方案：
分别在不同浏览器，或者同一个浏览器上，一个系统用浏览器直接访问效果，另一个系统用【打开新的无痕窗口】，这样的话，两个系统持有的cookie信息也是不一样的，不会被覆盖。
现象二解决方案：
第三方系统，在同时打开多个openresource.jsp 页面，先触发smartbi静态页面，进行一次握手动作，静态页面URL是 http://ip:端口号/smartbi/vision/noop.jsp。触发方式有两种，第三方系统按实际情况选用：
...
（2）如果第三方系统和Smartbi不存在跨域问题，可以用Ajax调用noop.jsp，请求返回200状态码后再执行同时打开多个openresource.jsp 页面的操作。
如果项目是使用V11版本，可以考虑使用交互仪表盘、新透视分析、新即席查询开发报表并做集成，也可避免会话混乱问题。
