Pervasive

Hello,

Can anyone suggest what might be causing the error "Invalid LNA response packet", which is apparently coming from the PSQL11 client software and complaining about the data coming back from the P11 server ?

More details:

I've seen this error a few times on various systems, going back as far as P9.5, and it has usually required a restart of the Windows services to clear (all our Pervasive stuff is on Windows).  But on one -- and only one -- of our customers' sites they are getting this error sporadically but quite frequently, and although it sometimes seems to clear itself  for a while, it doesn't stay cleared.

It's difficult to get details of this particular customer's software/hardware environment, but what I know today is:

All the Pervasive software is version 11 (don't know what SP level), running on Windows Server 2003, 32-bit.

The "client" software is actually a web server running is the MS IIS container (I think IIS6).  That software is written in C#, ASP.NET framework 2.0, and uses a connection string like the following:

    <connectionStrings>
        <clear/>
        <add
            name="AName"
            providerName="Pervasive.Data.SqlClient"
            connectionString="Server=XXXX; Database=YYYY;" />

Normally the application works correctly, but occasionally the DB connection will throw an error with the above text.  If it helps, it usually (perhaps always) happens while we are trying to close the connection.  A partial stack trace is:

Stack trace:
   at Pervasive.Data.SqlClient.Lna.ae.a(Stream )
   at Pervasive.Data.SqlClient.Lna.am.a(v , u )
   at Pervasive.Data.SqlClient.Lna.am.ci(v , u )
   at Pervasive.Data.SqlClient.Lna.w.a(Int16 )
   at Pervasive.Data.SqlClient.Lna.w.bv()
   at Pervasive.Data.SqlClient.PsqlConnection.Close()
   at: ... our custom code below here...

The same software is running on other customers' sites (with similar sized DBs and workloads) without these problems.  I don't know for sure if any of those other sites are running similar hardware/software combinations to the problem site. 

Can anyone suggest a cause, a fix, or what extra data I should try to collect ?

Thanks

       -- chris

What version of the Pervasive.Data.SqlClient.DLL are you using? 

I haven't seen this behavior before.

What's in the PVSW.LOG from both the server running IIS (and serving the ASP.NET application) and the machine running the PSQL server engine. 

This may not be related to the cause of your current configuration, but it is relevant given the version of Windows specified in the OP...

Anyone still using Windows Server 2003 or Windows XP should make sure the latest Windows service packs are installed (at least, the latest MS updates would also be highly recommended).

For all versions of Windows prior to 6.0 (Vista), Windows can have different Dynamic-Link Library Search Order and Dynamic-Link Library Redirection behavior if the latest service packs are not installed.  This can adversely affect how desktop applications and services find and load dependent libraries, especially if the libraries are installed as Side-by-side Assemblies with a particular desktop application or Windows service.  PSQL v11.0 and higher installs the Microsoft Visual Studio 2005 SP1 C++ Runtime assemblies [needed by the PSQL engine] side-by-side in the PSQL application directory.  In addition, PSQL v10.3 and higher also installs the Sun Java Runtime Environment (JRE) Version 6 files and the Eclipse Rich Client Platform (RCP) files [needed by some of the PSQL utilities] side-by-side to the PSQL application directory (if they are not already installed on the target system).  The latter would only potentially impact the runtime functionality of some of the PSQL utilities (and not the runtime of the PSQL engine itself).

Again, I do not know if anything I've mentioned above is related to the cause of the issue your customer is experiencing or not.  If it is impacting your customer there would probably be a "Side-by-side" error event written to the Windows event log.  If this is the case, I would suggest the following course of action:

1. Make sure the Windows Server 2003 system has the latest MS service pack and updates installed.
2. Try running the stand-alone installation of the 32-bit MS VS 2005 SP1 C++ Runtime available from the Microsoft Download Center. That will ensure the runtime files are installed "globally" on the target system so the PSQL engine will be able to load the dependencies from whichever location is more appropriate for Windows 2003 Server.

 In addition, if you're having trouble with any of the PSQL utilities you can also try installing the latest stand-alone JRE Version 6 installation from the Java download page.  That will ensure the JRE runtime files are installed "globally" on the target system so any PSQL utilities dependent on the files will be able to load them from whichever location is more appropriate for Windows 2003 Server.

Make sure that they're on at least v11 update 1 which has update 60103 to reduce memory allocation errors which can cause connections to fail.  Along the same line, take a look at what the cache allocation, max microkernel memory usage, and system cache settings are, and how much RAM the server has.  You may want to try lowering the amount of memory dedicated to the file caching.  I don't know if that error is returned to the client if the connection fails to the server because of low available memory but it's something to try.

Thanks, everyone, for your responses.

As I said, it's difficult to get hard information about this customer's installation, but what I now have is:

Pervasive.Data.SqlClient: version is 3.5.0.1813

Engine version is: 11.00.276

There's nothing that seems remotely relevant in C:\Windows\PCSW.LOG (only a few entries, and nothing at all for the last few days even though the problem has occurred several times during that period).

Thanks for the suggestion of 11 upgrade 1: it sounds promising, and I hope to try that, but -- since this is a live service, and there's a more important app against the same DB without the problem (it use the transactional, rather than the relational, interface) -- the customers might not want to risk worse disruption at what happens to be a very busy time.

I looked at the memory/cache stuff, but it didn't seem too surprising, but then I'm not a Pervasive expert (just a programmer).  Is there any guidance anywhere on what would be sensible settings for a given workload (I realise that such advise would, at best, be vague).

One other bit of data that has turned up: there is now some suspicion that the condition usually follows (some minutes later) after a query has timed-out on the client/web-server.  Not sure if that has any real connection.  It certainly isn't the case that the failure follows immediately afterwards, nor that it always follows at all.  It might even be that the timeout is a symptom of the server having failed to communicate the results back to the client rather than the query actually taking too long.

Thanks again,

     -- chris

First, 11.00 is the original release of PSQL v11.  I would suggest updating to PSQL v11 SP2. It's at http://pervasivedb.com/psqlv11/Pages/Default.aspx.  I understand about not disrupting the other application.  What I would suggest would be to setup a test environment and install the SP2 trial and try the applications (both transactional and relational apps) against it.  Once that is done, it'll be easier to convince the powers that be to update the live server. 

With PSQL v11, the PVSW.LOG is not in the WINDOWS directory but is in  "%ProgramData%\Pervasive Software\PSQL\logs\".  This is true on both the client and the server.  Can you verify there's nothing in these PVSW.LOG files?