RAM stateless Asset problem

Our RAM will happen the asset stateless problem one or two days once. When it happens, anyone create asset will get an empty status. We find the solution is in the RAM->Configuration->input the RTC admin password again , then it is no problem.

But it is not convenience for us to always set it because it is Random issue. We find it is caused by RAM was server do the web identity authenticate 2hours once, when it fail then never check RTC connection again.

In the RAM->Configuration-> RTC config, there is a time out value 120, anybody know it is minute? How it use for?

Thanks.

Using a default time out, I've never had any problem. In general, my activities are low.
What version do you have?

When I installed the 7.5.0.1 in a WAS 6.1, I went invited to apply some fixes on the WAS, this fix issues between RAM and RTC communications.

Hi Rramos,

We are using RAM 7.2.5 test fix 5, is that means we must upgrade to RAM 7.5 to fix this problem?

Could you tell me which test fix in version 7.5 regarding with this RTC problem?

Thanks.

On 3/10/2011 2:38 AM, pantian wrote:

Hi Rramos,

We are using RAM 7.2.5 test fix 5, is that means we must upgrade to
RAM 7.5 to fix this problem?

What is version 7.2.5? There is no 7.2.5. There is a 7.2.0.2, 7.5, and
7.5.0.1, and soon a 7.5.0.2.

But you have some other major problem if you have a failure every two
hours. We have some installations that have been up for months non-stop
and haven't had the RTC connection dropping.

The 120 timeout is how many seconds to wait whenever RTC is contacted.
If RTC is down then the request would time out. If this is timing out a
lot then you have an RTC problem. RAM cannot run at all without RTC.

This same kind of problem can happen with the database. If the password
expires things fail.

--
Rich Kulp
Rational Asset Manager developer

Hi Rich,
Sorry, I made mistake, our RAM version is 7.2.0.2, fix pack 6.

I believe this is RTC connection problem is because each time when this error occurred, our fix is in the "RAM->Administration->Config->Internal Rational Team Concert Path", input the RAM admin user password again, then the problem gone. Our password never change, just need to input the password every time when the stateless error show.

It is glad to hear your 7.5 version has fixed this issue, we will check if can upgrade to 7.5 to fix this problem, so what we want to know is which fix pack in 7.5 can resolve this problem.

Thanks.

On 3/15/2011 10:08 PM, pantian wrote:

Hi Rich,
Sorry, I made mistake, our RAM version is 7.2.0.2, fix pack 6.

I believe this is RTC connection problem is because each time when
this error occurred, our fix is in the
"RAM->Administration->Config->Internal Rational Team
Concert Path", input the RAM admin user password again, then
the problem gone. Our password never change, just need to input the
password every time when the stateless error show.

That doesn't make any sense. I'm wondering if you having an Websphere
LTPA problem. 120 minutes is also the timeout period for Websphere LTPA
tokens. LTPA tokens are the cookies Websphere uses for SSO and
authentication of a user. They become invalid every 120 minutes. But the
RTC client we use in the code should automatically log back in again
with the same password and by doing that create a new LTPA token. That
is what happens automatically on every one else's system.

If you go to the config page and re-enter the password then you are
doing essentially the same thing. When you hit save RAM logs out of RTC
and then logs back in again with the password you typed in. This creates
a new LTPA token.

We've seen this once before when there was a flaky LDAP connection or a
flaky Custom Websphere authentication adapter. What would happen is most
of the time when the LTPA cookie was invalid RAM would be able to
reconnect to RTC. But every once in a while when RAM went back to
re-login the Websphere LDAP authenticator on the RTC server itself would
return that the userid/password RAM had supplied to RTC was invalid.
When that happens RAM does not automatically try again. We don't want
RAM to lock up a brand new password by trying on old invalid one over
and over. It will try again only when a user explicitly types in a
password on the config page and hits save. It then assumes the user
knows what he is doing.

--
Rich Kulp
Rational Asset Manager developer

Hi Rich,

Thank you for your reply. Could you help to confirm the following things:
1) How the RTC do the authorization ? It is base on the LTPA token or not? I think the first time we use the admin user name/password which defined in RAM configuration to connect to RTC, it just verify password, but after that it will use LTPA instead or other way?

2) You mean the problem occurred because LTPA once invalid then RTC will never connect to RAM until user input the user name/password again, this is to prevent the lock of RTC. So how can we simulate the LTPA invalid and track the RTC behavior? Some actions we can do to reproduce this and get some idea from RTC? Because this problem happen one or two days once, we can not specify the detail time it occur.

3) When this problem happen, our Application and RAM still can login, just the RTC create task has problem, it that means the LTPA verify in RTC has problem but in RAM is passed?

Hi,

On 3/16/2011 11:23 PM, pantian wrote:

Hi Rich,

Thank you for your reply. Could you help to confirm the following
things:
1) How the RTC do the authorization ? It is base on the LTPA token or
not? I think the first time we use the admin user name/password which
defined in RAM configuration to connect to RTC, it just verify
password, but after that it will use LTPA instead or other way?

It is not RTC that is doing this. This is controlled by Websphere.
Websphere uses a cookie called an LTPA token. It is encrypted and if it
is found in the HTTP request and it is valid (still active, hasn't timed
out and is for this server/system) then the user is automatically logged
in without any further interaction. If token is missing or is invalid or
has timed out then Websphere responds with validation required and the
RTC client understands this "validation required" return code. It then
proceeds to do a regular HTPP login passing in userid and password.
Websphere then validates this information against its LDAP (using an
authentication adapter configured for that system) to verify the userid
and password. If they are valid Websphere returns a new LTPA cookie that
would be used on subsequent calls and the user is now logged in.

2) You mean the problem occurred because LTPA once invalid then RTC
will never connect to RAM until user input the user name/password
again, this is to prevent the lock of RTC. So how can we simulate the
LTPA invalid and track the RTC behavior? Some actions we can do to
reproduce this and get some idea from RTC? Because this problem
happen one or two days once, we can not specify the detail time it
occur.

You can't simulate. You need to look at your logs that the RTC is
running on and see why it is invalidating and not accepting the login
request. Look at the Websphere FFDC logs too.

3) When this problem happen, our Application and RAM still can login,
just the RTC create task has problem, it that means the LTPA verify
in RTC has problem but in RAM is passed?

That is correct. Those are two different sessions. One is a user session
to RAM and the other is an internal session between RAM and RTC. The one
for the user could have the same problem but the user would simply just
login again and it would work. The problem I was talking about that
someone else had was that this glitch was intermittent and if you tried
again immediately it would work. But we don't do this for the internal
session because we have no idea whether this is a valid rejection or
not. If it was a valid rejection and we tried again we could lock out
the RTC user by trying too many times.

--
Rich Kulp
Rational Asset Manager developer