db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Satheesh Bandaram <sathe...@Sourcery.Org>
Subject Re: [jira] Updated: (DERBY-230) "Schema already exists" when creating a table
Date Fri, 03 Jun 2005 17:02:52 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<body bgcolor="#ffffff" text="#000000">
This patch is committed. Changes look good.<br>
Transmitting file data ...<br>
Committed revision 179834.<br>
&Oslash;ystein Gr&oslash;vlen wrote:
<blockquote cite="midx1ofd5r5vw9f.fsf@atum11.Norway.Sun.COM" type="cite">
  <blockquote type="cite">
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">"A" == Army  <a class="moz-txt-link-rfc2396E" href="mailto:qozinx@sbcglobal.net">&lt;qozinx@sbcglobal.net&gt;</a>
  <pre wrap=""><!---->
    A&gt; &Atilde;&#732;ystein Gr&Atilde;&cedil;vlen (JIRA) wrote:

    &gt;&gt; Attaching  a new version  of the  patch where  I have  increased the
    &gt;&gt; probability of the test reproducing the bug by increasing the number
    &gt;&gt; of threads to 200. It now fails  16 out of 20 times on a single-CPU
    &gt;&gt; machine.  Increasing the number of threads further seems to increase
    &gt;&gt; the  execution  time  very  much.  Considering  that  when  running
    &gt;&gt; derbyall, the test  is run three times in  different frameworks, the
    &gt;&gt; probability  of the  test suite  detecting the  rebirth of  this bug
    &gt;&gt; should be more than 98%. On  a 2-CPU machine the test failed 20 out
    &gt;&gt; of 20 times.

I think I have to back out on the increase to 200 threads.  Once in a
while the test now seems to fail with lock timeouts.  Apparently the
contention for the single lock pool gets to high.  (This happens all
the time if I use 500 threads).  Hence, I will change back to 100
threads and attach the new patch to the Jira issue.

    A&gt; Thanks for looking  into this more. Given that, as  you said, this is
    A&gt; pretty minor bug, and seeing has  no one else has spoken up to object,
    A&gt; I guess this seems like an acceptable approach for now.

    A&gt; So  I give  it a  +1, with  one question:  the latest  patch  that you
    A&gt; submitted had the following at the top:

    A&gt; -- &lt;begin patch paste&gt; --

    A&gt; Property changes on:
    A&gt; ___________________________________________________________________
    A&gt; Name: svn:ignore
    A&gt;     - classes
    A&gt; changenumber.properties
    A&gt; jars
    A&gt; javadoc

    A&gt;     + .ignore
    A&gt; *.diff
    A&gt; classes
    A&gt; jars
    A&gt; TAGS
    A&gt; testdir

    A&gt; -- &lt;end patch paste&gt; --

    A&gt; Your previous  patches didn't have this  in it, and I'm  not sure what
    A&gt; this  is doing.  Do you  know,  or was  this accidental?  If it  was
    A&gt; accidental, then my "+1" vote would be on the assumption that this was
    A&gt; removed. If it's intentional, then  can you tell me briefly what this
    A&gt; is doing?

It is a result of me playing around with the ignore property to see if
I could get svn to ignore some files I had put into the trunk
directory.  I guess I should just learn to place my files somewhere
else.  I will fix this in the new patch.


View raw message