<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    On 19.04.2011 20:19, Eliot Miranda wrote:
    <blockquote
      cite="mid:BANLkTin9J8VsJr_hkWSbPxPNV5GU5-PPZw@mail.gmail.com"
      type="cite">Hi Henrik,<br>
      <br>
      <div class="gmail_quote">On Mon, Apr 18, 2011 at 1:23 AM, Henrik
        Sperre Johansen <span dir="ltr">&lt;<a moz-do-not-send="true"
            href="mailto:henrik.s.johansen@veloxit.no">henrik.s.johansen@veloxit.no</a>&gt;</span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          padding-left: 1ex;">
          <div class="im">On 17.04.2011 22:48, Chris Muller wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
            0.8ex; border-left: 1px solid rgb(204, 204, 204);
            padding-left: 1ex;">
            <div class="im">
              I was able to work on getting Magma 1.2 going in Pharo.
              &nbsp;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. &nbsp;All Magma functionality seems to work fine for
              low-volume<br>
              activity. &nbsp;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.
              &nbsp;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.
              &nbsp;What is it<br>
              doing? &nbsp;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.. &nbsp;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? &nbsp;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>
              &nbsp; 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. &nbsp;The limit is soft. &nbsp;It can be accessed using
          Smalltalk vmParameterAt: 49. &nbsp;It defaults to 256 entries. &nbsp;It
          maxes out it 64k entries because the value set via
          vmParameterAt: 49 put: X persists in a short in the image
          header. &nbsp;I expect 20k sockets to be sufficient for a while,
          right?<br>
        </div>
      </div>
    </blockquote>
    Ah, absolutely :D<br>
    <br>
    That's what I get for skimming readme's,&nbsp; think it'd be good to
    upgrade the comment though?<br>
    No specific mention is made that it can be(although frowned
    upon)/how to set it after startup, currently it reads:<br>
    "Another significant change is in the external semaphore table
    support code.&nbsp; <br>
    This is now lock-free at the cost of having to specify a maximum
    number of <br>
    external semaphores at start-up (default 256)."<br>
    <br>
    I guess having it accessible from image is one interpretation of
    that line, personally I thought it was that you could use some
    parameter when launching the executable :)<br>
    <br>
    Also, it's currently possible to register more than this limit in
    current images (Smalltalk registerExternalObject:) without an error.<br>
    Am I correct in my reading of the code that when this happens, they
    will never be signaled?<br>
    If so, we'd probably want to do some changes to
    ExternalSemaphoreTable :)<br>
    <br>
    Cheers,<br>
    Henry<br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
  </body>
</html>