From Jonny: There were also some cases that were resolved by disabling the TCP Chimney Offload feature.
http://support.microsoft.com/kb/942861
I tried that on both the SQL server machine and k2 server machine..it didnt solve it
Sounds like your socket connections are being broken. Might want to check the network utilization and also maybe check the number of open sockets on the K2 server (in case it is a socket leak on the code). You can run this from a command prompt on the K2 server to check the number of connections.
netstat –a –n |findstr :5252
Similar Error. I'm running something of a heartbeat test on 4 servers. First time works, last 2 servers throw an exception which I catch below related to auth. At first I thought no big deal it's leaving the connect open on the Exceptions, so I closed it explicitly. Technically it apears to be isolated to the Management Instance which does not have an explicit dispose that I could see. Quirky but perhaps something worth looking into:
Stack Trace, followed by netstat, followed by code which generated the error (Ran inside Console app)
SourceCode.Hosting.Exceptions.APICommunicationException: Error Receiving Buffer ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
at System.Net.Sockets.Socket.Receive(Bytet] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
at SourceCode.Hosting.Client.BaseAPI.BaseAPIConnection.ReceiveBuffer(ByteB] recvBuff)
--- End of inner exception stack trace ---
at SourceCode.Hosting.Client.BaseAPI.BaseAPIConnection.ReceiveBuffer(Bytef] recvBuff)
at SourceCode.Hosting.Client.BaseAPI.BaseAPIConnection.RecvHeader()
at SourceCode.Hosting.Client.BaseAPI.BaseAPIConnection.WindowsAuthentication(SCConnectionStringBuilder connectionStringBuilder)
at SourceCode.Hosting.Client.BaseAPI.BaseAPIConnection.Authenticate(String connectionString)
at SourceCode.Hosting.Client.BaseAPI.BaseAPIConnection.Open(String connectionString)
TCP 0.0.0.0:5252 0.0.0.0:0 LISTENING
TCP 0.0.0.0:5555 0.0.0.0:0 LISTENING
TCP 172.18.82.161:57580 172.18.76.34:10108 ESTABLISHED
TCP 172.18.82.161:57598 172.18.76.34:10108 ESTABLISHED
UDP 0.0.0.0:500 *:*
UDP 0.0.0.0:5355 *:*
UDP 127.0.0.1:50118 *:*
UDP 127.0.0.1:52445 *:*
UDP 127.0.0.1:53517 *:*
UDP 127.0.0.1:54711 *:*
UDP 127.0.0.1:54713 *:*
UDP 127.0.0.1:55320 *:*
UDP 127.0.0.1:56869 *:*
UDP 127.0.0.1:56871 *:*
UDP 127.0.0.1:58607 *:*
UDP ::]:500 *:*
public bool TestServer(SCConnectionStringBuilder conn)
{
bool pass = true;
WorkflowManagementServer managementServer = new WorkflowManagementServer();
Connection workflowServer = new Connection();
try
{
managementServer.CreateConnection();
managementServer.Connection.Open(conn.ConnectionString);
managementServer.GetErrorProfile("All");
managementServer.Connection.Close();
managementServer.DeleteConnection();
}
catch (Exception ex)
{
Console.WriteLine(ex.ToString());
managementServer.Connection.Close();
managementServer.DeleteConnection();
pass = false;
}
try
{
conn.Port = 5252;
workflowServer.Open(conn.Host, conn.ConnectionString);
string foo = workflowServer.GetUserStatus().ToString();
workflowServer.Close();
workflowServer.Dispose();
}
catch (Exception ex)
{
Console.WriteLine(ex.ToString());
workflowServer.Close();
workflowServer.Dispose();
pass = false;
}
return pass;
}
Hi,
I'm not sure why you are getting the exception, but the WorkflowMangementServer.Connection object has an explicit Dispose() which you can call to dispose of the connection. I'm not sure if you will actually need the DeleteConnection() method thereafter, so test with and without it.
Hope this helps!
Did you ever get this fixed? I am having the same issue.
thanks
if you are using the factory design pattern as a wrapper to the k2 then stop it. Instead use objects provided by the K2 directly like the connection, process...etc.
I am following an example I downloaded from K2 Underground. here is the snippet:
//use K2 management API to retrieve list of processes
//open connection to workflow management server
WorkflowManagementServer svr = new WorkflowManagementServer(_k2server, _k2port);
svr.Open();
ProcessSets procSets = svr.GetProcSets();
foreach (ProcessSet procSet in procSets)
{processes.Add(procSet.FullName);}
Are you saying there is a different way of handling this?
thanks
Hi jdrockwell,
I think your code segment is missing the srv.CreateConnection() method which initiates the connection.
When you open the connection I think you need to also do it like this: srv.Connection.Open() method instead of srv.Open().
Call the CreateConnection() method before you open the connection.
Let us know if this works.
I did finaly find a solution to my problems. It may have been the problem all along with my code.
I say mine because I'm not certain if it applies to the original case, perhaps it does although his is a write operation where mine is read.
The solution was a problem with my code. I created connections as Management connections 5555, then I call a workflow test using the same conn but set the port to 5252. I never set it back so the ops my code was running was against the wrong listening port. The test workflow server/engine resets the port to 5555 which is the port most of my operations are running against and all is well.
Whether that is BasharA's problem or not I couldn't say however a x.Write(conn.Port) just before the point of failure would answer the question whether the impersonate is being run against the wrong port.
Congratulations czbear glad you got it fixed and thanks for posting back the solution!
Hi,
RESOLUTION
I ran into the same issue where a WFE, IIS, K2, SQL is installed on separate environments. When a user opens their worklist they were getting that error. The same error even when connecting SMO Tester utility.
Checking the IIS and K2 logs the requests are redirected somehow to another machine (most likely to a LB) .
Modifying the host machine file (except SQL server) to point to the k2 server resolved the error. Now everything works fine.
Hope this helps.
Binyam
