Skip to main content

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

  • From: Michael Minella < >
  • To: " " < >
  • Subject: [jsr352-public] Re: MetricsTests#testMetricsJobExecutionTimestamps assertions too tight
  • Date: Wed, 14 Aug 2013 16:45:53 -0500

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
> 
> --------------------------------------------------------
>
> [image: Inactive hide details for Michael Minella ---08/14/2013 01:43:38
> PM---Scott, I just pulled the latest from the git repo on java]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*<http://java.net/
> and
> as you can see in the listing 
> *here*<https://java.net/projects/jbatch/sources/jsr-352-git-repository/content/JSR352.Tests.TCK/src/com/ibm/jbatch/tck/tests/jslxml/MetricsTests.java?rev=1cc2b7f6667241a80a6befb21e18d21ff36b77bb>,
> 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* ;<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*<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*<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* <845-435-5649>*
>    
> ** *
>  
> < >
>    --------------------------------------------------------
>
>    [image: Inactive hide details for Michael Minella ---08/14/2013
>    12:43:48 PM---In the MetricsTests#testMetricsJobExecutionTimestamps() 
> m]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* ;<http://www.michaelminella.com/>
>
>
>


[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