HostServer throwing exceptions after upgrade to K2 Blackpearl 4.6.11

2k Views Asked by At

We just upgraded K2 from version 4.6.6 to 4.6.11 on our environments. There are two K2 servers in the environment with a load balancer setup. After the upgrade, some of the functions from K2 workflow API are throwing exceptions.

"Error","EnvironmentServer","15100","Generic","SourceCode.Workflow.Runtime.Management [OpenConnection [string[] names]]","15100 Error occurred, ERROR: Unable to connect to loadbal-k2-abc.com on port 5252. A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. ","anonymous","0.0.0.0" "Error","EnvironmentServer","15100","Generic","SourceCode.Workflow.Runtime.Management [SendArchiveX [string[] names]]","15100 Error occurred, ERROR: Unable to connect to loadbal-k2-abc.com on port 5252. A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. ","anonymous","0.0.0.0" "Error","EnvironmentServer","15101","Generic","SourceCode.Workflow.Runtime.Management [ReleaseWorklistItem [string[] names]]","15101 Error occurred, ERROR: Unable to connect to loadbal-k2-abc.com on port 5252. A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. ","anonymous","0.0.0.0" "Error","System","2025","InternalMarshalError","SourceCode.Hosting.Server.Runtime.HostServerBroker.InternalMarshal","2025 Error Marshalling SourceCode.Workflow.Runtime.Management.WorkflowManagementHostServer.ReleaseWorklistItem, Unable to connect to loadbal-k2-abc.com on port 5252. A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. ","","", "Error","System","2025","InternalMarshalError","SourceCode.Hosting.Server.Services.TCPClientSocket.InternalMarshal","2025 Error Marshalling SourceCode.Workflow.Runtime.Management.WorkflowManagementHostServer.ReleaseWorklistItem, Unable to connect to loadbal-k2-abc.com on port 5252. A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. " "Error","Communication","8060","ProcessPacketError","SourceCode.Hosting.Server.Services.TCPClientSocket.ProcessMessage","8060 ProcessPacket Error, Unable to connect to loadbal-k2-abc.com on port 5252. A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. "

In the HostServer logs, we can see that the K2 servers are for some reason trying to contact the K2 load balancer. This looks like a change from K2 4.6.6 where this worked perfectly and there were no calls to the load balancer. We also checked the K2 configuration and the load balancer address is not mentioned anywhere.

We also upgraded on an environment without load balancer and it is working without any errors there.

Why is K2 host server trying to connect to the load balancer in K2 4.6.11 and where does it get the address from?

1

There are 1 best solutions below

0
On BEST ANSWER

This was resolved with the help of K2 support. There were changes in the way K2 makes connections and the way we made connection string needed to be changed.

This was introduced in 4.6.11 with the SSO changes (TFS 524432 - SSO Prompt for Credential cache). In 4.6.10, when you Authenticate a HostServer session with the following connection string:

Integrated=True;IsPrimaryLogin=True;Authenticate=True;EncryptedPassword=False;Host=k2.denallix.com;Port=5555;UserID=Denallix\Administrator;Password=K2pass!;WindowsDomain=denallix;SecurityLabelName=K2

the connectionstring associated with the session is: Integrated=True;IsPrimaryLogin=True;Authenticate=True;EncryptedPassword=False;Host=dlx;Port=5555;UserID=DENALLIX\Administrator;Password=K2pass!;AuthData=Denallix;SecurityLabelName=K2

So the WindowsDomain key wasn't persisted pre SSO and instead it was added as AuthData (pay attention to the end of sample connection strings above).

When you open a connection from the WorkflowManagmentServer to the WorkflowClient, there is a check to see if the connection has a WindowsDomain, Username and Password. If it had all 3, it would try and use those details to Auth a user, in 4.6.10 we didn't persist the WindowsDomain, it would just do a normal integrated connection string without the username and password.

Essentially with such configuration you are trying to authenticate with the following credentials WindowsDomain + UserID which leads to use of something like "Domain\Domain\User" for authentication and authentication attempt will fail because of that.