Skip to main content

[jsr352-public] Re: MetricsTests#testMetricsJobExecutionTimestamps assertions too tight

  • From: Scott Kurz < >
  • To:
  • Subject: [jsr352-public] Re: MetricsTests#testMetricsJobExecutionTimestamps assertions too tight
  • Date: Thu, 15 Aug 2013 09:36:00 -0400


Michael,

Thanks for raising this issue.   We did some tests with MySQL at some point
and include a runtime (RI) as well as a TCK DDL, but I won't claim we ran
the final TCK against any particular version.

Yes, it seems we should loosen the assertion with a precision buffer.

Let me ask:  is this something delaying you from claiming 100% compliance?
Or is it just something you've realized which should be fixed?

Will try to prioritize based on the answer...

Thanks,
------------------------------------------------------
Scott Kurz
WebSphere Batch / Compute Grid Development
T/L 295-5649;
External Phone 845-435-5649

--------------------------------------------------------



From:   Michael Minella 
< >
To:     
" "
 
< >,
Date:   08/14/2013 05:46 PM
Subject:        [jsr352-public] Re:
            MetricsTests#testMetricsJobExecutionTimestamps assertions too
            tight



Sorry for the confusion.  After a bit more digging, I was making an
incorrect assumption.  However, my digging has introduced another question.
The TCK is validating the time in these two tests to millisecond precision.
However, if an implementation is using a database (say MySql) that does not
support millisecond precision (which MySql doesn't pre 5.6), the times get
rounded...sometimes down...sometimes up.  When it rounds up, the test
passes.  If it rounds down...the test fails.

Do we feel that being able to validate to the millisecond precision (which
will cause many implementations using a database for their job repository)
to perform some form of database schema hack to work worth it or would we
be willing to relax the validation to second level precision?  Below is an
example of what the round trip to a MySql database does to the create time.
As you can see, if it wasn't for the MySql behavior...the test would pass.
However in this scenario it doesn't.

I notice that the RI provides DDLs for MySql.  Does it pass the TCK when
run against MySql (pre 5.6)?  It wasn't obvious to me how to configure the
database so I didn't try it myself...

**** time just before insertion 1376515526426
AJM: testcase start time: 1376515526166<p>
AJM: job create time: 1376515526000<p>
AJM: job start time: 1376515526000<p>
AJM: job last updated time: 1376515527000<p>
AJM: job end time: 1376515527000<p>



Thanks,
Michael Minella

http://www.michaelminella.com


On Wed, Aug 14, 2013 at 1:20 PM, Scott Kurz 
< >
 wrote:
  Maybe we're both looking at the latest but I'm not seeing the problem.

  So we have for example on line 706:

  assertWithMessage("Start time of job occurs no sooner than start time of
  test",   ts.compareTo(execution1.getStartTime()) <= 0);

  You wrote:
  ...On my laptop, I'm getting intermittent failures due to the fact that
  the times are ending up being equal.

  But equal times results in a compareTo() value of '0', which should pass
  with a <=0 check, right?




  ------------------------------------------------------
  Scott Kurz
  WebSphere Batch / Compute Grid Development
  T/L 295-5649;
  External Phone 845-435-5649
  

  --------------------------------------------------------

  Michael Minella ---08/14/2013 01:43:38 PM---Scott, I just pulled the
  latest from the git repo on java.net and as you can see


  From: Michael Minella 
< >
  To: 
" "
 
< >,
  Date: 08/14/2013 01:43 PM
  Subject: [jsr352-public] Re:
  MetricsTests#testMetricsJobExecutionTimestamps assertions too tight




  Scott,

  I just pulled the latest from the git repo on java.net and as you can see
  in the listing here, the test is still verifying via <=.  Also, I
  re-downloaded the zip file and got the same results.  Unfortunately the
  git commit log is a bit sparse so I can't see if the changes were
  overwritten.  Any insight you can provide is appreciated.  Thanks in
  advance!

  Thanks,
  Michael Minella

  Thanks,
  Michael Minella
  

  http://www.michaelminella.com


  On Wed, Aug 14, 2013 at 11:57 AM, Scott Kurz 
< >
 wrote:
        Michael,

        We actually fixed the issue of wrongly failing on equal timestamps
        already  (we didn't do anything about the time format).

        We actually fixed it before the TCK version we tagged as
        "final" (from 4/22), though it was in very similar form before that
        final release so I don't blame anyone who missed the fine print
        there.

        Let me take this opportunity to point you to our TCK change
        history:
        https://java.net/projects/jbatch/pages/TCK_ChangeHistory

        As I wrote here, we're of course, not going to be changing TCKs
        without a careful justification (excepting the case when it's a
        very minor change).

        And the latest TCK (6/27) is at:
        https://java.net/projects/jbatch/downloads/download/jsr352-tck-1.0.zip


        Thanks for bringing this up,
        ------------------------------------------------------
        Scott Kurz
        WebSphere Batch / Compute Grid Development
        T/L 295-5649;
        External Phone 845-435-5649
        

        --------------------------------------------------------

        Michael Minella ---08/14/2013 12:43:48 PM---In the
        MetricsTests#testMetricsJobExecutionTimestamps() method, the
        assertions at the end validate t

        From: Michael Minella 
< >
        To: 
" "
 
< >,
        Date: 08/14/2013 12:43 PM
        Subject: [jsr352-public]
        MetricsTests#testMetricsJobExecutionTimestamps assertions too tight




        In the MetricsTests#testMetricsJobExecutionTimestamps() method, the
        assertions at the end validate that the job creation timestamp is
        not less than or equal to the start time for the test.  On my
        laptop, I'm getting intermittent failures due to the fact that the
        times are ending up being equal.  I would think that the test
        should validate that the time was not before but equal should be ok
        in this instance.  The same scenario occurs in
        MetricsTests#testMetricsStepTimestamps.

        As a side note, it would be helpful if the reporter output actually
        specified a date format instead of relying on toString so that
        consistent output is generated from the test and the
        implementation.

        testMetricsJobExecutionTimestamps
              Create job parameters for execution #1:


              app.processFilterItem=3


              Locate job XML file: testMetricsCommitCount.xml


              Invoke startJobAndWaitForResult for execution #1


              execution #1 JobExecution getBatchStatus()=COMPLETED


              AJM: testcase start time: Wed Aug 14 10:30:52 CDT 2013


              AJM: job create time: 2013-08-14 10:30:52.863


              AJM: job start time: 2013-08-14 10:30:52.864


              AJM: job last updated time: 2013-08-14 10:30:52.878


              AJM: job end time: 2013-08-14 10:30:52.878






        testMetricsStepTimestamps
              Create job parameters for execution #1:


              app.processFilterItem=3


              Locate job XML file: testMetricsCommitCount.xml


              Invoke startJobAndWaitForResult for execution #1


              Obtaining StepExecutions for execution id: 112


              execution #1 JobExecution getBatchStatus()=COMPLETED


              AJM: testcase start time: Wed Aug 14 10:30:53 CDT 2013


              AJM: step start time: 2013-08-14 10:30:53.73


              AJM: step end time: 2013-08-14 10:30:53.74




        Thanks,
        Michael Minella
        

        http://www.michaelminella.com





GIF image



[jsr352-public] MetricsTests#testMetricsJobExecutionTimestamps assertions too tight

Michael Minella 08/14/2013

[jsr352-public] Re: MetricsTests#testMetricsJobExecutionTimestamps assertions too tight

Scott Kurz 08/14/2013

[jsr352-public] Re: MetricsTests#testMetricsJobExecutionTimestamps assertions too tight

Michael Minella 08/14/2013

[jsr352-public] Re: MetricsTests#testMetricsJobExecutionTimestamps assertions too tight

Scott Kurz 08/14/2013

[jsr352-public] Re: MetricsTests#testMetricsJobExecutionTimestamps assertions too tight

Michael Minella 08/14/2013

[jsr352-public] Re: MetricsTests#testMetricsJobExecutionTimestamps assertions too tight

Scott Kurz 08/15/2013

[jsr352-public] Re: MetricsTests#testMetricsJobExecutionTimestamps assertions too tight

Michael Minella 08/15/2013
 
 
Close
loading
Please Confirm
Close