Error -26601: Decompression function (wgzMemDecompressBuffer) failed, return code=-5 (Z_BUF_ERROR), inSize=0, inUse=0, outUse=0 [MsgId: MERR-26601] With LoadRunner/Performance Center applicable to all versions.

20 Feb

My team frequently get this error message while running this scenario in performance center for many of our web application.Of course percentage of errors were extremely less.All these days I was pretty much ignoring this message whenever we use to get this.The reason for ignoring this message was that I strongly believe that this  was due to bug in LoadRunner.Reason for ignoring this was that I have come across this message in almost all version of LoadRunner starting from LoadRunner 8.0.

Some days back my colleague started getting this message in Vugen 9.52 with web protocol while scripting for remedy thin client 8.0 version.So I thought that let me investigate and see why LoadRunner keeps frequently give this error message in spite of correct response coming back from server.

Some of my observations were,

1. This errors tends to come whenever response have more number of bytes to return.In this case we have around 20kb of response coming back from the server for that particular request.

2.Correct headers were send by the LoadRunner during replay.Solution offered by HP Support says that one needs to add some web auto add header with gzip or deflate headers.This solution has never worked from me before.So I would not recommend it.

3. This errors comes with http 1.1 version which is send via LoadRunner.

So I would like to suggest people to understand the impact of web auto add headers.Web auto add headers function adds the headers for all the subsequent requests you send.This functions sends the added headers also to the request where the particular header is not required.So be cautious when using these types of auto header functions.In stead use the web add header function, both serve the same purpose with just the difference that web add header function adds the header to request just below it and not to all subsequent requests.We need to understand that web works with correct headers and headers play very important role in web communications.Messing with headers means that you are not doing right performance testing and bound to waste lot of time in debugging the scripts for errors which comes just because you did not use the right headers in the right place for replay.By default setting LoadRunner records only specific sets of headers and not all headers which might be used by your application.

So Is this error message related to headers? ,my suggestion it might be or it might not be the case.However I observed one thing, there is one setting in run time setting of the LoadRunner where Network buffer was set with appx 12k bytes(by default it is set at 12k bytes),this setting surely means that LoadRunner client script cannot decompress or play beyond the 12k bytes of response data and we were getting around 20k bytes of response to parse.So just increased this setting to 30k bytes and also changed the http version used for replay to 1.0.That’s it script starting running the fine.

I am not sure as why changing the http version 1.1 to 1.0 did the trick but I will surely investigate more on this and come back with my observations.Well part of the credit to this solution also goes to SQAForums.I remember either Terri C or Jean Ann had posted this some years back to the thread I was either replying or some thread which I might have been reading.I feel they got this response from Mercury support.

I also remember that this particular error message comes in  3 Flavors in LoadRunner.Maybe I will try to stress my mind and see if I recollect all the 3 types and write something about that as well.

Advertisements

One Response to “Error -26601: Decompression function (wgzMemDecompressBuffer) failed, return code=-5 (Z_BUF_ERROR), inSize=0, inUse=0, outUse=0 [MsgId: MERR-26601] With LoadRunner/Performance Center applicable to all versions.”

  1. Brian Wilson August 3, 2011 at 3:14 pm #

    Great article! At least in LR 11, http 1.1 is the default. But changing the network buffer to 30k seems to have cleared up my repeated problem with this decompression error. Thanks!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

%d bloggers like this: