Open GoogleCodeExporter opened 8 years ago
SOS
We are getting these messages pretty often:
Failures
An exception occurred while running test instance 'TestEntities'.
System.Runtime.Remoting.RemotingException: Port is Busy: All pipe instances are
busy.
Server stack trace:
at System.Runtime.Remoting.Channels.Ipc.IpcPort.Connect(String portName, Boolean secure, TokenImpersonationLevel impersonationLevel, Int32 timeout)
at System.Runtime.Remoting.Channels.Ipc.ConnectionCache.GetConnection(String portName, Boolean secure, TokenImpersonationLevel level, Int32 timeout)
at System.Runtime.Remoting.Channels.Ipc.IpcClientTransportSink.ProcessMessage(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream, ITransportHeaders& responseHeaders, Stream& responseStream)
at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage msg)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Gallio.Runtime.ProgressMonitoring.RemoteProgressMonitor.Forwarder.SetStatus(String status)
at Gallio.Runtime.ProgressMonitoring.RemoteProgressMonitor.SetStatus(String status) in c:\Server\Projects\MbUnit v3.2\Work\src\Gallio\Gallio\Runtime\ProgressMonitoring\RemoteProgressMonitor.cs:line 76
This is a relatively recent regression. Probably something we do in our tests,
though I cannot think of any criminal acts there.
Original comment by mark.kha...@gmail.com
on 20 Oct 2010 at 2:16
Can you reliably reproduce it?
Original comment by grahamr...@gmail.com
on 20 Oct 2010 at 2:37
I can, however, it is not possible to isolate in a short example, because it
happens when we run our integration tests, which means the (unit) test is the
client of some server, which in turns talks to the database. As you can see, I
cannot wrap it up and upload here.
However, I could collect diagnostics or run a debug build of gallio or whatever
to let you have enough input to identify and solve the problem.
Original comment by mark.kha...@gmail.com
on 20 Oct 2010 at 4:24
Run it as IsolatedAppDomain, if there are no problems then it is due to
remoting. In which case you need to identify which test or tests is causing the
problem.
Original comment by grahamr...@gmail.com
on 22 Oct 2010 at 8:35
Sounds like it's interfering with Gallio's own remoting. We should really drop
our use of .Net remoting and send directly messages over a domain socket or a
named pipe instead.
Original comment by jeff.br...@gmail.com
on 28 Nov 2010 at 11:35
We are having the same problem here - same exception. This, and some extremely
frustrating memory problems where running certain fixtures suddenly ups
Gallio.Host.exe memory usage to 2+GB (after 10 or 15 or so tests), then back to
the normal 50:ish MB, then back up to 2+GB, and so on. No idea if those are
related, but it all started happening roughly 3+ weeks ago. If I run only the
test(s) where memory goes down the drain, it's all fine. If I run around 10
tests at the time instead of the whole fixture, it's also fine.
We have not changed the Gallio version (3.1 Build 397), and all those tests
have been run over and over again for a long time, only to start failing now.
We are not using Remoting in our tests.
Occurs on both Windows 7 and Windows Server 2008 R2. It doesn't seem completely
unlikely that it's related to some Windows Update, but we haven't been able to
figure it out.
Original comment by mikael.r...@gmail.com
on 6 Feb 2011 at 11:11
Short update. I have been suspicious of the HTML output generation vs. having
large test suites, so we tried running Echo with text as output instead. This
time, we did manage to run it all without Remoting Exception and without memory
issues.
Instead, we got "System.CannotUnloadAppDomainException: Error while unloading
appdomain". However, we have seen this before and it's likely/hopefully
unrelated.
We'll continue to dig, but I am still puzzled why it suddenly became a problem.
Original comment by mikael.r...@gmail.com
on 7 Feb 2011 at 9:06
Thank you for the follow-up.
We've replaced the XSL-based engine to generate HTML reports by a faster engine
based on Castle NVelocity. But it's still only in the v3.3 trunk. And it's not
enabled by default yet. We will also provide a functionality to split large
HTML reports into several smaller child files.
It should be usable in the v3.3 trunk in a couple of weeks. And I expect it to
be available in v3.2.x release (maybe 4, after the next feature release) in the
current of year (summer?)
Original comment by Yann.Tre...@gmail.com
on 7 Feb 2011 at 9:18
Could you get us a dump when the memory usage is very high?
Original comment by grahamr...@gmail.com
on 7 Feb 2011 at 10:52
Original comment by Yann.Tre...@gmail.com
on 14 Jun 2011 at 5:48
Original comment by Yann.Tre...@gmail.com
on 14 Jun 2011 at 5:53
did you guys find any solution ,I am also facing same issue
Original comment by anurag....@gmail.com
on 7 Aug 2013 at 5:09
Original issue reported on code.google.com by
mark.kha...@gmail.com
on 19 Oct 2010 at 7:06Attachments: