Driver visa session looping issue

Hi,
This is the first time I've ever setup a loop with a visa driver session in it. I am attempting to collect an array of flux data. The array indexes correspond to physical (x,y) locations on the item i'm measureing the flux of. This is why i need the data to be read in as a 5x7 array of flux. The 5x 7 matrix is collected 3 times (at 3 different z heights). However, I can't figure out why I am getting three 6x7 matrices instead of a 5x7. I can't tell if it is my shift register setup, where my visa session is implemented, etc. I just can't figure it out.
Could someone look at my attached code ( it's pretty simple, just 3 nested for loops with the visa session inside, and that data is fed out to 3 matrices, which is then stripped down further which can be ignored)
Thank you very much,
chelsea
Solved!
Go to Solution.
Attachments:
visa loop test1.vi ‏31 KB

First of all, I don't see a point in any of those sequence structures. All they are doing is creating clutter.
Secondly, why are you appending the second to last results to the whole results? That is where your extra index is coming from. Get rid of that shift register and the Build Array.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Similar Messages

Opening multiple visa sessions

I'm having problems with opening multiple VISA sessions for communicating with 4 HP-34401A multimeters in LabVIEW 6.1. If you have a little bit of time, please take a look at what I have here to see if I'm doing something wrong.
Thanks
Attachments:
HP34401_Test.vi ‏108 KB

I have made a look at your VI. I don't have the driver for the instrument I couldn't go into the subVIs and its documentation and I could not change it for you.
1. You initialise only 2 of the 4 meters. Initialize all meters.
2. In sequence 0 you close the session to the meter. In the next loop iteration it will not measure as you intended. Delete the "VISA Close" function.
3. The stop button would cause the while loop to exit. But your handling is a little bit complicated. Do following:
Delete the "not" and case where the stop terminal is connected. Wire the stop terminal directly to the termination terminal of the while loop. With the context menu set it to "stop if True". Wire the VISA sessions to the right border of the while loop and connect t
hem to the "VISA Close" function.
Waldemar
Waldemar
Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions

Multiple VISA sessions & diagram clutter

I am writing automated test sequences that use multiple VISA sessions
(multiple test instruments) and many sub VIs. Is there any way to
reduce the diagram clutter from the error cluster & visa session wiring
(i.e. hide them, or use some kind of global reference)?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

I have made a look at your VI. I don't have the driver for the instrument I couldn't go into the subVIs and its documentation and I could not change it for you.
1. You initialise only 2 of the 4 meters. Initialize all meters.
2. In sequence 0 you close the session to the meter. In the next loop iteration it will not measure as you intended. Delete the "VISA Close" function.
3. The stop button would cause the while loop to exit. But your handling is a little bit complicated. Do following:
Delete the "not" and case where the stop terminal is connected. Wire the stop terminal directly to the termination terminal of the while loop. With the context menu set it to "stop if True". Wire the VISA sessions to the right border of the while loop and connect t
hem to the "VISA Close" function.
Waldemar
Waldemar
Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions

Do we still need to close VISA sessions?

I know it sounds like a silly question but do we?
Back in my early days (LabVIEW 5.1) I used to have a set of favorite VI's for my instruments that opened a VISA session, performed a task (like taking a measurement), then closed the VISA session. I used these a lot as I could drop them in and throw a program together without having to worry about wiring the VISA sessions. Fact this speed of test development really sold our company on LabVIEW...
Well later on I was having an issue with a larger program crashing. After spending some time on the phone with a NI Engineer troubleshooting he told me that the constant opening and closing VISA sessions was not a good idea and could be the cause of my issues. So I rewrote the program opening a VISA session once for each instrument and closing it at the end. This cured the crashing and forced me to abandon my library of drop-in VI's that had served me so well for so long, totally changing the way I was writing my programs.
Now fast forward to a couple years ago when my company made the jump from Labview 5.1 to 8.0 (that was a big step) now we are at LabVIEW 2009
Among the many other changes from 5.1 to 8.0 most notably VISA had changed, I/O wire types, VISA Open was gone, VISA Close was deprecated, all my old programs have the (old) tag on the VISA blocks... AND there was a Automatically close VISA sessions in the advanced options
The fact that VISA Close was deprecated kind of leads me to believe that we are being guided to used the auto-close option. It certainly makes programming faster not having to drag the VISA wires out and close them... But often I still do just out of habit.
This also has me wondering if we even still have to open a VISA session and wire it all the way through?
So take a look at the attached overly simplified examples and explain what is the "best method"?
Attachments:
VISA.png ‏64 KB

When the option is checked, VISA sessions are only closed automatically when your VI stops running. My understanding, based on this, is that your two auto-close VISA examples are identical. The session is opened the first time a resource is used and remains open until it is explicitly closed or until your VI stops running (if the automatically close VISA sessions option is checked). If you don't automatically close VISA sessions and you do not close them explicitly, they will stay open even when your VI is not executing, which means they will open faster when you restart your code but will not be available to other applications. Of course, exiting LabVIEW closes all VISA sessions.

How are VISA sessions managed by executables?

I have noticed that VISA sessions opened in the development environment (Labview version 6.0.2) do not show up in the VISA I/O reference control of compiled executables and visa versa. I assume that each EXE has its own memory space for open VISA sessions. Is it possible to get separate EXE's and the development environment to use the same VISA memory space so that all applications and uncompiled VI's show the same open VISA sessions?

This answer, while correct, doesn't address the issue of some VISA classes and how Labview addresses open VISA sessions. It is quite correct concerning the listing of available resources, that is not the nature of my problem. The heart of the matter is the Open VISA sessions and how they are returned by the "Open VISA sessions.vi" vi in the vi.lib utilities. Also, the VISA reference control does, as you say, display currently available resources (for some classes), but it also displays currently open sessions below a dividing line for those resources not usually displayed.
The best example of this is for the TCP/IP class. Resources of this class are not displayed unless a session for them has been opened.
I have written and compiled an executable tha
t opens a VISA session for a TCP/IP resource. After opening it, the session is displayed in the executable's VISA resource control below a dividing line that separates it from the available serial and GPIB resources. If, however, I have an uncompiled VI with a VISA control open in the development environment at the same time, the open session is not displayed in that VI's resource control. If I run the compiled executable as an uncompiled VI in the development environment along with other VI's containing VISA resource controls, the open TCP/IP session is displayed in all VI's. The same holds true for the "Open VI sessions.vi". Sessions opened by compiled VI's are not returned by this subVI when it is run from outside the executable.
As I stated before, it appears the executable creates its own separate memory space for listing open VISA sessions.
I would like to create a small executable that logs in to TCP/IP resources and makes those sessions available to other VI's that ar
e either uncompiled and running in the devel environment, or are running as separate executables.
Thanks for your comments
Steve

VISA session to an instrument handle

I tried to aquire data from TEKTDS 220. I use "set condition" to "aqu
status",
then "read waveform" subVIs. So there is a problem: I need to connect the
"VISA
session" to "instrument handle", but it doesn't work. Could you please tell
me
how to connect these two type of wires?
Thanks a lot!

It looks like you're trying to mix the tktds2x0 IVI driver with the tktds2xx LabVIEW native driver. The IVI driver has an "instrument handle" which is an IVI session, and the LabVIEW driver has a "VISA session". The two wires are not compatible. You should either use just the IVI driver or just the LabVIEW driver.

Open visa sessions for controlling external dlls

I need to open a VISA session to pass a session reference into a call library fucntion that calls the vendors instrument functions. I currently see no way to do this using the call library or visa open function. Does anybody know how to proceed when you have a non NI instrument that has a dll wiht it that you need to control over USB serially?

Mike,
First thanks for your help but I have been in both those docs before. My issue is that I have an instrument vendor that has a dll with functions like this:
ViStatus _VI_FUNC Instr_autoConnectToFirst(ViPSession vi)
return(Instr_autoConnectToAll(vi,1,NULL));
that is written using some of the variables in the VISA library...
When I go to look up what datatypes these variables are in the VISA specifications so I can hopefully create inpuits on a call library function in Labview, I get descriptions like this:
Type ViStatus
This is the operational return status. It returns either a completion code or an error code as follows.
Completion Codes
Description
VI_SUCCESS
Attribute value set successfully.
VI_WARN_NSUP_ATTR_STATE
Although the specified attribute state is valid, it is not supported by this implementation.
Error Codes
Description
VI_ERROR_INV_SESSION
VI_ERROR_INV_OBJECT
The given session or object reference is invalid (both are the same value).
VI_ERROR_NSUP_ATTR
The specified attribute is not defined by the referenced session, event, or find list.
VI_ERROR_NSUP_ATTR_STATE
The specified state of the attribute is not valid, or is not supported as defined by the session, event, or find list.
VI_ERROR_ATTR_READONLY
The specified attribute is read-only.
VI_ERROR_RSRC_LOCKED
Specified operation could not be performed because the resource identified by vi has been locked for this kind of access.
I do not see how I get the IO defined for passing and returning data to these external library calls.
Any ideas???

Open VISA Session Monitor.vi

This is a vi that is located in \vi.lib\Utility\visa.llb. Did anybody ever had it worked? I started 2 VISA sessions on test equipment (a power meter connected to USB and a signal generator connected to a gpib-usb) and the number of open sessions indicated 0 when there was clearly 2 open sessions.
Ben64

Vincent90 wrote:
Hi Ben,
Can you specify your error ? Did you try to send commands to your instruments when you think that your session is open ?
BR,
Vincent
There is no error generated, the open VISA sessions just doesn't show up and the Open Sessions.vi return an empty array of references. The issue seems to be with this vi but we can't look at the diagram since it is password protected.
I was running continuous acquisitions and the VISA resource name controls was showing 2 open sessions (the small computers icon beside the resource name).
Ben64

GPIB Vi's vs. opening a VISA session

Hi,
I'm currently trying to develop a simple set of drivers for a GPIB device that we have (Stanford Research Systems SR430). I have used the Developer Zone and the guidelines and templates given there. Those templates all open a VISA session to establish communications with the instrument. I have noticed, however, that some of the GPIB vi's can perform the same functions (reading and writing) using just the address of the device rather than creating a VISA session. Is there any difference to these two methods and if so, which is recommended and why?
Thank you very much,
April

VISA is much preferred. For one thing, VISA works for not only GPIB instruments but also for serial, vxi, and TCP/IP instruments. It is fairly easy to write a single driver that accomodates more than one interface. I've had to do this several times as we have instruments that were sometimes purchased with one or another interface. Another advantage to VISA is that it supports resource sharing and locking. Multiple applications can open the same resource and locking permits the applications to share the resource in a "graceful" manner.

Why Open VISA Session?

In the driver here, the VISA Open sub-VI states that it "must be called first" when using the device. There is a similar sub-VI for closing the session.
How true is this?
I can open and run a different sub-VI (such as Write Single) with no immediately obvious problems, just by specifying the correct device in the VISA Session field. Are errors or performance hits building up in the background?
My problem is that the KS 3988 will be called on in sub VI's within sub VI's within sub VI's (relative to the main program). I'm not clear on where, exactly, I should be putting that VISA Open panel. This is especially confusing if the "dup VISA session" needs to be wired into every use of the Write Single sub-VI.

Here is a picture of the VI which actually calls the KS 3988.
My problem is that this thing is just the sub VI of a VI which is itself the sub VI of a VI that is running in a frame. The top-level VI that contains the frames has four such frames.
Now, those top three VI's all read out of the black Admin sub VI, and the bottom can both read from it and write to it. Currently, all programs use the same KS 3988 via VISA, but that needs to be something we can change on the fly.
So, where does the Open sub VI go? Do I need to include, in the frame-containing VI, something like this?
Message Edited by DJDDA on 07-31-2008 04:10 PM
Attachments:
convertfix.jpg ‏17 KB
convertvi1.jpg ‏26 KB
convertvicontext.jpg ‏66 KB

Q: what does this VISA session name means?

I'm using GPIB reading data from two oscilliscopes. When I probe the VISA
session, I found they are like "GPIB::2 27". I know GPIB::2 means GPIB
address 2. what does this 27 means?
thanks!

This is just an initial guess. Can you look at your application and see if my conjecture could be true?
I think if you open duplicate VISA sessions to a device (e.g., "GPIB::2"), we append a number to the duplicate sessions. So, perhaps you've opened (with VISA Open and the "duplicate session" input set to TRUE) "GPIB::2" 27 times. (Note that we're talking about LV 6i or later.)
Normally, you never need more than one session to a single GPIB device, so "duplicate session" should almost always be FALSE.
If that doesn't apply, then please explain more about what you are doing. Are you using VISA calls yourself, or are you using an instrument driver? Is the instrument driver written in LabVIEW, or does it wrap around a DLL?
If you were u
sing "duplicate session" set to TRUE, I'd like to know about why you think (or thought) you needed to set it.
I hope this helps.

Closing Identical VISA Sessions

I have several sub VI's using VISA in my latest build. By default they all use the same VISA session, but the user has the option to switch one or more sub VI's to a different device (different VISA session).
In my "Panel Close" event, I currently have it wired such that each sub VI's VISA session is closed separately. It occurred to me that this may cause problems in the (normal) case that one or more sub VI's is using the same session; however, my main VI is somewhat of a mess, and it will be a couple days before I can actually test this.
Will it cause errors, program crashing, etc. for me to give a Close command on a VISA session that isn't open any more?

PeterHeckert wrote:
Much easier to do than closing at exit.
But you really should be closing them when you are done with them. If you try to close something that isn't open, it is not an issue.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Login "Loop" issue after upgrading to Leopard from Tiger-iBook G4

Hi Guys,
I've the same login "loop" issue as described in *Apple KB article #306965* only on an iBook G4, unfortunately the solution offered in the KB article does not help.
There is one slight variant being that the user desktop appears for a second or two after the blue screen following login before it returns (loops) to the login window. It happens on all (2) user accounts.
The interesting thing is it doesn't occur on either account when booting in 'safe mode'.
Apart from deleting these accounts and saving/transferring the data are there any other ideas, suggestions or solutions?
Regards,
BB

Did a clean install, cloned the HD with SuperDuper and then used Mig. Asst. to restore data back to the original HD. All now OK.
A & I was done in the initial upgrade from Tiger.
Cheers,
BB

Error in using TCPIP/Instr class to open a VISA session

I use the TCPIP/Instr class session to open a VISA session to Agilent 86140B Optical spectrum Analyser and I get an Error - VISA open in Appln.vi.Help me to fix this problem.
I am able to access the instrument on LAN through a Telnet session.
Vijayalakshmi.
Attachments:
OSA_Close.vi ‏28 KB
OSA_Reset.vi ‏27 KB
OSA_Initialize.vi ‏63 KB

Thanx for the reply.The instrument is VXI-11 compliant.The error I am getting is Instrument timeout -1073807339 (BFFF0015) and I am using LabVIEW on Linux.
I have another problem.I am able to see the instrument using a Telnet session but not using http//192.168.10.2 on a web browser.It is giving an error that the host may be down and try some time later.

Session Stickiness Issue

Hi All,
I am facing session stickiness issue where we have four webserver instances and six weblogic instances.
If you see in the failure logs the JVM ID generated by the cookie is 1872775671 but the plugin is routing the request to 923706867.Please find below
Please find the success and failure logs below
Proxy Error Log :
================New Request: [amserver/UI/Login] =================
Wed Mar 20 15:01:10 2013 <202911363806070191> Uri as read from rq (request) data structure /amserver/UI/Login
Wed Mar 20 15:01:10 2013 <202911363806070191> Uri after pathTrim /amserver/UI/Login
Wed Mar 20 15:01:10 2013 <202911363806070191> Uri resolved to /amserver/UI/Login?module=GMACLoginModule&org=branch
Wed Mar 20 15:01:10 2013 <202911363806070191> resolveRequest return code is [0]
Wed Mar 20 15:01:10 2013 <202911363806070191> URI=[amserver/UI/Login?module=GMACLoginModule&org=branch]
Wed Mar 20 15:01:10 2013 <202911363806070191> INFO: SSL is not configured
Wed Mar 20 15:01:10 2013 <202911363806070191> Found cookie from cookie header: JSESSIONID=RKHWGqJvmJGWgZ9YdqywsXBLRd7QtMGX1Qr1yTmNTn0Kcdq0M0xq!-1872775671
Wed Mar 20 15:01:10 2013 <202911363806070191> Parsing cookie JSESSIONID=RKHWGqJvmJGWgZ9YdqywsXBLRd7QtMGX1Qr1yTmNTn0Kcdq0M0xq!-1872775671
Wed Mar 20 15:01:10 2013 <202911363806070191> getpreferredServersFromCookie: [-1872775671]
Wed Mar 20 15:01:10 2013 <202911363806070191> primaryJVMID: [-1872775671]
secondaryJVMID: []
Wed Mar 20 15:01:10 2013 <202911363806070191> No of JVMIDs found in cookie: 1
Wed Mar 20 15:01:10 2013 <202911363806070191> Trying to locate Primary or Secondary using SrvrInfo with JVMID: 923706867
Wed Mar 20 15:01:10 2013 <202911363806070191> getPreferredFromCookie: Start Position is 0, listLen is 1
Wed Mar 20 15:01:10 2013 <202911363806070191> getPreferredFromCookie: Either JVMIDs not set or they are stale. Will try to get JVMIDs from WLS
Wed Mar 20 15:01:10 2013 <202911363806070191> initJVMID: Iterating SrvrList from position 0
Wed Mar 20 15:01:10 2013 <202911363806070191> ======internal request /bea_wls_internal/WLDummyInitJVMIDs======
initJVMID: Trying Host[10.13.52.81] Port[7005] SecurePort[7006] useSSL [0] ioTimeout [30] socketTimeout [10]
Wed Mar 20 15:01:10 2013 <202911363806070191> INFO: New NON-SSL URL
Wed Mar 20 15:01:10 2013 <202911363806070191> Connect returns -1, and error no set to 245, msg 'Operation now in progress'
Wed Mar 20 15:01:10 2013 <202911363806070191> EINPROGRESS in connect() - selecting
Wed Mar 20 15:01:10 2013 <202911363806070191> Local Port of the socket is 63476
Wed Mar 20 15:01:10 2013 <202911363806070191> Remote Host 10.13.52.81 Remote Port 7005
Wed Mar 20 15:01:10 2013 <202911363806070191> URL::sendHeaders(): meth='HEAD' file='/bea_wls_internal/WLDummyInitJVMIDs' protocol='HTTP/1.0'
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[Connection]=[Close]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[X-WebLogic-Request-ClusterInfo]=[true]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[X-WebLogic-Force-JVMID]=[unset]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[X-WebLogic-KeepAliveSecs]=[30]
Wed Mar 20 15:01:10 2013 <202911363806070191> URL::parseHeaders: CompleteStatusLine set to [HTTP/1.1 400 Bad Request]
Wed Mar 20 15:01:10 2013 <202911363806070191> URL::parseHeaders: StatusLine set to [400 Bad Request]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from WLS:[Date]=[Wed, 20 Mar 2013 19:01:10 GMT]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from WLS:[Content-Length]=[897]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from WLS:[Content-Type]=[text/html]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from WLS:[X-WebLogic-Cluster-Hash]=[7GHstOoW2dPEsRHcWrZe05SfKAc]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from WLS:[X-WebLogic-Cluster-List]=[923706867!168637521!7005!7006]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from WLS:[Connection]=[Close]
Wed Mar 20 15:01:10 2013 <202911363806070191> parsed all headers OK
Wed Mar 20 15:01:10 2013 <202911363806070191> initJVMID: Received the same cluster-list. Returning with no preferred servers found.
Wed Mar 20 15:01:10 2013 <202911363806070191> .....internal request /bea_wls_internal/WLDummyInitJVMIDs.....processed
Wed Mar 20 15:01:10 2013 <202911363806070191> getPreferredFromCookie: Found 0 servers
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from Client:[accept]=[image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */*]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from Client:[referer]=[https://capacity.dealerservices.ally.com/userprovisioning/jsp/autoSubmit.jsp?lang=en-us&source=MigratedLoginWidget&userType=branch&process=login]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from Client:[accept-language]=[en-US]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from Client:[user-agent]=[Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; BTRS99959; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MS-RTC LM 8; .NET4.0C; InfoPath.3)]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from Client:[accept-encoding]=[gzip, deflate]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from Client:[host]=[gdpcapacity.gmacbranch.gmac.gm.com]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from Client:[cache-control]=[no-cache]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from Client:[cookie]=[s_pers=%20s_ts%3D%255B%255B%2527BRA0006T%2527%252C%25271362265430952%2527%255D%252C%255B%2527BRA0005T%2527%252C%25271363804235955%2527%255D%255D%7C1521570635955%3B%20s_nr%3D1363805063050-Repeat%7C1366397063050%3B; Locale=en-us; MasterCookie=MasterCookie; GDP_screenHeight=768; GDP_screenWidth=1366; GDP_browserType=Microsoft%20Internet%20Explorer; GDP_browserVersion=4.0%20%28compatible%3B%20MSIE%208.0%3B%20Windows%20NT%206.1%3B%20Trident/4.0%3B%20BTRS99959%3B%20SLCC2%3B%20.NET%20CLR%202.0.50727%3B%20.NET%20CLR%203.5.30729%3B%20.NET%20CLR%203.0.30729%3B%20Media%20Center%20PC%206.0%3B%20MS-RTC%20LM%208%3B%20.NET4.0C%3B%20InfoPath.3%29; GDP_operatingSystem=Win32; GDP_userAgent=Mozilla/4.0%20%28compatible%3B%20MSIE%208.0%3B%20Windows%20NT%206.1%3B%20Trident/4.0%3B%20BTRS99959%3B%20SLCC2%3B%20.NET%20CLR%202.0.50727%3B%20.NET%20CLR%203.5.30729%3B%20.NET%20CLR%203.0.30729%3B%20Media%20Center%20PC%206.0%3B%20MS-RTC%20LM%208%3B%20.NET4.0C%3B%20InfoPath.3%29; JSESSIONID=RKHWGqJvmJGWgZ9YdqywsXBLRd7QtMGX1Qr1yTmNTn0Kcdq0M0xq!-1872775671; ObSSOCookie=tKGxD0YS6sUw8kyVwfVBNujGihNvtG5GlUrYljs%2F3fngJbUm4%2B1bA6FpLn3LEESIpQsqwhjMDZODuautF%2B7zHKXypTkT%2Fn8DwdGn%2FYZOJK49wBTU511DfkqBmqBMsGjSM42jobA5gSQ672vUQskytWaJc4tZQC7MDLOGPEJf%2Bwc%2BVtXRi1%2FRGI4ql8jQpyWSJP6ImkHwt6QNig3Vlyt9BLZws6vvgHulULaxuA%2BXfUZ4fkVaVwN35tAmWorUa1ODiORCWhVSrZybMhTk53NsjT%2FdOaXFLZM4wcj6PKVkeG1UtZVfoNuVw8LBBVd5ave0]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from Client:[gmacdealer_groups]=[smartcash:scsupervisor:branch:us:en-us:EOAdminUS:]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from Client:[HTTP_OBLIX_UID]=[cbrus16]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from Client:[HTTP_OBLIX_UID]=[cbrus16]
Wed Mar 20 15:01:10 2013 <202911363806070191> attempt #0 out of a max of 5
Wed Mar 20 15:01:10 2013 <202911363806070191> Server details are ''/0/0
Preferred server not set or was marked bad, checking next preferred server
Wed Mar 20 15:01:10 2013 <202911363806070191> Server details are ''/0/0
Preferred server not set or was marked bad, checking next preferred server
Wed Mar 20 15:01:10 2013 <202911363806070191> Trying a pooled connection for '10.13.52.81/7005/7006'
Wed Mar 20 15:01:10 2013 <202911363806070191> getPooledConn: No more connections in the pool for Host[10.13.52.81] Port[7005] SecurePort[7006]
Wed Mar 20 15:01:10 2013 <202911363806070191> general list: trying connect to '10.13.52.81'/7005/7006 at line 1676 for '/amserver/UI/Login?module=GMACLoginModule&org=branch'
Wed Mar 20 15:01:10 2013 <202911363806070191> INFO: New NON-SSL URL
Wed Mar 20 15:01:10 2013 <202911363806070191> Connect returns -1, and error no set to 245, msg 'Operation now in progress'
Wed Mar 20 15:01:10 2013 <202911363806070191> EINPROGRESS in connect() - selecting
Wed Mar 20 15:01:10 2013 <202911363806070191> Local Port of the socket is 63477
Wed Mar 20 15:01:10 2013 <202911363806070191> Remote Host 10.13.52.81 Remote Port 7005
Wed Mar 20 15:01:10 2013 <202911363806070191> general list: created a new connection to '10.13.52.81'/7005 for '/amserver/UI/Login?module=GMACLoginModule&org=branch', Local port: 63477
Wed Mar 20 15:01:10 2013 <202911363806070191> WLS info : 10.13.52.81:7005 recycled? 0
Wed Mar 20 15:01:10 2013 <202911363806070191> URL::sendHeaders(): meth='GET' file='/amserver/UI/Login?module=GMACLoginModule&org=branch' protocol='HTTP/1.1'
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[accept]=[image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */*]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[referer]=[https://capacity.dealerservices.ally.com/userprovisioning/jsp/autoSubmit.jsp?lang=en-us&source=MigratedLoginWidget&userType=branch&process=login]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[accept-language]=[en-US]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[user-agent]=[Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; BTRS99959; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MS-RTC LM 8; .NET4.0C; InfoPath.3)]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[accept-encoding]=[gzip, deflate]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[host]=[gdpcapacity.gmacbranch.gmac.gm.com]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[cache-control]=[no-cache]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[cookie]=[s_pers=%20s_ts%3D%255B%255B%2527BRA0006T%2527%252C%25271362265430952%2527%255D%252C%255B%2527BRA0005T%2527%252C%25271363804235955%2527%255D%255D%7C1521570635955%3B%20s_nr%3D1363805063050-Repeat%7C1366397063050%3B; Locale=en-us; MasterCookie=MasterCookie; GDP_screenHeight=768; GDP_screenWidth=1366; GDP_browserType=Microsoft%20Internet%20Explorer; GDP_browserVersion=4.0%20%28compatible%3B%20MSIE%208.0%3B%20Windows%20NT%206.1%3B%20Trident/4.0%3B%20BTRS99959%3B%20SLCC2%3B%20.NET%20CLR%202.0.50727%3B%20.NET%20CLR%203.5.30729%3B%20.NET%20CLR%203.0.30729%3B%20Media%20Center%20PC%206.0%3B%20MS-RTC%20LM%208%3B%20.NET4.0C%3B%20InfoPath.3%29; GDP_operatingSystem=Win32; GDP_userAgent=Mozilla/4.0%20%28compatible%3B%20MSIE%208.0%3B%20Windows%20NT%206.1%3B%20Trident/4.0%3B%20BTRS99959%3B%20SLCC2%3B%20.NET%20CLR%202.0.50727%3B%20.NET%20CLR%203.5.30729%3B%20.NET%20CLR%203.0.30729%3B%20Media%20Center%20PC%206.0%3B%20MS-RTC%20LM%208%3B%20.NET4.0C%3B%20InfoPath.3%29; JSESSIONID=RKHWGqJvmJGWgZ9YdqywsXBLRd7QtMGX1Qr1yTmNTn0Kcdq0M0xq!-1872775671; ObSSOCookie=tKGxD0YS6sUw8kyVwfVBNujGihNvtG5GlUrYljs%2F3fngJbUm4%2B1bA6FpLn3LEESIpQsqwhjMDZODuautF%2B7zHKXypTkT%2Fn8DwdGn%2FYZOJK49wBTU511DfkqBmqBMsGjSM42jobA5gSQ672vUQskytWaJc4tZQC7MDLOGPEJf%2Bwc%2BVtXRi1%2FRGI4ql8jQpyWSJP6ImkHwt6QNig3Vlyt9BLZws6vvgHulULaxuA%2BXfUZ4fkVaVwN35tAmWorUa1ODiORCWhVSrZybMhTk53NsjT%2FdOaXFLZM4wcj6PKVkeG1UtZVfoNuVw8LBBVd5ave0]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[gmacdealer_groups]=[smartcash:scsupervisor:branch:us:en-us:EOAdminUS:]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[HTTP_OBLIX_UID]=[cbrus16]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[HTTP_OBLIX_UID]=[cbrus16]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[Proxy-Path-Translated]=[u001/webserver/docs/gdp-capacity-backend-sec/amserver/UI/Login]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[Proxy-Path-Translated-Base]=[u001/webserver/docs/gdp-capacity-backend-sec]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[WL-Proxy-Client-Keysize]=[128]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[WL-Proxy-Client-Secretkeysize]=[128]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[WL-Proxy-Client-IP]=[129.41.252.30]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[WL-Proxy-SSL]=[true]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[Proxy-Client-IP]=[129.41.252.30]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[X-Forwarded-For]=[129.41.252.30]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[Connection]=[Keep-Alive]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[X-WebLogic-KeepAliveSecs]=[30]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[X-WebLogic-Request-ClusterInfo]=[true]
Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[x-weblogic-cluster-hash]=[7GHstOoW2dPEsRHcWrZe05SfKAc]
Wed Mar 20 15:01:11 2013 <202911363806070191> URL::parseHeaders: CompleteStatusLine set to [HTTP/1.1 302 Moved Temporarily]
Wed Mar 20 15:01:11 2013 <202911363806070191> URL::parseHeaders: StatusLine set to [302 Moved Temporarily]
Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs from WLS:[Date]=[Wed, 20 Mar 2013 19:01:10 GMT]
Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs from WLS:[Pragma]=[no-cache]
Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs from WLS:[Location]=[https://gdpcapacity.gmacbranch.gmac.gm.com/portal/dt?action=process&provider=PortletWindowProcessChannel&windowProvider.targetPortletChannel=GMACDataProvider&containerName=GMACBranchHomeContainer&windowProvider.currentChannelMode=VIEW&window.portletAction=ACTION]
Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs from WLS:[Content-Type]=[text/html]
Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs from WLS:[Expires]=[0]
Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs from WLS:[Set-Cookie]=[JSESSIONID=RKHW4QzDhbJpcQJJpXJ21CV3lxY2lbhNJYmtJCYGGK2BC71JTqGr!923706867; path=/]
Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs from WLS:[Set-Cookie]=[iPlanetDirectoryPro=AQIC5wM2LY4Sfcwgaa%2Bz8dzyN5AAXxW2GEBHoRwWjfYUb9M%3D%40AAJTSQACMDI%3D%23; path=/]
Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs from WLS:[Set-Cookie]=[AMAuthCookie=LOGOUT; expires=Thursday, 01-Jan-1970 01:00:00 GMT; path=/]
Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs from WLS:[X-AuthErrorCode]=[0]
Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs from WLS:[X-DSAMEVersion]=[6 2005Q1]
Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs from WLS:[Transfer-Encoding]=[chunked]
Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs from WLS:[Cache-Control]=[private]
Wed Mar 20 15:01:11 2013 <202911363806070191> parsed all headers OK
Wed Mar 20 15:01:11 2013 <202911363806070191> sendResponse() : uref_p->getStatus() = '302'
Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs to client (add):[date]=[Wed, 20 Mar 2013 19:01:10 GMT]
Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs to client (add):[Pragma]=[no-cache]
Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs to client (add):[Location]=[https://gdpcapacity.gmacbranch.gmac.gm.com/portal/dt?action=process&provider=PortletWindowProcessChannel&windowProvider.targetPortletChannel=GMACDataProvider&containerName=GMACBranchHomeContainer&windowProvider.currentChannelMode=VIEW&window.portletAction=ACTION]
Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs to client (add):[content-type]=[text/html]
Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs to client (add):[Expires]=[0]
Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs to client (add):[Set-Cookie]=[JSESSIONID=RKHW4QzDhbJpcQJJpXJ21CV3lxY2lbhNJYmtJCYGGK2BC71JTqGr!923706867; path=/]
Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs to client (add):[Set-Cookie]=[iPlanetDirectoryPro=AQIC5wM2LY4Sfcwgaa%2Bz8dzyN5AAXxW2GEBHoRwWjfYUb9M%3D%40AAJTSQACMDI%3D%23; path=/]
Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs to client (add):[Set-Cookie]=[AMAuthCookie=LOGOUT; expires=Thursday, 01-Jan-1970 01:00:00 GMT; path=/]
Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs to client (add):[X-AuthErrorCode]=[0]
Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs to client (add):[X-DSAMEVersion]=[6 2005Q1]
Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs to client (add):[Cache-Control]=[private]
Wed Mar 20 15:01:11 2013 <202911363806070191> canRecycle: conn=1 status=302 isKA=1 clen=-1 isCTE=1
Wed Mar 20 15:01:11 2013 <202911363806070191> closeConn: pooling for '10.13.52.81/7005'
Wed Mar 20 15:01:11 2013 <202911363806070191> request [amserver/UI/Login?module=GMACLoginModule&org=branch] processed successfully..................
Could some one let me know how to maintain the session stickiness and please do let me know why the JVM ID is getting changed.
Note : We are using cookie based replication in our environment.
Thanks & Regards
Arun

the CSS does not have the possibility to dynamically learn cookie.
So, you have to setup manually the value sent by each server.
According to your setup, the jsessionid would have a fix value after the first 33 bytes and the value will be 2 bytes long.
Is that correct ?
If yes, try to increase the string range.
Finally, it might be easier to use arrowpoint cookies.
Gilles.

Driver visa session looping issue

Similar Messages

Maybe you are looking for