recent HashCrypt changes, and using salt-based password hashing

[Adam Heath-2]

As some may have noticed, I recently changed the way ofbiz creates
password hashes when it stores them in the database.  Each time a new
password is created, a bit of randomness is used, to create a
random-length, random-content salt.  This is placed at the beginning
of the hashed password, stored along with it in the database.

Then, when it comes time to compare passwords, the salt is extracted,
and used to re-hash.

If someone continously changes their password to the same value,
you'll end up getting different raw hashed values in the database.  It
also increases the workload for crackers, and makes rainbow tables
much less fruitful.

I wrote this change over 2 years ago, in direct response to the jira
intrusion that happened.

[Jacques Le Roux]

Looking forward for
https://issues.apache.org/jira/browse/OFBIZ-1151
https://issues.apache.org/jira/browse/OFBIZ-2729
https://issues.apache.org/jira/browse/OFBIZ-3006

Jacques

From: "Adam Heath" <[hidden email]>

> As some may have noticed, I recently changed the way ofbiz creates
> password hashes when it stores them in the database.  Each time a new
> password is created, a bit of randomness is used, to create a
> random-length, random-content salt.  This is placed at the beginning
> of the hashed password, stored along with it in the database.
>
> Then, when it comes time to compare passwords, the salt is extracted,
> and used to re-hash.
>
> If someone continously changes their password to the same value,
> you'll end up getting different raw hashed values in the database.  It
> also increases the workload for crackers, and makes rainbow tables
> much less fruitful.
>
> I wrote this change over 2 years ago, in direct response to the jira
> intrusion that happened.

[Adam Heath-2]

On 04/19/2012 04:28 PM, Jacques Le Roux wrote:
> Looking forward for
> https://issues.apache.org/jira/browse/OFBIZ-1151
> https://issues.apache.org/jira/browse/OFBIZ-2729
> https://issues.apache.org/jira/browse/OFBIZ-3006

2729 doesn't apply for what I am doing.  Here's the list of things
that this solves:

1: salt-based UserLogin.currentPassword
   (done, I have a fix for the recent issue locally)
2: salt-based CreditCard.cardNumber encrypted value
   (s/b done tonight)
3: salt-based EntityKeyStore.keyText
   (s/b done tonight)
4: key-encrypting-key for EntityKeyStore.keyText.  The
key-encrypting-key will be available somewhere in ${ofbiz.home.dir}.
   (need to read java security doco)

I've currently rewritten a bunch of EntityCrypto already to fix the
issues I posted into the jira issue.  I'm now at the point I can start
adding new features.

This set of changes I currently have are rather straight forward, just
moving code around.  When I finally get around to adding the new
features, then there is a very definate chance of breaking stuff.

>
> Jacques
>
> From: "Adam Heath" <[hidden email]>
>> As some may have noticed, I recently changed the way ofbiz creates
>> password hashes when it stores them in the database.  Each time a new
>> password is created, a bit of randomness is used, to create a
>> random-length, random-content salt.  This is placed at the beginning
>> of the hashed password, stored along with it in the database.
>>
>> Then, when it comes time to compare passwords, the salt is extracted,
>> and used to re-hash.
>>
>> If someone continously changes their password to the same value,
>> you'll end up getting different raw hashed values in the database.  It
>> also increases the workload for crackers, and makes rainbow tables
>> much less fruitful.
>>
>> I wrote this change over 2 years ago, in direct response to the jira
>> intrusion that happened.

[Adam Heath-2]

On 04/19/2012 04:49 PM, Adam Heath wrote:

> On 04/19/2012 04:28 PM, Jacques Le Roux wrote:
>> Looking forward for
>> https://issues.apache.org/jira/browse/OFBIZ-1151
>> https://issues.apache.org/jira/browse/OFBIZ-2729
>> https://issues.apache.org/jira/browse/OFBIZ-3006
>
> 2729 doesn't apply for what I am doing.  Here's the list of things
> that this solves:
>
> 1: salt-based UserLogin.currentPassword
>    (done, I have a fix for the recent issue locally)
> 2: salt-based CreditCard.cardNumber encrypted value
>    (s/b done tonight)
> 3: salt-based EntityKeyStore.keyText
>    (s/b done tonight)
> 4: key-encrypting-key for EntityKeyStore.keyText.  The
> key-encrypting-key will be available somewhere in ${ofbiz.home.dir}.
>    (need to read java security doco)

Also, no longer using hex-encoding for the values, but base64, as it
produces a smaller encoded value.  The new salt-based password stuff
I've committed already does that.

[Jacques Le Roux]

From: "Adam Heath" <[hidden email]>
> On 04/19/2012 04:28 PM, Jacques Le Roux wrote:
>> Looking forward for
>> https://issues.apache.org/jira/browse/OFBIZ-1151
>> https://issues.apache.org/jira/browse/OFBIZ-2729
>> https://issues.apache.org/jira/browse/OFBIZ-3006
>
> 2729 doesn't apply for what I am doing.  Here's the list of things
> that this solves:

Oops indeed sorry, I too hastily picked them up from https://issues.apache.org/jira/browse/OFBIZ-1525

2729 is "only" about permission. For that we want to introduce Shiro but that's not for a near future:  we agreed on slim down
1st...

Jacques

[Jacques Le Roux]

From: "Adam Heath" <[hidden email]>

> On 04/19/2012 04:49 PM, Adam Heath wrote:
>> On 04/19/2012 04:28 PM, Jacques Le Roux wrote:
>>> Looking forward for
>>> https://issues.apache.org/jira/browse/OFBIZ-1151
>>> https://issues.apache.org/jira/browse/OFBIZ-2729
>>> https://issues.apache.org/jira/browse/OFBIZ-3006
>>
>> 2729 doesn't apply for what I am doing.  Here's the list of things
>> that this solves:
>>
>> 1: salt-based UserLogin.currentPassword
>>    (done, I have a fix for the recent issue locally)
>> 2: salt-based CreditCard.cardNumber encrypted value
>>    (s/b done tonight)
>> 3: salt-based EntityKeyStore.keyText
>>    (s/b done tonight)
>> 4: key-encrypting-key for EntityKeyStore.keyText.  The
>> key-encrypting-key will be available somewhere in ${ofbiz.home.dir}.
>>    (need to read java security doco)
>
> Also, no longer using hex-encoding for the values, but base64, as it
> produces a smaller encoded value.  The new salt-based password stuff
> I've committed already does that.

Sounds good, long awaited "feature"...

Jacques

[Scott Gray-2]

On 20/04/2012, at 9:49 AM, Adam Heath wrote:

> On 04/19/2012 04:28 PM, Jacques Le Roux wrote:
>> Looking forward for
>> https://issues.apache.org/jira/browse/OFBIZ-1151
>> https://issues.apache.org/jira/browse/OFBIZ-2729
>> https://issues.apache.org/jira/browse/OFBIZ-3006
>
> 2729 doesn't apply for what I am doing.  Here's the list of things
> that this solves:
>
> 1: salt-based UserLogin.currentPassword
>   (done, I have a fix for the recent issue locally)
> 2: salt-based CreditCard.cardNumber encrypted value
>   (s/b done tonight)
> 3: salt-based EntityKeyStore.keyText
>   (s/b done tonight)
> 4: key-encrypting-key for EntityKeyStore.keyText.  The
> key-encrypting-key will be available somewhere in ${ofbiz.home.dir}.
>   (need to read java security doco)
>
> I've currently rewritten a bunch of EntityCrypto already to fix the
> issues I posted into the jira issue.  I'm now at the point I can start
> adding new features.
>
> This set of changes I currently have are rather straight forward, just
> moving code around.  When I finally get around to adding the new
> features, then there is a very definate chance of breaking stuff.

Please just do your best to ensure backwards compatibility is maintained.  I can't imagine anything worse than doing an upgrade and discovering that all my user passwords are no longer valid.

>> Jacques
>>
>> From: "Adam Heath" <[hidden email]>
>>> As some may have noticed, I recently changed the way ofbiz creates
>>> password hashes when it stores them in the database.  Each time a new
>>> password is created, a bit of randomness is used, to create a
>>> random-length, random-content salt.  This is placed at the beginning
>>> of the hashed password, stored along with it in the database.
>>>
>>> Then, when it comes time to compare passwords, the salt is extracted,
>>> and used to re-hash.
>>>
>>> If someone continously changes their password to the same value,
>>> you'll end up getting different raw hashed values in the database.  It
>>> also increases the workload for crackers, and makes rainbow tables
>>> much less fruitful.
>>>
>>> I wrote this change over 2 years ago, in direct response to the jira
>>> intrusion that happened.
>

[Adam Heath-2]

On 04/19/2012 06:13 PM, Scott Gray wrote:

>
> On 20/04/2012, at 9:49 AM, Adam Heath wrote:
>
>> On 04/19/2012 04:28 PM, Jacques Le Roux wrote:
>>> Looking forward for
>>> https://issues.apache.org/jira/browse/OFBIZ-1151
>>> https://issues.apache.org/jira/browse/OFBIZ-2729
>>> https://issues.apache.org/jira/browse/OFBIZ-3006
>>
>> 2729 doesn't apply for what I am doing.  Here's the list of things
>> that this solves:
>>
>> 1: salt-based UserLogin.currentPassword
>>   (done, I have a fix for the recent issue locally)
>> 2: salt-based CreditCard.cardNumber encrypted value
>>   (s/b done tonight)
>> 3: salt-based EntityKeyStore.keyText
>>   (s/b done tonight)
>> 4: key-encrypting-key for EntityKeyStore.keyText.  The
>> key-encrypting-key will be available somewhere in ${ofbiz.home.dir}.
>>   (need to read java security doco)
>>
>> I've currently rewritten a bunch of EntityCrypto already to fix the
>> issues I posted into the jira issue.  I'm now at the point I can start
>> adding new features.
>>
>> This set of changes I currently have are rather straight forward, just
>> moving code around.  When I finally get around to adding the new
>> features, then there is a very definate chance of breaking stuff.
>
> Please just do your best to ensure backwards compatibility is maintained.  I can't imagine anything worse than doing an upgrade and discovering that all my user passwords are no longer valid.

Sure, I've got things done as an array of handlers now(2 current, plus
1 new).

How do we feel about moving EntityKeyStore into a separate database?
It'd improve the security a little bit, and is rather simple to do
with ofbiz.

[Pierre Smits]

Hi Adam,

How would that be? That would be one per tenant in a multi-tenant setup? I
can imagine in a multi-tenant setup with the db backend not on derby (as we
all recommend) the upgrade/migration aspect can be enormous. Even more so
in a HAFO-setup.

Regards,

Pierre

Op 20 april 2012 01:23 schreef Adam Heath <[hidden email]> het
volgende:

> On 04/19/2012 06:13 PM, Scott Gray wrote:
> >
> > On 20/04/2012, at 9:49 AM, Adam Heath wrote:
> >
> >> On 04/19/2012 04:28 PM, Jacques Le Roux wrote:
> >>> Looking forward for
> >>> https://issues.apache.org/jira/browse/OFBIZ-1151
> >>> https://issues.apache.org/jira/browse/OFBIZ-2729
> >>> https://issues.apache.org/jira/browse/OFBIZ-3006
> >>
> >> 2729 doesn't apply for what I am doing.  Here's the list of things
> >> that this solves:
> >>
> >> 1: salt-based UserLogin.currentPassword
> >>   (done, I have a fix for the recent issue locally)
> >> 2: salt-based CreditCard.cardNumber encrypted value
> >>   (s/b done tonight)
> >> 3: salt-based EntityKeyStore.keyText
> >>   (s/b done tonight)
> >> 4: key-encrypting-key for EntityKeyStore.keyText.  The
> >> key-encrypting-key will be available somewhere in ${ofbiz.home.dir}.
> >>   (need to read java security doco)
> >>
> >> I've currently rewritten a bunch of EntityCrypto already to fix the
> >> issues I posted into the jira issue.  I'm now at the point I can start
> >> adding new features.
> >>
> >> This set of changes I currently have are rather straight forward, just
> >> moving code around.  When I finally get around to adding the new
> >> features, then there is a very definate chance of breaking stuff.
> >
> > Please just do your best to ensure backwards compatibility is
> maintained.  I can't imagine anything worse than doing an upgrade and
> discovering that all my user passwords are no longer valid.
>
> Sure, I've got things done as an array of handlers now(2 current, plus
> 1 new).
>
> How do we feel about moving EntityKeyStore into a separate database?
> It'd improve the security a little bit, and is rather simple to do
> with ofbiz.
>
>

[Jacques Le Roux]

Yes I'm not too inclined too. This could be an option though for more security concerned projects...

Jacques

From: "Pierre Smits" <[hidden email]>

> Hi Adam,
>
> How would that be? That would be one per tenant in a multi-tenant setup? I
> can imagine in a multi-tenant setup with the db backend not on derby (as we
> all recommend) the upgrade/migration aspect can be enormous. Even more so
> in a HAFO-setup.
>
> Regards,
>
> Pierre
>
> Op 20 april 2012 01:23 schreef Adam Heath <[hidden email]> het
> volgende:
>
>> On 04/19/2012 06:13 PM, Scott Gray wrote:
>> >
>> > On 20/04/2012, at 9:49 AM, Adam Heath wrote:
>> >
>> >> On 04/19/2012 04:28 PM, Jacques Le Roux wrote:
>> >>> Looking forward for
>> >>> https://issues.apache.org/jira/browse/OFBIZ-1151
>> >>> https://issues.apache.org/jira/browse/OFBIZ-2729
>> >>> https://issues.apache.org/jira/browse/OFBIZ-3006
>> >>
>> >> 2729 doesn't apply for what I am doing.  Here's the list of things
>> >> that this solves:
>> >>
>> >> 1: salt-based UserLogin.currentPassword
>> >>   (done, I have a fix for the recent issue locally)
>> >> 2: salt-based CreditCard.cardNumber encrypted value
>> >>   (s/b done tonight)
>> >> 3: salt-based EntityKeyStore.keyText
>> >>   (s/b done tonight)
>> >> 4: key-encrypting-key for EntityKeyStore.keyText.  The
>> >> key-encrypting-key will be available somewhere in ${ofbiz.home.dir}.
>> >>   (need to read java security doco)
>> >>
>> >> I've currently rewritten a bunch of EntityCrypto already to fix the
>> >> issues I posted into the jira issue.  I'm now at the point I can start
>> >> adding new features.
>> >>
>> >> This set of changes I currently have are rather straight forward, just
>> >> moving code around.  When I finally get around to adding the new
>> >> features, then there is a very definate chance of breaking stuff.
>> >
>> > Please just do your best to ensure backwards compatibility is
>> maintained.  I can't imagine anything worse than doing an upgrade and
>> discovering that all my user passwords are no longer valid.
>>
>> Sure, I've got things done as an array of handlers now(2 current, plus
>> 1 new).
>>
>> How do we feel about moving EntityKeyStore into a separate database?
>> It'd improve the security a little bit, and is rather simple to do
>> with ofbiz.
>>
>>
>

[Adrian Crum-3]

On 4/20/2012 12:23 AM, Adam Heath wrote:

> On 04/19/2012 06:13 PM, Scott Gray wrote:
>> On 20/04/2012, at 9:49 AM, Adam Heath wrote:
>>
>>> On 04/19/2012 04:28 PM, Jacques Le Roux wrote:
>>>> Looking forward for
>>>> https://issues.apache.org/jira/browse/OFBIZ-1151
>>>> https://issues.apache.org/jira/browse/OFBIZ-2729
>>>> https://issues.apache.org/jira/browse/OFBIZ-3006
>>> 2729 doesn't apply for what I am doing.  Here's the list of things
>>> that this solves:
>>>
>>> 1: salt-based UserLogin.currentPassword
>>>    (done, I have a fix for the recent issue locally)
>>> 2: salt-based CreditCard.cardNumber encrypted value
>>>    (s/b done tonight)
>>> 3: salt-based EntityKeyStore.keyText
>>>    (s/b done tonight)
>>> 4: key-encrypting-key for EntityKeyStore.keyText.  The
>>> key-encrypting-key will be available somewhere in ${ofbiz.home.dir}.
>>>    (need to read java security doco)
>>>
>>> I've currently rewritten a bunch of EntityCrypto already to fix the
>>> issues I posted into the jira issue.  I'm now at the point I can start
>>> adding new features.
>>>
>>> This set of changes I currently have are rather straight forward, just
>>> moving code around.  When I finally get around to adding the new
>>> features, then there is a very definate chance of breaking stuff.
>> Please just do your best to ensure backwards compatibility is maintained.  I can't imagine anything worse than doing an upgrade and discovering that all my user passwords are no longer valid.
> Sure, I've got things done as an array of handlers now(2 current, plus
> 1 new).
>
> How do we feel about moving EntityKeyStore into a separate database?
> It'd improve the security a little bit, and is rather simple to do
> with ofbiz.

+1

I believe credit card companies split security-sensitive data across
databases in a similar way.

-Adrian

[Adam Heath-2]

On 04/20/2012 12:53 AM, Pierre Smits wrote:
> Hi Adam,
>
> How would that be? That would be one per tenant in a multi-tenant setup? I
> can imagine in a multi-tenant setup with the db backend not on derby (as we
> all recommend) the upgrade/migration aspect can be enormous. Even more so
> in a HAFO-setup.

Moving EntityKeyStore to a separate database would not be hard, no code
changes at all.  Just a new entitygroup mapping, and updating
entityengine.xml(or TenantDataSource) to point it at a different
database.  This would then mean running pg_dump(or whatever) would not
see the keys.

I currently have the new crypto storage done.  It uses base64 to store
the hashed keyname, the key value, and the encrypted column values
scattered around the database.  A random-length(0-15) random-value salt
is pre-pended to each value during encryption, so if you continually set
the same value, you'll get different encrypted values.

I do not yet have key-encrypting-key(KEK) support working.  I'm
currently thinking there would be one 'master' KEK.  This is what
EntityCrypto would use by default.  In sub-tenant delegators, the sub
EntityCrypto would fetch a key from it's parent delegator.  The parent
delegator would be using the master KEK to encode it's keys.  The
sub-delegator would be using a unique KEK stored in the base delegator.
  The base delegator has it's own EntityCrypto.

So, the master KEK could be stored in entityengine.xml(base64 encoded, I
can provide a cmdline tool to generate it), or some other file.

[Pierre Smits]

Hi Adam,

I can follow your reasoning. And it seems reasonable. But I would like to
suggest to you to create a JIRA for this where patches are uploaded and can
be tested in a separate ofbiz instantiation. This would then help with the
creation of implementation procedures and documentation prior to uploading
it to trunk.

Regards,

Pierre

Op 20 april 2012 16:41 schreef Adam Heath <[hidden email]> het
volgende:

> On 04/20/2012 12:53 AM, Pierre Smits wrote:
>
>> Hi Adam,
>>
>> How would that be? That would be one per tenant in a multi-tenant setup? I
>> can imagine in a multi-tenant setup with the db backend not on derby (as
>> we
>> all recommend) the upgrade/migration aspect can be enormous. Even more so
>> in a HAFO-setup.
>>
>
> Moving EntityKeyStore to a separate database would not be hard, no code
> changes at all.  Just a new entitygroup mapping, and updating
> entityengine.xml(or TenantDataSource) to point it at a different database.
>  This would then mean running pg_dump(or whatever) would not see the keys.
>
> I currently have the new crypto storage done.  It uses base64 to store the
> hashed keyname, the key value, and the encrypted column values scattered
> around the database.  A random-length(0-15) random-value salt is pre-pended
> to each value during encryption, so if you continually set the same value,
> you'll get different encrypted values.
>
> I do not yet have key-encrypting-key(KEK) support working.  I'm currently
> thinking there would be one 'master' KEK.  This is what EntityCrypto would
> use by default.  In sub-tenant delegators, the sub EntityCrypto would fetch
> a key from it's parent delegator.  The parent delegator would be using the
> master KEK to encode it's keys.  The sub-delegator would be using a unique
> KEK stored in the base delegator.  The base delegator has it's own
> EntityCrypto.
>
> So, the master KEK could be stored in entityengine.xml(base64 encoded, I
> can provide a cmdline tool to generate it), or some other file.
>

[Adam Heath-2]

On 04/20/2012 09:56 AM, Pierre Smits wrote:
> Hi Adam,
>
> I can follow your reasoning. And it seems reasonable. But I would like to
> suggest to you to create a JIRA for this where patches are uploaded and can
> be tested in a separate ofbiz instantiation. This would then help with the
> creation of implementation procedures and documentation prior to uploading
> it to trunk.

Well, I won't be sending any patches into JIRA.  That would be a worse
workflow than I currently have.  I use git to do everything now.  I'd
publish a git link somewhere in JIRA.

However, the nature of this changes is tending to keep all the
alterations in a small location.  Under those circumstances, it can be
quite difficult to have multiple people work on it at once.  I do
acknowledge the suggestion about documentation.  Implementation will
be simple, you'll upgrade, generate the master KEK, and everything
else is automatic.

[Jacques Le Roux]

From: "Adam Heath" <[hidden email]>

> On 04/20/2012 09:56 AM, Pierre Smits wrote:
>> Hi Adam,
>>
>> I can follow your reasoning. And it seems reasonable. But I would like to
>> suggest to you to create a JIRA for this where patches are uploaded and can
>> be tested in a separate ofbiz instantiation. This would then help with the
>> creation of implementation procedures and documentation prior to uploading
>> it to trunk.
>
> Well, I won't be sending any patches into JIRA.  That would be a worse
> workflow than I currently have.  I use git to do everything now.  I'd
> publish a git link somewhere in JIRA.
>
> However, the nature of this changes is tending to keep all the
> alterations in a small location.  Under those circumstances, it can be
> quite difficult to have multiple people work on it at once.  I do
> acknowledge the suggestion about documentation.  Implementation will
> be simple, you'll upgrade, generate the master KEK, and everything
> else is automatic.

Adam,

Not sure you noticed but Builbot is no longer running
http://ci.apache.org/waterfall?show_events=false&branch=&builder=ofbiz-trunk&reload=none

That's maybe why Pierre and Hans want an easy way to check before integrating?

Jacques

[Adam Heath-2]

On 04/20/2012 12:13 PM, Jacques Le Roux wrote:
> Not sure you noticed but Builbot is no longer running
> http://ci.apache.org/waterfall?show_events=false&branch=&builder=ofbiz-trunk&reload=none

Yeah, noticed that buildbot wasn't emailing.  Looking at that link, it
appears that isis_ubuntu is offline.

I always run all my changes thru a full clean/test run before
committing(even when I commit > 10 at a time).

I am willing to post some of my new stuff somewhere before committing,
'cuz changing EntityCrypto is not something you would do lightly.

> That's maybe why Pierre and Hans want an easy way to check before
> integrating?

Verifying that the existing test cases run(because buildbot is broken)
is completely separate than wanting to verify an implementation before
committing to trunk.


>
> Jacques

[Jacques Le Roux]

From: "Adam Heath" <[hidden email]>
> On 04/20/2012 12:13 PM, Jacques Le Roux wrote:
>> Not sure you noticed but Builbot is no longer running
>> http://ci.apache.org/waterfall?show_events=false&branch=&builder=ofbiz-trunk&reload=none
>
> Yeah, noticed that buildbot wasn't emailing.  Looking at that link, it
> appears that isis_ubuntu is offline.

Yes: https://issues.apache.org/jira/browse/INFRA-4562, please push...
 

> I always run all my changes thru a full clean/test run before
> committing(even when I commit > 10 at a time).
>
> I am willing to post some of my new stuff somewhere before committing,
> 'cuz changing EntityCrypto is not something you would do lightly.
>
>> That's maybe why Pierre and Hans want an easy way to check before
>> integrating?
>
> Verifying that the existing test cases run(because buildbot is broken)
> is completely separate than wanting to verify an implementation before
> committing to trunk.

I meant we can't rely on a shared (fast) CI...

Jacques

>
>>
>> Jacques
>

[Adrian Crum-3]

On 4/20/2012 9:00 PM, Adam Heath wrote:
> On 04/20/2012 12:13 PM, Jacques Le Roux wrote:
>> Not sure you noticed but Builbot is no longer running
>> http://ci.apache.org/waterfall?show_events=false&branch=&builder=ofbiz-trunk&reload=none
> Yeah, noticed that buildbot wasn't emailing.  Looking at that link, it
> appears that isis_ubuntu is offline.
>
> I always run all my changes thru a full clean/test run before
> committing(even when I commit>  10 at a time).

Adam,

If it's not too much trouble, could you look at

https://issues.apache.org/jira/browse/OFBIZ-4239 ?

Buildbot was failing the framework/base tests intermittently. I think I
tracked the problem down to a timing issue in the UtilCache tests - see
the attached test report and my comments for details.

-Adrian

[Jacopo Cappellato-4]

Adrian,

the issue you are experiencing is interesting and I had a look at it; I was only able to recreate the same failures by changing the timeouts in UtilCacheTests.java at line 302 and 308; instead of:

cache.setExpireTime(100); // line 302
Thread.sleep(200); // line 308

I set:

cache.setExpireTime(100); // line 302
Thread.sleep(99); // line 308

and (of course) I got the error.
It is kind of weird that you are getting the error with the current settings (100 and 200): is this consistent? I mean, are you able to recreate the issue frequently? did you try to increase the time for sleep:

Thread.sleep(300); // line 308

?

Regards,

Jacopo


On Apr 22, 2012, at 10:53 AM, Adrian Crum wrote:

> On 4/20/2012 9:00 PM, Adam Heath wrote:
>> On 04/20/2012 12:13 PM, Jacques Le Roux wrote:
>>> Not sure you noticed but Builbot is no longer running
>>> http://ci.apache.org/waterfall?show_events=false&branch=&builder=ofbiz-trunk&reload=none
>> Yeah, noticed that buildbot wasn't emailing.  Looking at that link, it
>> appears that isis_ubuntu is offline.
>>
>> I always run all my changes thru a full clean/test run before
>> committing(even when I commit>  10 at a time).
>
> Adam,
>
> If it's not too much trouble, could you look at
>
> https://issues.apache.org/jira/browse/OFBIZ-4239 ?
>
> Buildbot was failing the framework/base tests intermittently. I think I tracked the problem down to a timing issue in the UtilCache tests - see the attached test report and my comments for details.
>
> -Adrian
>

[Adrian Crum-3]

The tests failed intermittently in the OFBiz buildbot (back when it was
running). They always fail on my development machine.

I tried experimenting with the sleep timing and I also replaced the
Thread.sleep call with a safer version, but the tests still failed.

-Adrian

On 4/23/2012 2:40 PM, Jacopo Cappellato wrote:

> Adrian,
>
> the issue you are experiencing is interesting and I had a look at it; I was only able to recreate the same failures by changing the timeouts in UtilCacheTests.java at line 302 and 308; instead of:
>
> cache.setExpireTime(100); // line 302
> Thread.sleep(200); // line 308
>
> I set:
>
> cache.setExpireTime(100); // line 302
> Thread.sleep(99); // line 308
>
> and (of course) I got the error.
> It is kind of weird that you are getting the error with the current settings (100 and 200): is this consistent? I mean, are you able to recreate the issue frequently? did you try to increase the time for sleep:
>
> Thread.sleep(300); // line 308
>
> ?
>
> Regards,
>
> Jacopo
>
>
> On Apr 22, 2012, at 10:53 AM, Adrian Crum wrote:
>
>> On 4/20/2012 9:00 PM, Adam Heath wrote:
>>> On 04/20/2012 12:13 PM, Jacques Le Roux wrote:
>>>> Not sure you noticed but Builbot is no longer running
>>>> http://ci.apache.org/waterfall?show_events=false&branch=&builder=ofbiz-trunk&reload=none
>>> Yeah, noticed that buildbot wasn't emailing.  Looking at that link, it
>>> appears that isis_ubuntu is offline.
>>>
>>> I always run all my changes thru a full clean/test run before
>>> committing(even when I commit>   10 at a time).
>> Adam,
>>
>> If it's not too much trouble, could you look at
>>
>> https://issues.apache.org/jira/browse/OFBIZ-4239 ?
>>
>> Buildbot was failing the framework/base tests intermittently. I think I tracked the problem down to a timing issue in the UtilCache tests - see the attached test report and my comments for details.
>>
>> -Adrian
>>