asp track records 64 hits per page view!

Now it gets better

Since i added the asp code to track all ASP pages i have, i now get this error whenever i try to go to the site,

HTTP/1.1 New Session Failed

Everything i have found on this talks about database connections not being closed properly, leaking memory, and eventually clogging up all availible resources until it says "HTTP/1.1 New Session Failed"

Anyone else see this? The server was very sluggish after i started adding the code snippet to my pages, and it turned into this.

From what i read the server has to be restarted to flush out the memory, but this does not solve the problem, the memory leak has to be found or it will just happen again.

Any suggestions?

Good day overthere,

I must admit, I never experienced that situation before, but as they all say : "There is always a first time!".

Little check list :

) Determine which version of IIS is running on the server your're accessing. As per Chad's advice, it is better to run the utility on IIS 5. Personally I was successfull at getting it up and running under IIS 4, however this may vary based on the last SP applied.

) Determine the version of VBScript running on the server. Must be the most recent version of VBScript, otherwise scripts may act up or even fail.

) Is there any other Server.CreateObject on the page you're tracking, for other purpose than ADO ?

) Try to create a barebone page, with only some text on it along with the #include for the tracker. See if this is working.

) There may be a loop in the code of the page where you inserted the #include. Make sure it is outside the loop. I know, it might be silly to ask, but I prefer be safe than sorry.

) Make sure to provide the version of MetaTraffic you're running when you'll come back.

) Ideally, if you could copy and paste the source of one of your pages here, we could see things that would otherwise be impossible to determine.

I personally have tested the scripts on different sites, and I never encountered a scenario like the one you described. I'm suspecting a loop somewhere, mainly because you have a steady quantity of entries per page, actually 64.

Hope that helps.

Regards.

Hi,

It is running IIS 5 with scripts upgraded to current version.

This is the only script running on the page. I wanted to use the .asp mode of tracking for robot info, since i could care less about screen area.

I would also suspect it is a loop issue, but i did not change any of Chads code yet. I inserted the Server.Execute /track.asp at the top of all my ASP pages.

My install of IIS on this specific server is causing hell with the rest of the network. I am going to try having an independent mailserver with no IIS installed and move this website onto another server to see if that helps. The SMTP server is sending out thousands of packets on differnt ports for some strange reason, maybe it could be related.

I have the .js track running on another small site and it works fine. The site is not commercial or well advertised so it doesnt get a ton of traffic a day, but metatraffic works like a dream on it.

Now when typing in the URL, it brings up a DNS Error, and when typing in the IP into the address bar, it also brings up a DNS error. I would imagine that IIS has completly shut down!

I'll keep you posted as per the results of the switch over to a server without anything but IIS 5.

thanks

Good day,

The potential loop is not related to MetaTraffic code, in fact, the logging process is pretty straightforward, so I'm sure you can see that easily.

As far as SMTP is concerned, the scripts are not using ANY e-mail related material, therefore I would withdraw the possibility of SMTP being impacted by MetaTraffic.

If you get a DNS error, the odds are in fact that IIS was brought down.

I don't know where you're hosting your site, but 2 things might need to be verified, but before that keep in mind that some hosting services are forcing a banner at the top, via some kind of a frame, which may cause you griefs too.

1) Try to put the Server.Execute at the bottom of the page, instead of the top. Just before the call, try to add a Response.Flush (assuming Buffering is ON, which is the default for IIS 5). This should allow you to see what was rendered up to the point the logging is invoked. This will be a bit slower than normal processing, but at least you will have a little idea of what is going on.

2) If the Server.Execute still gives you griefs, try to revert to the "old fashion way" with a "traditional" #include.

Since the script is rather large in size, perhaps a Server.Execute is too demanding on the server, as it has to allocate quite a lot of memory to run the thing.

Perhaps there is some information pulled from the server by the script that put it some kind of a loop when invoked via the Server.Execute. The #include will force the server to "build" the whole page before executing the script, which might be the safest way to go.

Since Server.Execute and Server.Transfer were introduced with II5, I can't tell you if that will work, since I have only access to an IIS4 site for the moment being.

Don't forget to mention the version of MT you're using, mainly for record purposes.

If you have Win2K PRO or Server, consider testing MT locally via LocalHost with IIS 5. If you have WinXP Pro, IIS 6 will then be available to you.

I personally tested MT in Win98 with PWS, which provides me with a basic IIS4 equivalency, or almost.

If nothing is in a loop, than the odds are that the server is really short of memory. It seldomly happen, but like anything else, the possibilities are there.

Good luck...

Hi,
I got it all set.

I am using the new metatraffic (1.3x?)

I had another SMTP email server running on the same machine this site was hosted on, a dual xeon with 3 gigs of ram.

The IIS smtp virtual server was able to start along with the other smtp server, so both ports 25 and 49 were yelling back and forth on the local machine to one another, and broadcasting tons of packets all over the local network.

I totally disabled IIS on the machine, kept the third part email software running, and moved the site in question to another server with IIS 5.

I will let you know the results here in a few minutes once i am done transfering it over

Put the site on a differnt server,
when logging in, i get this
Microsoft VBScript runtime (0x800A01A8)
Object required: 'objConn'
/class.asp, line 2805

I have a feeling this has to do with updating something? (Windows update)

Anyone see this before?

SOLVED!
For some reason i addedd the server.execute command INTO the track.asp (so it was really telling the track.asp to execute the track.asp file every time the script was executed)

Don't make fun of me to much for doing this

I removed the server.ex. from the track.asp and pages load quick and memory usage is to a minimum.

I still get the

"Error Type:
Microsoft VBScript runtime (0x800A01A8)
Object required: 'objConn'
/class.asp, line 2805"

Whenver i log into the login.asp

When i delete a username and password in config.asp the error shows up when trying to load default.asp

Do i need to upgrade my server script software?

Good day,

Upgrading your server sripting software won't do any harm. If it is already at the proper level, I don't think this will change anything, but who knows.

The error you're getting, indicating that objConn is required, might have something to do with it, although if an include was omitted by mistake you would end up in a similar situation, even if the server is at the proper scripting level.

I would strongly suggest you to revise the different paths specifications in your MT scripts, mainly for the #include statements. Double-check with the scripts from the distribution files to ensure there is no omission.

If you're upgrading your server scripting software, you may take a peek at MDAC, just to make sure you're up to date on that one as well.
On all the systems I tested MT, MDAC was at level 2.5 and up.

Keep us informed of your progress.

Good luck!

It works

I guess when i downloaded something got corrupt because sections were missing of some files.

This was the cause of the lag error in the other post, as well as the error with this. Server software is fine, it simply was bad ASP code (due to a corrupted download) that was clogging up DLLHOST

It certainly was strange, and had me real concerned that some major issue was plaquing servers. I downloaded a fresh trial version and replaced the existing MT files with them and everything worked A-OK.

I removed the server.execute from the track.asp so it only records one hit per page load (and not 64) and loads the pages quickly.

I wonder why that would only loop 64 times though?

If in a page header i was saying <% server.execute pathname%> and then in the track.asp page saying another server.execute for the same file one would think that the it would keep looping (much like a Do Until Loop in VB would)

Why 64? Does asp have a mechinism in place to stop looping after 64 as to not shut down IIS? I can't imagine it does, when going through a DB file having a

Do while not db.EOF
sql=SELECT* from LOG where ip='ip'
db.rs sql, "DSN=traffc"
loop

statement would surely loop more than 64 times if the EOF was not reached.

I guess a user could upload a script that has some server intense process and have it loop continusly, and be able to shut down IIS or whatever web server is running.

For some reason i wanted to check what was being outputted by the track.asp, so i included a response.write at the end of the script. Sure enough the text printed itself out 64 times, like clockwork.

Im glad i got it working. I am curious to see how the robot tracking works, hence the desire to use ASP pages.

Good show!

Glad to see you were able to make it work. Welcome to the gang!

Server.Execute as you probably know, works pretty much in a similar way as a Call to a function.

My first thought on that situation is that DLLHOST has a limit as to how much memory it can be allocated. Reaching the the 70MB mark was pretty impressive! :D

On the other hand, before concluding this is a memory related thing, I would attempt a test with MUCH smaller asp pages, and see if the 64 figure still apply.

If it does, the it would be somehow fair to conclude that the situation is controlled via a stack. If the stack overlows, IIS may recover as it may not.

This is the beauty of the computer and programming world, there will always be unknowns to challenge us, or having us swear at them! :twisted:

If you're willing to attempt the test with really small pages, please let us know the outcome. I'm sure people will benifit from that experience.

Regards.