ERR_BAD_CONTEXT_INVALID

Startbeitrag von J André Labuschagné am 03.10.2014 23:34

Hi All

This is the first time I have encountered this. We have deployed dozens of WebDev sites. This machine has is a server running 6CPU's 8GB RAM and the page file is managed by the system and is currently sitting on 8091MB. Current utilization is only 36% of the memory, CPU usage is averaging out at 8%. We have set the concurrent connections for this site to 100. The idle time is set to 10 minutes.

Web Application Server 17.

It is a dynamic site.

The error is intermittent but increases with the number of concurrent connections.

Has anyone seen this sort of error and if so how does one resolve it?

Fill error is:

The context to which this request refers (-2) is unknown.
The server may have been restarted since your last request.
(54, ERR_BAD_CONTEXT_INVALID)

Any ideas welcome.

Cheers
Andre

Antworten:

Hello André,

when you say "It is a dynamic site. ", I understand that it is NOT an AWP dynamic site. If that is correct, and added to the fact that the error is intermittent, it COULD be a simple case of users clicking on the BACK one page button, and this putting your page out of sync with the session.

Best regards

von Fabrice Harari - am 04.10.2014 10:07
Hi Fabrice

>when you say "It is a dynamic site. ", I understand that it is NOT an AWP dynamic site.

Correct. It is a dynamic site.

>If that is correct, and added to the fact that the error is intermittent, it COULD be a >simple case of users clicking on the BACK one page button, and this putting your page >out of sync with the session.

Nope. I have tested it myself under load and it is weird. The login screen comes up. Put in credentials and bang - this error. Next time you get in and get to the page you want to and do whatever you want and it is fine. Then the next time you log in and try that same page and you get this error. And tomorrow you go in and login comes up and after that bang again.

I have also checked and the back button and it was not disabled on the login page. I have changed that now. These are business apps so as a force of habit we do not enable the back button on any page. I am wondering now if the login button when pressed can somehow affect the back one page button on the login page. If so that would explain it. But that would be really weird and I think not. What do you think?

Thanks for trying to help. I often find it extremely difficult to get any help from Montpelier for this sort of problem. Hoping that it something silly that I have done.

Any other ideas?

Cheers
Andre

von J André Labuschagné - am 04.10.2014 18:12
Hi Andre

is the problem the same with all browsers ? Or could it be something specific to one (by example the Ajax refresh problem coming with IE)?

Best regards

von Fabrice Harari - am 05.10.2014 16:23
Hi Fabrice

It seems to be all browsers. One client was using Firefox and had the problem. Switch to IE and it was fine. And then a little later IE was returning the same error. I understand that the WAS specifically looks after sessions and context. That is what it is all about. I also understand that the back button is a killer - it causes this sort of error. So we disallow the back button everywhere.

You mention an Ajax refresh problem with IE? What problem is that? Is there anything I can check with respect to any AJAX we have used?

Cheers
Andre

von J André Labuschagné - am 05.10.2014 20:49
As far as i can remember we had the same problem in one site in WB15.
The problem was in the parameter Maximum mumbers of connection of a user on a site, using a value different from zero in that parameter was the solution.

One of our routers was using NAT and the connection from that network had always the same IP the WAS just restarts the connection, we never understood why but that change solved it.

von Paulo Oliveira - am 06.10.2014 09:43
Hi Andre

if you google IE AJAX problem, you'll have all the gory details...

Basically, it seems that M$, in their almighty wisdom, decided that if you do TWO (or more) AJAX calls with the SAME parameters, the answer from the server HAS to be the same. It clearly doesn't matter to them that the data on the server may have CHANGED between the two calls.

So they basically juts cache the result of any ajax call, and if a new one is made with the same parameters, it's not executed and get the cache result instead.

Therefore, you have to make sure to at least add a dummy parameter with date/time in it, or something of the kind.

Best regards

von Fabrice Harari - am 06.10.2014 10:42
Hi Paulo

>The problem was in the parameter Maximum mumbers of connection of a user on a >site, using a value different from zero in that parameter was the solution.

This we have not done. Will try it. I think that you may have just solved our problem.

Cheers
Andre

von J André Labuschagné - am 06.10.2014 18:52
Hi Fabrice

>Basically, it seems that M$, in their almighty wisdom, decided that if you do TWO (or >more) AJAX calls with the SAME parameters, the answer from the server HAS to be >the same. It clearly doesn't matter to them that the data on the server may have >CHANGED between the two calls.

Indeed - I am completely gobsmacked. And they have been in the trade for, what, around 30 years or so!!!!

> So they basically juts cache the result of any ajax call, and if a new one is made with >the same parameters, it's not executed and get the cache result instead.

How charming.

> Therefore, you have to make sure to at least add a dummy parameter with date/time in >it, or something of the kind.

Will try that.

Thanks for the input.

Cheers
Andre

von J André Labuschagné - am 06.10.2014 18:56
Zur Information:
MySnip.de hat keinen Einfluss auf die Inhalte der Beiträge. Bitte kontaktieren Sie den Administrator des Forums bei Problemen oder Löschforderungen über die Kontaktseite.
Falls die Kontaktaufnahme mit dem Administrator des Forums fehlschlägt, kontaktieren Sie uns bitte über die in unserem Impressum angegebenen Daten.