Hi Henrik,<br><br><div class="gmail_quote">On Mon, Apr 18, 2011 at 1:23 AM, Henrik Sperre Johansen <span dir="ltr"><<a href="mailto:henrik.s.johansen@veloxit.no">henrik.s.johansen@veloxit.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 17.04.2011 22:48, Chris Muller wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
I was able to work on getting Magma 1.2 going in Pharo. It was quite<br>
easy to get the code loaded and functioning in Pharo 1.1.1, Pharo 1.2,<br>
and Pharo 1.3.<br>
<br>
But something seems to have changed in Pharo's networking from 1.1.1<br>
to 1.2. All Magma functionality seems to work fine for low-volume<br>
activity. However, when the test-suite gets to the HA test cases (at<br>
the end), one of the images performing heavy networking activity,<br>
consistently gets very slow and bogged down for some reason; causing<br>
the clients to timeout and disrupting the test suite. Fortunately, it<br>
happens in the same place in the test-suite every time.<br>
<br>
The UI of the image in question becomes VERY sluggish, but<br>
MessageTally spyAllOn: didn't reveal anything useful. What is it<br>
doing? I did verify that the Magma server in that image is still<br>
functioning; clients were committing, but I had to increase their<br>
timeouts from 10 to 45 seconds to avoid timeouts..<br>
<br></div><div class="im">
Unfortunately, two days of wrangling in Pharo (because I'm an old<br>
Squeak dog) I could not nail the problem down; but I have one<br>
suspect.. A couple of times, I caught a process seemingly hung up in<br>
NetworkNameResolver; trying to resolve an IP from 'localhost'.<br>
<br></div><div class="im">
This exact set of Magma packages is rock-solid on Pharo 1.1.1 and<br>
Squeak, but that doesn't mean the problem for sure lies in Pharo 1.2;<br>
maybe a networking bug in 1.1.1 is allowing Magma to "misuse" the<br>
network and get away with it and Pharo 1.2 is now more strict? I<br>
don't know, I would just like to ask the experts here for help who<br>
know all what went into Pharo 1.2 so hopefully we can get to the<br>
bottom of it.<br>
<br>
Thanks,<br>
Chris<br>
<br>
</div></blockquote>
Which VM did you run these tests on?<br>
IIRC, Cog has a hard limit on how many external semaphores are available, and each Socket consumes 3 of those.<br></blockquote><div><br></div><div>Not so. The limit is soft. It can be accessed using Smalltalk vmParameterAt: 49. It defaults to 256 entries. It maxes out it 64k entries because the value set via vmParameterAt: 49 put: X persists in a short in the image header. I expect 20k sockets to be sufficient for a while, right?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
So if you are running on Cog, the problem when under heavy load may be that there simpy aren't enough free external semaphores to create enough sockets...<br>
<br>
Cheers,<br>
Henry<br>
<br>
</blockquote></div><br>