遇到Session灵异啦,请各位高人进来分析一下

Question

现在正在做一个进度条控件WEB自定义控件内嵌js资源,浏览器端是XMLHTTP异步请求实时数据,服务端调用自定义控件的静态方法来更新进度和给浏览器返回实时数据异步请求用是SetTimeout循环调用XmlHttp组件的open方法,确认标志为异步了,这个请放心服务端有个ResponsePage.ashx文件,为了防止用户进行艰巨任务的时候,将会话所在线程阻塞
使用了异步HTTP处理方法,开线程,这样确实受同一会话里的其他任务影响很小,可以及时的返回进度我在测试的时候,是直接在ResponsePage.ashx中更新进度条,然后返回实时数据的而进度条的实时数据在服务端是存储在session中的一个结构体前面声明了,因为是调用的静态方法,而且是在ashx中调用的静态方法
所以要获取session首先应该加上IRequiresSessionState接口,在方法内部访问session时,我用了两种方法因为异步调用时,他会传入一个Httpcontext对象,我在异步调用的静态方法中是用的这个参数
还有个用于同步调用的方法,是用HttpContext.Current获取的当前Context,然后访问session[我怀疑问题就在这个地方]default.aspx为测试页面,有一个文件上传框,一个按钮
点击按钮的时候,先提交表单(开始上传),然后启动进度条更新脚本=========================================================================下面是我遇到的情况
IE浏览器可以正常使用,即使在浏览器cpu占用非常高,服务器cpu占用也非常高的时候,进度条还可以是不是更新一下,基本可用而firefox下....
一会儿出现个异常,
在这行代码这里:ProgressBarStatus _Status = (ProgressBarStatus)context.Session[ProgressBarId];
添加监视后发现,session里面是空的我就想啊,怎么会是空的呢?研究了半天没搞懂,就用try catch将这段有异常的过去了,并在catch里面给session赋值(一段错误描述,融进进度条结构体中了)没想到啊,我手工访问那个ResponsePage.ashx出现了这样的情况我刷新一次:出现我子定义的错误信息
我再刷新一次:进度条数字正常增长,并且是一直在正常增长...
似乎有两个session一样这还好些,后来更蹊跷的事情发生了
我点击default页面的按钮,提交表单并开始更新进度条后
一开始是一秒一个错误
后来是一秒错误,下一次就是正确的进度条增长再后来,出现进度条波动啦,就是说这样的(举个例子)
本来应该是 1,5,10,15,20
现在成了   1,10,5,15,10,20,15
左右摆动前进啊
但是这一切在IE浏览器里是正常的我用HTTP嗅探器看过了,两个浏览器对于ResponsePage的访问是一致的
而上传文件时的TCP数据包,我只截取了firefox的,IE的还没有分析,暂时没有对比结果感觉是Firefox的文件上传机制把ASP.NET的Session机制给搞乱了,(不也是HTTP标准?)没有头绪,希望各位分析一下,看看这是怎么回事,如何解释?

Answer 1

简单说就是session异常再提交文件上传之后,用xmlhttp异步访问一个异步HTTP处理程序的时候出现session异常的情况,表现为:似乎有两个session,其中一个偶尔为空

Answer 2

太长了，你session里面的数据是从哪儿来的？你的问题在IE下是正常的？仅在FF下面出现异常？

Answer 3

从字面上分析，个人认为是你的异步处理问题……
在WinForm下委托刷新进度条还要强制执行一下所有事件，否则Windows消息也会有乱了顺序的时候~何况网络请求呼……
另外，浏览器本就是一个单线程的东西，在页面上做异步是为了避免服务器后台处理事件响应时间过长~而上传文件明显是前后台实时交互……
LZ在IE下能正常显示进度已经令我感到很惊讶了~~
当你在一个页面里短时间内发出多个异步请求（还有一个长时间占着线程的上传-_-b），你永远不会知道哪个请求会先回来……

Answer 4

你说你用HTTP嗅探器探过，把截获的封包放出来看看估计有可能是ajax提交时，回传给服务器的sessionId乱了
我想你应该这么解决问题：ajax提交给服务器不要依靠浏览器默认的sessionid提交方式，你可以直接构造http封包提交过去

Answer 5

另外：一个长时间的异步调用也不应该直接依靠session，毕竟session有超时机制和sessionid的管控，我想你应该重点跟踪一下服务器和浏览器间sessionid的传输情况

Answer 6

从字面上分析，个人认为是你的异步处理问题…… 
在WinForm下委托刷新进度条还要强制执行一下所有事件，否则Windows消息也会有乱了顺序的时候~何况网络请求呼…… 
另外，浏览器本就是一个单线程的东西，在页面上做异步是为了避免服务器后台处理事件响应时间过长~而上传文件明显是前后台实时交互…… 
LZ在IE下能正常显示进度已经令我感到很惊讶了~~ 
当你在一个页面里短时间内发出多个异步请求（还有一个长时间占着线程的上传-_-b），你永远不会知道哪个请求会先回来……从字面上分析，个人认为是你的异步处理问题…… 
在WinForm下委托刷新进度条还要强制执行一下所有事件，否则Windows消息也会有乱了顺序的时候~何况网络请求呼…… 
另外，浏览器本就是一个单线程的东西，在页面上做异步是为了避免服务器后台处理事件响应时间过长~而上传文件明显是前后台实时交互…… 
LZ在IE下能正常显示进度已经令我感到很惊讶了~~ 
当你在一个页面里短时间内发出多个异步请求（还有一个长时间占着线程的上传-_-b），你永远不会知道哪个请求会先回来……从字面上分析，个人认为是你的异步处理问题…… 
在WinForm下委托刷新进度条还要强制执行一下所有事件，否则Windows消息也会有乱了顺序的时候~何况网络请求呼…… 
另外，浏览器本就是一个单线程的东西，在页面上做异步是为了避免服务器后台处理事件响应时间过长~而上传文件明显是前后台实时交互…… 
LZ在IE下能正常显示进度已经令我感到很惊讶了~~ 
当你在一个页面里短时间内发出多个异步请求（还有一个长时间占着线程的上传-_-b），你永远不会知道哪个请求会先回来……从字面上分析，个人认为是你的异步处理问题…… 
在WinForm下委托刷新进度条还要强制执行一下所有事件，否则Windows消息也会有乱了顺序的时候~何况网络请求呼…… 
另外，浏览器本就是一个单线程的东西，在页面上做异步是为了避免服务器后台处理事件响应时间过长~而上传文件明显是前后台实时交互…… 
LZ在IE下能正常显示进度已经令我感到很惊讶了~~ 
当你在一个页面里短时间内发出多个异步请求（还有一个长时间占着线程的上传-_-b），你永远不会知道哪个请求会先回来……从字面上分析，个人认为是你的异步处理问题…… 
在WinForm下委托刷新进度条还要强制执行一下所有事件，否则Windows消息也会有乱了顺序的时候~何况网络请求呼…… 
另外，浏览器本就是一个单线程的东西，在页面上做异步是为了避免服务器后台处理事件响应时间过长~而上传文件明显是前后台实时交互…… 
LZ在IE下能正常显示进度已经令我感到很惊讶了~~ 
当你在一个页面里短时间内发出多个异步请求（还有一个长时间占着线程的上传-_-b），你永远不会知道哪个请求会先回来……从字面上分析，个人认为是你的异步处理问题…… 
在WinForm下委托刷新进度条还要强制执行一下所有事件，否则Windows消息也会有乱了顺序的时候~何况网络请求呼…… 
另外，浏览器本就是一个单线程的东西，在页面上做异步是为了避免服务器后台处理事件响应时间过长~而上传文件明显是前后台实时交互…… 
LZ在IE下能正常显示进度已经令我感到很惊讶了~~ 
当你在一个页面里短时间内发出多个异步请求（还有一个长时间占着线程的上传-_-b），你永远不会知道哪个请求会先回来……从字面上分析，个人认为是你的异步处理问题…… 
在WinForm下委托刷新进度条还要强制执行一下所有事件，否则Windows消息也会有乱了顺序的时候~何况网络请求呼…… 
另外，浏览器本就是一个单线程的东西，在页面上做异步是为了避免服务器后台处理事件响应时间过长~而上传文件明显是前后台实时交互…… 
LZ在IE下能正常显示进度已经令我感到很惊讶了~~ 
当你在一个页面里短时间内发出多个异步请求（还有一个长时间占着线程的上传-_-b），你永远不会知道哪个请求会先回来……从字面上分析，个人认为是你的异步处理问题…… 
在WinForm下委托刷新进度条还要强制执行一下所有事件，否则Windows消息也会有乱了顺序的时候~何况网络请求呼…… 
另外，浏览器本就是一个单线程的东西，在页面上做异步是为了避免服务器后台处理事件响应时间过长~而上传文件明显是前后台实时交互…… 
LZ在IE下能正常显示进度已经令我感到很惊讶了~~ 
当你在一个页面里短时间内发出多个异步请求（还有一个长时间占着线程的上传-_-b），你永远不会知道哪个请求会先回来……从字面上分析，个人认为是你的异步处理问题…… 
在WinForm下委托刷新进度条还要强制执行一下所有事件，否则Windows消息也会有乱了顺序的时候~何况网络请求呼…… 
另外，浏览器本就是一个单线程的东西，在页面上做异步是为了避免服务器后台处理事件响应时间过长~而上传文件明显是前后台实时交互…… 
LZ在IE下能正常显示进度已经令我感到很惊讶了~~ 
当你在一个页面里短时间内发出多个异步请求（还有一个长时间占着线程的上传-_-b），你永远不会知道哪个请求会先回来……从字面上分析，个人认为是你的异步处理问题…… 
在WinForm下委托刷新进度条还要强制执行一下所有事件，否则Windows消息也会有乱了顺序的时候~何况网络请求呼…… 
另外，浏览器本就是一个单线程的东西，在页面上做异步是为了避免服务器后台处理事件响应时间过长~而上传文件明显是前后台实时交互…… 
LZ在IE下能正常显示进度已经令我感到很惊讶了~~ 
当你在一个页面里短时间内发出多个异步请求（还有一个长时间占着线程的上传-_-b），你永远不会知道哪个请求会先回来……从字面上分析，个人认为是你的异步处理问题…… 
在WinForm下委托刷新进度条还要强制执行一下所有事件，否则Windows消息也会有乱了顺序的时候~何况网络请求呼…… 
另外，浏览器本就是一个单线程的东西，在页面上做异步是为了避免服务器后台处理事件响应时间过长~而上传文件明显是前后台实时交互…… 
LZ在IE下能正常显示进度已经令我感到很惊讶了~~ 
当你在一个页面里短时间内发出多个异步请求（还有一个长时间占着线程的上传-_-b），你永远不会知道哪个请求会先回来……从字面上分析，个人认为是你的异步处理问题…… 
在WinForm下委托刷新进度条还要强制执行一下所有事件，否则Windows消息也会有乱了顺序的时候~何况网络请求呼…… 
另外，浏览器本就是一个单线程的东西，在页面上做异步是为了避免服务器后台处理事件响应时间过长~而上传文件明显是前后台实时交互…… 
LZ在IE下能正常显示进度已经令我感到很惊讶了~~ 
当你在一个页面里短时间内发出多个异步请求（还有一个长时间占着线程的上传-_-b），你永远不会知道哪个请求会先回来……从字面上分析，个人认为是你的异步处理问题…… 
在WinForm下委托刷新进度条还要强制执行一下所有事件，否则Windows消息也会有乱了顺序的时候~何况网络请求呼…… 
另外，浏览器本就是一个单线程的东西，在页面上做异步是为了避免服务器后台处理事件响应时间过长~而上传文件明显是前后台实时交互…… 
LZ在IE下能正常显示进度已经令我感到很惊讶了~~ 
当你在一个页面里短时间内发出多个异步请求（还有一个长时间占着线程的上传-_-b），你永远不会知道哪个请求会先回来……从字面上分析，个人认为是你的异步处理问题…… 
在WinForm下委托刷新进度条还要强制执行一下所有事件，否则Windows消息也会有乱了顺序的时候~何况网络请求呼…… 
另外，浏览器本就是一个单线程的东西，在页面上做异步是为了避免服务器后台处理事件响应时间过长~而上传文件明显是前后台实时交互…… 
LZ在IE下能正常显示进度已经令我感到很惊讶了~~ 
当你在一个页面里短时间内发出多个异步请求（还有一个长时间占着线程的上传-_-b），你永远不会知道哪个请求会先回来……从字面上分析，个人认为是你的异步处理问题…… 
在WinForm下委托刷新进度条还要强制执行一下所有事件，否则Windows消息也会有乱了顺序的时候~何况网络请求呼…… 
另外，浏览器本就是一个单线程的东西，在页面上做异步是为了避免服务器后台处理事件响应时间过长~而上传文件明显是前后台实时交互…… 
LZ在IE下能正常显示进度已经令我感到很惊讶了~~ 
当你在一个页面里短时间内发出多个异步请求（还有一个长时间占着线程的上传-_-b），你永远不会知道哪个请求会先回来……从字面上分析，个人认为是你的异步处理问题…… 
在WinForm下委托刷新进度条还要强制执行一下所有事件，否则Windows消息也会有乱了顺序的时候~何况网络请求呼…… 
另外，浏览器本就是一个单线程的东西，在页面上做异步是为了避免服务器后台处理事件响应时间过长~而上传文件明显是前后台实时交互…… 
LZ在IE下能正常显示进度已经令我感到很惊讶了~~ 
当你在一个页面里短时间内发出多个异步请求（还有一个长时间占着线程的上传-_-b），你永远不会知道哪个请求会先回来……从字面上分析，个人认为是你的异步处理问题…… 
在WinForm下委托刷新进度条还要强制执行一下所有事件，否则Windows消息也会有乱了顺序的时候~何况网络请求呼…… 
另外，浏览器本就是一个单线程的东西，在页面上做异步是为了避免服务器后台处理事件响应时间过长~而上传文件明显是前后台实时交互…… 
LZ在IE下能正常显示进度已经令我感到很惊讶从字面上分析，个人认为是你的异步处理问题…… 
在WinForm下委托刷新进度条还要强制执行一下所有事件，否则Windows消息也会有乱了顺序的时候~何况网络请求呼…… 
另外，浏览器本就是一个单线程的东西，在页面上做异步是为了避免服务器后台处理事件响应时间过长~而上传文件明显是前后台实时交互…… 
LZ在IE下能正常显示进度已经令我感到很惊讶了~~ 
当你在一个页面里短时间内发出多个异步请求（还有一个长时间占着线程的上传-_-b），你永远不会知道哪个请求会先回来……了~~ 当你在一个页面里短时间内发出多个异步请求（还有一个长时间占着线程的上传-_-b），你永远不会知道哪个请求会先回来……回来……回来……回来……回来……回来……的饿饿444444444

Answer 7

我觉得你应该去依靠一个全局的静态集合对象比较实际，比如一个静态hashtable，初始时利用sessionid做key，加入hashtable，客户端直接用get方式提交sessionid，服务器根据sessionid访问hashtable，执行完了把hashtable的那个key给删掉这个东东，其实还有细节可以挖，比如可以开线程池，服务器去访问线程中的变量，只要线程不挂，你就能访问的到

Answer 8

ajax的session提交是没有问题的,所有ajax的HTTP头,我都跟过了,包括IE和FF中正在监视asp.net计数器中的session total,session active
试着重现昨晚的环境
我现在是在单位机器上

Answer 9

ustbwuyi:我session中的数据,,是通过一个静态方法进行设置的
进度条数据存储在session中,其生存周期是这样的在访问进度条控件所在页面的时候,对进度条控件render过程中,建立session数据在任务进行中,更新session中的进度数据在ResponsePage页面中,访问session数据,并合成为类似于下面这种格式的数据,返回给xmlhttp调用{StateCode:0,Message:'',Data:{InnerWidth:'114px',Text:'正在处理'}}

Answer 10

0xff从字面上分析，个人认为是你的异步处理问题……
在WinForm下委托刷新进度条还要强制执行一下所有事件，否则Windows消息也会有乱了顺序的时候~何况网络请求呼……
另外，浏览器本就是一个单线程的东西，在页面上做异步是为了避免服务器后台处理事件响应时间过长~而上传文件明显是前后台实时交互……
LZ在IE下能正常显示进度已经令我感到很惊讶了~~
当你在一个页面里短时间内发出多个异步请求（还有一个长时间占着线程的上传-_-b），你永远不会知道哪个请求会先回来……你说的有道理,我也怀疑是异步的问题,因为服务端和浏览器均在异步,而IE下,是正常的
所以目前怀疑是FF在执行了文件上传操作后的XMLHTTP调用受到了影响(但我查看HTTP头又发现一致)
难道是影响了ASP.NET的session有效性判定机制?你说的最后一句
确实有这个问题,一个请求在繁忙的上传文件,同时还有一个HTTP请求
虽然第二个请求的目标页面我已经使用异步处理妄图使其立即返回,而且似乎也确实是立即返回了
但数据有错误.....session有问题......
而有时候,确实回不来假如先开始更新进度条,然后提交文件上传,直接挂掉,xmlhttp对象失效,继续分析...

Answer 11

wanghui0380你说你用HTTP嗅探器探过，把截获的封包放出来看看估计有可能是ajax提交时，回传给服务器的sessionId乱了
我想你应该这么解决问题：ajax提交给服务器不要依靠浏览器默认的sessionid提交方式，你可以直接构造http封包提交过去我考虑过这个可能,所以在两个页面都输出了sessionID,结果发现一致,没有问题,就是session的内容空了ajax提交的HTTP头我已经全部看过了,没有发现问题谢谢

Answer 12

ladOnTheBrinkOfRage我猛一看回复那么多字,好兴奋啊,再一看,都是重复的,呵呵

Answer 13

yuan74521940,cceon,honey52570,yhy0611,liuyun1987等网友谢谢你们的热心我也想改简单一点,让大家看着舒服些,不过发现CSDN不给我机会啊,没法编辑抱歉

Answer 14

CloneCenter就像楼上又写些朋友说的那样，既然是异步调用，你可能没有办法知道他什么时候返回了上一次的查询结果。有可能是后请求的数据，最先被发回来了。
尝试这样，在浏览器中发送一个请求之后，等待服务器返回，如果没有返回的话，就等下去，有了返回再发送下一个请求，试试看。你说的问题我考虑过,不过现在我在本地调试这个问题不是很严重,再说
我说的乱,不仅仅是数的问题,有时候根本就没有了,session空了,这个可不是顺序的问题了加入在浏览器发请求,等待服务器返回的话,是不是就是XMLHTTP同步调用啊
浏览器会停止渲染死掉的,

Answer 15

只能说
楼上各位强人！
我碰到过的问题是Session传递错乱或者丢失
-----------------------------------PS：解决办法，给各个有Session传递的页面地址加入一个随即值
比如：原来为a.aspx?id=1
改为：a.aspx?id=1&Random=12321321321312312312
这样，通过传递页面唯一保证Session唯一！

Answer 16

把session设的时间长一些！！！

Answer 17

就偶的经验,session只在页面间传递数据不会出问题,在本页自提交,一般用Viewstate

Answer 18

1、处理异步返回问题：丢弃错误的和过期的返回（即进度只增不减），最后返回成功标志或者根据错误次数判断失败；
可能出现的现象--进度条突然飞跳~  不过没什么人会感到奇怪~毕竟网络也是时快时慢……2、防止页面缓存问题：就是在请求链接后面加上Random()参数；3、服务器异步问题：
如果LZ的请求过程是这样--
上传请求        ---  页面新建服务器线程处理
开始进度条请求  ---  页面线程直接处理
……我没试过，所以不清楚会发生什么……
不过如果你能确保两个线程的Session一致的话，那么返回数据错误就是其他原因造成的，查一下操作Session的部分吧~

Answer 19

今天没能重新昨天的情况,但是也一直异常,只不过没有昨天(确切的说是今天凌晨)那么离谱找资料的时候,看到了http://www.builder.com.cn/2007/1111/623895.shtml中的那副图我现在的情况跟那副图一样,查询线程返回一次后,就挂在那里了从上面的文章中知道了有这样的问题wanghui0380的话给了我很大帮助,既然怀疑是Session机制的受影响或者是Session相关的问题干脆换成哈希表了,(还是喜欢叫字典,总觉得哈希表有些....麻人)然后在临界区加lockOK了,已经可以正常工作了,
FF和IE都没有问题准备哪天抽空把我写这个WEB自定义控件的感受写一下,跟大家分享是不是ASP.net的Session真的对多线程比较敏感?我用的InPro模式准备结贴

Answer 20

CSDN不能当日结贴吗?CSDN可以编辑啊,似乎,嘻嘻,冤枉好人啦

Answer 21

谢谢各位的关心后来又出现个问题线程争夺资源就是处理主要任务的线程,和返回实时进度条数据的线程争夺CPU资源我处心积虑想在他们两个和平共处平起平坐的基础上解决这个问题,无奈那主要任务线程太霸道没办法,只有不跟他争了,骑到他头上去解决了,呵呵

Answer 22

再次感谢基本抛弃session,留了个sessionID用线程已经用不到了^_^,所以线程池也就用不到了,谢谢

Answer 23

用于asp.net2.0的实时WEB进度条控件刚写好感兴趣的可以看看本控件使用XMLHTTP组件在浏览器端异步请求进度条实时数据，同时由特定的Http   Module进行快速响应，不会因为用户的高负载操作而轻易失去响应，或者阻塞。可以根据不同的使用场景对进度条进行适当调整以完成实时进度显示任务。
详细介绍
http://www.antardev.cn/showArticle.asp?id=34