Error deploying to Websphere

[Anon Anon]

A specific user is getting the following error when deploying an application to Websphere using CA Release Automation:

 

WAS - Get Application Status
Error creating connection. Possible reasons: Server down, wrong port. (Error code: WASX7023E). (Exit value: 105)
 

Server : xxxxx
Start : 29/08/16 15:49
End : 29/08/16 15:50

 

But if a different user run the same deployment plan then the deployment is finished successfully.

 

Do you know what could be causing this error?

[Keith Puzey]

Hi,

   As part of the deployment plan are you using release / environment parameters and are both users deploying to the same environment / agents? Can you check the agent log that is running the websphere action to confirm what the websphere connection details are.

 

Regards

Keith

[Anon Anon]

Hi,

 

1) are you using release / environment parameters ?

Yes. Environment Parameters

 

2) are both users deploying to the same environment / agents ?

Yes.

 

3) Can you check the agent log that is running the websphere action to confirm what the websphere connection details are?

Which logs? Which information should I look for?

I collected all the logs from the agent using the ASAP and it retrieved 111 log files.

 

Thanks.

[Gregg Stewart]

In regards to which logs, the nolio_action_all.log will normally have something related to this error. You might find something there if you search for "Executing command".

 

In regards to the error I think this can happen for one of two possible reasons:

1. the owner of the release automation agent process (Iinux or windows?) does not have access/permissions to websphere's wlst.sh file/folder; or

2. you're trying to the action without the username/password fields filled out which:

a. relies on the agent's process owner to have access to the soap.client.props file (which is commonly found in  profiles/<profilename>/properties folder); and

b. the soap.client.props being configured correctly.

 

If you supply a username/password to the action does it work? If so then permissions to the wlst.sh is okay and it is likely a matter of permissions to access the soap.client.props file, and the soap.client.props file being setup properly (which you can test outside of RA). If I am not mistaken I think the action has a field for specifying a directory. If the soap.client.props file is being used (due to the absence of supplying username/password to the action) then the action, if i'm not mistaken checks for that soap.client.props file by taking the the bin folder supplied through the action and looking for it in the ../properties folder. So you'll probably need to make sure that the bin folder you specify is also the correct bin folder by verifying that <the folder you give in the action>/../properties/soap.client.props is available.

 

Regards,
Gregg

[Anon Anon]

Hi Gregg,

 

1. the owner of the release automation agent process (Iinux or windows?) does not have access/permissions to websphere's wlst.sh file/folder;

We checked that and our Websphere does have access/permissions to wlst.sh file/folder.

 

2. you're trying to the action without the username/password fields filled out which(...)

All of our websphere actions have the username/password fields filled out.

 

I also checked ALL the logs running the following command and I got 0 results back:

$ grep -i 'Executing command' *

 

The bizarre thing about this problem is that with user 1 the same process/deployment ran without errors and then with user 2 we got the error. After a while the same user 2 tried to run again and mysteriously the process/deployment ran without any errors.

 

Thanks,

Eduardo

[Gregg Stewart]

Hi Eduardo,

 

Bizarre indeed. When you say user 1 and user 2, is this the username supplied in the username field of the action? Or, is your action using the "Set credentials" feature to have the action execute as another user - and you're referring the user specified there? 

 

Does this behavior reproduce itself if you run the action as one user and then run it immediately after with the second user?

 

Kind regards,

Gregg

[Anon Anon]

Hi Gregg,

 

User 1 and user 2 are the usernames supplied in the username field of the action.

 

There's is no apparent pattern to reproduce this behavior.

The error was happening every time for one of the users and after the other user ran the action successfully the first was able to run without errors too. After that, both of the users are executing the same process/deployment successfully.

 

Here is a screenshot of one the actions that were failing to execute that day.

was_user and was_password are input parameters that the executing user must enter to complete de deployment process. 

 

[Gregg Stewart]

Hi Eduardo,

 

Sorry we couldn't nail down the problem while you were experiencing it. But if you suddenly do have the problem again (on the same machine) then I would recommend opening a support issue and attaching the logs directory zipped for the NAC, NES, and Agent. The agent logs are most important but I'd rather get more information and not need it then not enough and need it.

 

If it is a condition that constantly occurs then the Agent's log (usually nolio_action_exe.log is sufficient, but if not then nolio_all.log) will help you figure out the issue. And for actions that are configured to use impersonation features there is an additional log that is very helpful. It is named <username>_output.log.

 

Kind regards,

Gregg

[Dirk Bleyenberg]

Hi Eduardo,

Did the s answer from Gregg answered your question? If it did please mark it as the right answer. When your question is not answered or you still have additional questions please let us know.

With Kind Regards

[Anon Anon]

Hi,

He tried to help me but we didn´t get to the root cause of the problem.

For me this remains without an answer.

 

Thanks,

Eduardo

[Dirk Bleyenberg]

Hi Eduardo ,

 

As the problem does not occur anymore , the only advice we can give at the moment is

to raise a support case and provide us with the logs , this is not common problem which has a simple

single answer and we need to investigate this .

The first place to check is the nolio_action_all.log  as gregg mentioned .

 

I will mark this one as answered for now , if the problem reoccurs again feel free to create a new question or raise a

support case so we can investigate the root cause .

 

Regards Dirk