Ant task to log off
10 answers
RAM guards against automated processes that access RAM programmatically without reusing sessions. It is a common problem where scripts access the RAM server without sending back the session cookie. This creates a new session per request which holds resources for ~30minutes.
A limit for the number of sessions that can be created for a single uid is on the Administration->Configuration page (I think that the default is 100).
If you are using an Ant Script, make sure to use the same session e.g.,
The session above has the id="ramServer" ... you can use that session throughout your script. e.g.,
A limit for the number of sessions that can be created for a single uid is on the Administration->Configuration page (I think that the default is 100).
If you are using an Ant Script, make sure to use the same session e.g.,
<ram:server id="ramServer" url="${ram.url}" username="${ram.uid}" password="${ram.password}" />
The session above has the id="ramServer" ... you can use that session throughout your script. e.g.,
<ram:modify server="ramServer">
RAM guards against automated processes that access RAM programmatically without reusing sessions. It is a common problem where scripts access the RAM server without sending back the session cookie. This creates a new session per request which holds resources for ~30minutes.
A limit for the number of sessions that can be created for a single uid is on the Administration->Configuration page (I think that the default is 100).
If you are using an Ant Script, make sure to use the same session e.g.,
<ram>
The session above has the id="ramServer" ... you can use that session throughout your script. e.g.,
<ram>
Yes, we're doing all of that.
The problem is when we run lots of different scripts to do different things.
For example, we run one set of scripts to do the RAM Upload. That is tried to the release processes of our software.
Then, we have an entirely different set of scripts that are run at separate times to create the (affore mentioned) Deployment Requests.
The value of the RAM Server can not be preserved across these separe calls to Ant (via Maven, in our case). So there are lots of separate interactions with RAM, not one large one, that can preserve the RAM Server/SessionId.
Yes, the session is released, eventually around 30 minutes later, which is not a good thing.
Hence, i run into the issue. :D
-Chris
p
responded) this shouldn't be necessary. The code should be logging off
when the ANT build is finished. We have a build listener attached, so
any short script should connect, do its thing, then log off when the ANT
ends.
--
Rich Kulp
Rational Asset Manager developer
Rational Asset Manager developer
Hi Rich.
Sorry, whom are you asking to open the Enhancement Request?
-Chris
I was asking you, but now talking to our developer (Eric, who has
responded) this shouldn't be necessary. The code should be logging off
when the ANT build is finished. We have a build listener attached, so
any short script should connect, do its thing, then log off when the ANT
ends.
--
Rich Kulp
Rational Asset Manager developer
7.5.0.2 for both. The jars were obtained from the ramclient.zip from the 7.5.0.2 server.
And, no, it does not automatically close the session (by definition of this problem, otherwise I'd never see it...)
-Chris
And, no, it does not automatically close the session (by definition of this problem, otherwise I'd never see it...)
-Chris
What version of the RAM client are you using? There may be some fixed
bugs in this area if you are using an older one.
Also what version of RAM Server are you talking to? Same thing as above
about bugs.
--
Rich Kulp
Rational Asset Manager developer
And, no, it does not automatically close the session (by definition of this problem, otherwise I'd never see it...)
Do you see anything in the Ant log (using -v) about releasing the session (e.g. Releasing session for user admin on server http://localhost:8080/ram)? If so, we're trying to release the session and for some reason it's not working. If not, we're not even getting to the point where we try to release the session.
Actually, we're running it under Maven, using the antrun plugin (so I needed a -X :-) )
Anyway, yes I did see the releasing line.
I tried kicking the server a bit, but I could now, not fault it.
(There is much work being performed on the RAM server itself, perhaps it has been resolved?)
It's been a week or so since I've seen this issue. I'll continue to monitor it.
Thanks for the help!
-Chris
Do you see anything in the Ant log (using -v) about releasing the session (e.g. Releasing session for user admin on server http://localhost:8080/ram)? If so, we're trying to release the session and for some reason it's not working. If not, we're not even getting to the point where we try to release the session.
Anyway, yes I did see the releasing line.
I tried kicking the server a bit, but I could now, not fault it.
(There is much work being performed on the RAM server itself, perhaps it has been resolved?)
It's been a week or so since I've seen this issue. I'll continue to monitor it.
Thanks for the help!
-Chris
And, no, it does not automatically close the session (by definition of this problem, otherwise I'd never see it...)
Do you see anything in the Ant log (using -v) about releasing the session (e.g. Releasing session for user admin on server http://localhost:8080/ram)? If so, we're trying to release the session and for some reason it's not working. If not, we're not even getting to the point where we try to release the session.