Unsolved
This post is more than 5 years old
16 Posts
0
4121
August 30th, 2009 19:00
XAM/.Net - unable to connect from a web application
I have my centera access code (using XAM) in a separate library, and am able to access/read/write with the Centera using a console application.
I'm now trying to hook this same library in to a web application and make it work. I initially was receiving the "VIM not found" error, but resolved that by adding a to the windows PATH. I'm now receiving the following error:
System.Exception: XAMException caught initialising Centera class. Message: Exception of type 'XAMSDK.XAMException' was thrown. XamMessage: xam/authentication failed
The unusual thing is that this exception is thrown almost instantaneously, when normall any operations with the Centera take a number of seconds (due to network latency etc.), therefore I suspect that for some reason it is not actually even trying to authenticate.
I'm using the following connection string:
snia-xam://centera_vim!123.123.123.123?C:\\peafile.pea
and have checked that the application has read access to this file at the point in code where the CreateXSystem() method is called.
I'm using the following code:
_xlib = XAMLibrary.Instance
_xlib.LogLevel = Constants.LOG_ALL
_xlib.LogPath = "sdk.log"
_xsys = _xlib.CreateXSystem(connectInfo)
The exception is thrown on the last line.
I'm at a bit of a loss as to why this wouldn't work from the web app, but the exact same code will work from a console app. Any tips appreciated!
Note: when running the shXAM java tool, with the pea file and centera_vim.dll in the same directory, I also get the message "xam/authentication failed"
mckeown_paul
409 Posts
0
September 1st, 2009 01:00
hitch2
16 Posts
0
September 1st, 2009 23:00
Should I be seeing the pea file opened in process explorer?
as an example, I tried using the cas command line tools just to see what procexp would report - i used:
c-list epoch now -a 123.123.123.123
and i receive a message indicating no content found on the cluster (not true, but I assume because it can't authenticate, that's the default message)
if I try:
c-list epoch now -a 123.123.123.123?p.pea
It lists all of the content, but I can't see the pea file anywhere in the process listing. Also, if I search for "pea" using the Find Handle or DLL, nothing is reported.
If I run the console application I have which does 10 inserts, 10 retrieves and 10 deletes (using the .NET api), it also is unsuccessful if I don't provide the pea and successful if I do, however again, I can't find the pea at all using process explorer.
I have ensured that the centera_vim file and the pea file are in the same location, which is the first element in the path. With both shxam and the web application, the vim is successfully loaded from this location.
I appreciate your help - this is quite frustrating given it works as part of teh console application.
mckeown_paul
409 Posts
0
September 2nd, 2009 03:00
Youi should see in the process monitor window every file open attempt your process makes and whether it was successful or not
I don't understand why you are not seeing th pea file open
The other thing to try is give the full pathname of the pea file in the connection string
hitch2
16 Posts
0
September 2nd, 2009 16:00
As I mentioned in the original post, I've been using the following (or similar) as my connection string:
snia-xam://centera_vim!123.221.123.191?C:\\Centera\\dev_profile.pea
Even when the console application works and successfully inserts/retrieves/deletes from the Centera, I still don't see the pea file appear in procexp (both manually examining all of the open file handles, and by doing a search for Handle or DLL in procexp) - similarly I don't see this file opened when running c-ping, c-list etc. with the full path to pea file specified.
This is very unusual.
mckeown_paul
409 Posts
0
September 6th, 2009 11:00
I just tried using jcasscript.jar and I saw the pea file get opened okay
Are you using procmon.exe and have added a filter process name is java.exe (which it was in my case)
hitch2
16 Posts
0
September 6th, 2009 21:00
I was using procexp.exe, but have now switched to procmon.exe - which is quite useful.
I managed to track down the issue, thanks a lot for all of your help in pointing out my own stupidity
I had a folder of dll's I was moving around for my test applications, providing the centera and xam functionality. Using procmon.exe I was able to see that an attempt was being made to open pai_module.dll, but the attempt was failing. Once I put that dll in the required location, everything worked as expected. It turns out this dll was in the console application directory (which wasn't in the path). I've now centralised all of the dll's, and am only using one location now, which should hopefully avoid this problem in future.
Apologies for taking up your time, and thanks again for your help!