recent HashCrypt changes, and using salt-based password hashing

[Jacopo Cappellato-4]

This is really weird... I am wondering if there are issues caused by concurrent threads accessing the cache but the JUnit tests should be all executed in the same thread... so this should not be the case.

Jacopo

On Apr 23, 2012, at 3:47 PM, Adrian Crum wrote:

> 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
>>>

[Paul Foxworthy]

Hi Adam,

Maybe I'm missing something, but if the salt is a random length and might be 0 characters, doesn't that mean that some passwords, randomly, won't get the benefit of a salt? Why not make the salt a fixed length, or a random length with a reasonable minimum?

Cheers

Paul Foxworthy

Adam Heath-2 wrote

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.

[Jacques Le Roux]

This makes sense indeed, thanks Paul

I'd suggest 5 rather than 0? (still random length)

Jacques

From: "Paul Foxworthy" <[hidden email]>

> Hi Adam,
>
> Maybe I'm missing something, but if the salt is a random length and might be
> 0 characters, doesn't that mean that some passwords, randomly, won't get the
> benefit of a salt? Why not make the salt a fixed length, or a random length
> with a reasonable minimum?
>
> Cheers
>
> Paul Foxworthy
>
>
> Adam Heath-2 wrote
>>
>> 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.
>>
>
>
> -----
> --
> Coherent Software Australia Pty Ltd
> http://www.cohsoft.com.au/
>
> Bonsai ERP, the all-inclusive ERP system
> http://www.bonsaierp.com.au/
>
> --
> View this message in context:
> http://ofbiz.135035.n4.nabble.com/recent-HashCrypt-changes-and-using-salt-based-password-hashing-tp4571241p4583331.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.

[Adam Heath-2]

On 04/22/2012 03: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.

Eventually, yes, I'm still pushing hard on key-encrypting-key support
in EntityCrypto(a continuation of the hashcrypt changes).

[Adam Heath-2]

On 04/23/2012 08:40 AM, 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

Ah, brilliant.  Different platforms have different minimum
time-slices.  If my guess is correct, probably fixing this to run in
*all* cases is really rather tricky.  I'll definiately have a look at
this, but it will take even longer to come up with a proper correct fix.

[Adam Heath-2]

On 04/24/2012 03:06 AM, Jacopo Cappellato wrote:
> This is really weird... I am wondering if there are issues caused by concurrent threads accessing the cache but the JUnit tests should be all executed in the same thread... so this should not be the case.

The tests run in the foreground, yes, but soft-references are removed
by a singleton background thread that is reading from a
ReferenceQueue, and timed entries are also removed *immediately* by a
singleton background thread.

[Adam Heath-2]

On 04/24/2012 07:49 AM, Paul Foxworthy wrote:
> Hi Adam,
>
> Maybe I'm missing something, but if the salt is a random length and might be
> 0 characters, doesn't that mean that some passwords, randomly, won't get the
> benefit of a salt? Why not make the salt a fixed length, or a random length
> with a reasonable minimum?

The key is that if you continously set the *same* password value, you
will get *different* crypted output.  With no salt, the same output
will happen.  Maybe I could have a minimum length of 1.  The main
thing, however, is to make it more complex for crackers to use a
dictionary attack.

As for having a fixed or random length, it allows for having a few
more bits of randomness as part of the salt.

[Jacques Le Roux]

If you believe 1 is enough then +1 for me
Actually as it's only salt, I think it's ok

Jacques

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

> On 04/24/2012 07:49 AM, Paul Foxworthy wrote:
>> Hi Adam,
>>
>> Maybe I'm missing something, but if the salt is a random length and might be
>> 0 characters, doesn't that mean that some passwords, randomly, won't get the
>> benefit of a salt? Why not make the salt a fixed length, or a random length
>> with a reasonable minimum?
>
> The key is that if you continously set the *same* password value, you
> will get *different* crypted output.  With no salt, the same output
> will happen.  Maybe I could have a minimum length of 1.  The main
> thing, however, is to make it more complex for crackers to use a
> dictionary attack.
>
> As for having a fixed or random length, it allows for having a few
> more bits of randomness as part of the salt.

[Paul Foxworthy]

Hi Jacques and Adam,

Yes, I understand why a salt is a good idea. As well as making a
dictionary attack much harder, a salt ensures that if two users happen
to choose the same password, they will have different encrypted
passwords.

Since the salt should be unique for each user, shouldn't the length be
sufficient to ensure that's so? As it stands, a random length between
1 and 15 means about one-fifteenth of our users will have one
character salts. The salt characters are drawn from a list of 64, so
if we have more than 960 (15 * 64) users, probably two of them will
have the same salt character. Or to put it another way, if there's
more than 480 users, there's a better than even chance two of them
have the same salt character. So we reduce the chance of discovering
that two users have the same password by a factor of hundreds. Make
the salt always four characters, and the chances are one in 16
million.

I don't see any point in a shorter salt than that.

There's a discussion on the issues at
http://stackoverflow.com/questions/184112/what-is-the-optimal-length-for-user-password-salt

Cheers

Paul Foxworthy

On 27 April 2012 16:46, Jacques Le Roux [via OFBiz]
<[hidden email]> wrote:

> If you believe 1 is enough then +1 for me
> Actually as it's only salt, I think it's ok
>
> Jacques
>
> From: "Adam Heath" <[hidden email]>
>
>> On 04/24/2012 07:49 AM, Paul Foxworthy wrote:
>>> Hi Adam,
>>>
>>> Maybe I'm missing something, but if the salt is a random length and might
>>> be
>>> 0 characters, doesn't that mean that some passwords, randomly, won't get
>>> the
>>> benefit of a salt? Why not make the salt a fixed length, or a random
>>> length
>>> with a reasonable minimum?
>>
>> The key is that if you continously set the *same* password value, you
>> will get *different* crypted output.  With no salt, the same output
>> will happen.  Maybe I could have a minimum length of 1.  The main
>> thing, however, is to make it more complex for crackers to use a
>> dictionary attack.
>>
>> As for having a fixed or random length, it allows for having a few
>> more bits of randomness as part of the salt.
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://ofbiz.135035.n4.nabble.com/recent-HashCrypt-changes-and-using-salt-based-password-hashing-tp4571241p4591890.html
> To unsubscribe from recent HashCrypt changes, and using salt-based password
> hashing, click here.
> NAML

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: [phone]
Fax: [phone]
Web: http://www.cohsoft.com.au/
Email: [hidden email]

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/

[Jacques Le Roux]

Initially I suggested 5 as min

Jacques

From: "Paul Foxworthy" <[hidden email]>

> Hi Jacques and Adam,
>
> Yes, I understand why a salt is a good idea. As well as making a
> dictionary attack much harder, a salt ensures that if two users happen
> to choose the same password, they will have different encrypted
> passwords.
>
> Since the salt should be unique for each user, shouldn't the length be
> sufficient to ensure that's so? As it stands, a random length between
> 1 and 15 means about one-fifteenth of our users will have one
> character salts. The salt characters are drawn from a list of 64, so
> if we have more than 960 (15 * 64) users, probably two of them will
> have the same salt character. Or to put it another way, if there's
> more than 480 users, there's a better than even chance two of them
> have the same salt character. So we reduce the chance of discovering
> that two users have the same password by a factor of hundreds. Make
> the salt always four characters, and the chances are one in 16
> million.
>
> I don't see any point in a shorter salt than that.
>
> There's a discussion on the issues at
> http://stackoverflow.com/questions/184112/what-is-the-optimal-length-for-user-password-salt
>
> Cheers
>
> Paul Foxworthy
>
> On 27 April 2012 16:46, Jacques Le Roux [via OFBiz]
> <[hidden email]> wrote:
>> If you believe 1 is enough then +1 for me
>> Actually as it's only salt, I think it's ok
>>
>> Jacques
>>
>> From: "Adam Heath" <[hidden email]>
>>
>>> On 04/24/2012 07:49 AM, Paul Foxworthy wrote:
>>>> Hi Adam,
>>>>
>>>> Maybe I'm missing something, but if the salt is a random length and might
>>>> be
>>>> 0 characters, doesn't that mean that some passwords, randomly, won't get
>>>> the
>>>> benefit of a salt? Why not make the salt a fixed length, or a random
>>>> length
>>>> with a reasonable minimum?
>>>
>>> The key is that if you continously set the *same* password value, you
>>> will get *different* crypted output. With no salt, the same output
>>> will happen. Maybe I could have a minimum length of 1. The main
>>> thing, however, is to make it more complex for crackers to use a
>>> dictionary attack.
>>>
>>> As for having a fixed or random length, it allows for having a few
>>> more bits of randomness as part of the salt.
>>
>>
>> ________________________________
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://ofbiz.135035.n4.nabble.com/recent-HashCrypt-changes-and-using-salt-based-password-hashing-tp4571241p4591890.html
>> To unsubscribe from recent HashCrypt changes, and using salt-based password
>> hashing, click here.
>> NAML
>
>
>
> --
> Coherent Software Australia Pty Ltd
> PO Box 2773
> Cheltenham Vic 3192
> Phone: [phone]
> Fax: [phone]
> Web: http://www.cohsoft.com.au/
> Email: [hidden email]
>
> Bonsai ERP, the all-inclusive ERP system
> http://www.bonsaierp.com.au/
>

[Jacopo Cappellato-4]

On Apr 23, 2012, at 3:47 PM, Adrian Crum wrote:

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

interesting... but if you change the Thread.sleep timeout from 200 to 2000 it works, right?

Jacopo

[Adrian Crum-3]

On 4/30/2012 10:27 AM, Jacopo Cappellato wrote:
> On Apr 23, 2012, at 3:47 PM, Adrian Crum wrote:
>
>> I tried experimenting with the sleep timing and I also replaced the Thread.sleep call with a safer version, but the tests still failed.
> interesting... but if you change the Thread.sleep timeout from 200 to 2000 it works, right?

I changed it to 300. By the way, the test finally passed for the first
time when I had another non-OFBiz process running at the same time that
was making heavy use of the hard disk.

-Adrian

[Jacopo Cappellato-4]

If, as Adam mentioned, it is an issue caused by the time-slice in your box, then setting a greater timeout may fix the issue... if you will be able to make it work with, let's say 600 ms (or even 1s) then I would like to commit the change to make the test a bit more robust (even if it will be slower).

Jacopo

On Apr 30, 2012, at 12:17 PM, Adrian Crum wrote:

> On 4/30/2012 10:27 AM, Jacopo Cappellato wrote:
>> On Apr 23, 2012, at 3:47 PM, Adrian Crum wrote:
>>
>>> I tried experimenting with the sleep timing and I also replaced the Thread.sleep call with a safer version, but the tests still failed.
>> interesting... but if you change the Thread.sleep timeout from 200 to 2000 it works, right?
>
> I changed it to 300. By the way, the test finally passed for the first time when I had another non-OFBiz process running at the same time that was making heavy use of the hard disk.
>
> -Adrian
>

[Adrian Crum-3]

I will give it a try, but it will have to wait until tomorrow.

-Adrian

On 4/30/2012 12:42 PM, Jacopo Cappellato wrote:

> If, as Adam mentioned, it is an issue caused by the time-slice in your box, then setting a greater timeout may fix the issue... if you will be able to make it work with, let's say 600 ms (or even 1s) then I would like to commit the change to make the test a bit more robust (even if it will be slower).
>
> Jacopo
>
> On Apr 30, 2012, at 12:17 PM, Adrian Crum wrote:
>
>> On 4/30/2012 10:27 AM, Jacopo Cappellato wrote:
>>> On Apr 23, 2012, at 3:47 PM, Adrian Crum wrote:
>>>
>>>> I tried experimenting with the sleep timing and I also replaced the Thread.sleep call with a safer version, but the tests still failed.
>>> interesting... but if you change the Thread.sleep timeout from 200 to 2000 it works, right?
>> I changed it to 300. By the way, the test finally passed for the first time when I had another non-OFBiz process running at the same time that was making heavy use of the hard disk.
>>
>> -Adrian
>>

[Pierre Smits]

This issue seems to be a same kind of problem as the change of test ports
in trunk.

Why are we so adament that end users should and must apply patches in their
own test environment regarding test ports, while we - on the other hand -
are trying to fix something in trunk that is along the same line?

Regards,

Pierre

2012/4/30 Adrian Crum <[hidden email]>

> I will give it a try, but it will have to wait until tomorrow.
>
> -Adrian
>
>
> On 4/30/2012 12:42 PM, Jacopo Cappellato wrote:
>
>> If, as Adam mentioned, it is an issue caused by the time-slice in your
>> box, then setting a greater timeout may fix the issue... if you will be
>> able to make it work with, let's say 600 ms (or even 1s) then I would like
>> to commit the change to make the test a bit more robust (even if it will be
>> slower).
>>
>> Jacopo
>>
>> On Apr 30, 2012, at 12:17 PM, Adrian Crum wrote:
>>
>>  On 4/30/2012 10:27 AM, Jacopo Cappellato wrote:
>>>
>>>> On Apr 23, 2012, at 3:47 PM, Adrian Crum wrote:
>>>>
>>>>  I tried experimenting with the sleep timing and I also replaced the
>>>>> Thread.sleep call with a safer version, but the tests still failed.
>>>>>
>>>> interesting... but if you change the Thread.sleep timeout from 200 to
>>>> 2000 it works, right?
>>>>
>>> I changed it to 300. By the way, the test finally passed for the first
>>> time when I had another non-OFBiz process running at the same time that was
>>> making heavy use of the hard disk.
>>>
>>> -Adrian
>>>
>>>

[Adrian Crum-3]

The two are vastly different. Configuring ports is something the end
user is responsible for. Cache unit tests that are failing need to be
fixed. Configuration != failed unit tests.

-Adrian

On 4/30/2012 12:58 PM, Pierre Smits wrote:

> This issue seems to be a same kind of problem as the change of test ports
> in trunk.
>
> Why are we so adament that end users should and must apply patches in their
> own test environment regarding test ports, while we - on the other hand -
> are trying to fix something in trunk that is along the same line?
>
> Regards,
>
> Pierre
>
> 2012/4/30 Adrian Crum<[hidden email]>
>
>> I will give it a try, but it will have to wait until tomorrow.
>>
>> -Adrian
>>
>>
>> On 4/30/2012 12:42 PM, Jacopo Cappellato wrote:
>>
>>> If, as Adam mentioned, it is an issue caused by the time-slice in your
>>> box, then setting a greater timeout may fix the issue... if you will be
>>> able to make it work with, let's say 600 ms (or even 1s) then I would like
>>> to commit the change to make the test a bit more robust (even if it will be
>>> slower).
>>>
>>> Jacopo
>>>
>>> On Apr 30, 2012, at 12:17 PM, Adrian Crum wrote:
>>>
>>>   On 4/30/2012 10:27 AM, Jacopo Cappellato wrote:
>>>>> On Apr 23, 2012, at 3:47 PM, Adrian Crum wrote:
>>>>>
>>>>>   I tried experimenting with the sleep timing and I also replaced the
>>>>>> Thread.sleep call with a safer version, but the tests still failed.
>>>>>>
>>>>> interesting... but if you change the Thread.sleep timeout from 200 to
>>>>> 2000 it works, right?
>>>>>
>>>> I changed it to 300. By the way, the test finally passed for the first
>>>> time when I had another non-OFBiz process running at the same time that was
>>>> making heavy use of the hard disk.
>>>>
>>>> -Adrian
>>>>
>>>>

[Jacopo Cappellato-4]

Thank you Adrian, and of course there is no rush at all.

Jacopo

On Apr 30, 2012, at 1:45 PM, Adrian Crum wrote:

> I will give it a try, but it will have to wait until tomorrow.
>
> -Adrian
>
> On 4/30/2012 12:42 PM, Jacopo Cappellato wrote:
>> If, as Adam mentioned, it is an issue caused by the time-slice in your box, then setting a greater timeout may fix the issue... if you will be able to make it work with, let's say 600 ms (or even 1s) then I would like to commit the change to make the test a bit more robust (even if it will be slower).
>>
>> Jacopo
>>
>> On Apr 30, 2012, at 12:17 PM, Adrian Crum wrote:
>>
>>> On 4/30/2012 10:27 AM, Jacopo Cappellato wrote:
>>>> On Apr 23, 2012, at 3:47 PM, Adrian Crum wrote:
>>>>
>>>>> I tried experimenting with the sleep timing and I also replaced the Thread.sleep call with a safer version, but the tests still failed.
>>>> interesting... but if you change the Thread.sleep timeout from 200 to 2000 it works, right?
>>> I changed it to 300. By the way, the test finally passed for the first time when I had another non-OFBiz process running at the same time that was making heavy use of the hard disk.
>>>
>>> -Adrian
>>>

[Pierre Smits]

Adrian,

I accept that there is a difference, but using vastly is an exaggeration.

Are we going to provide a fix for this issue, whereby end-users can tweak
this in there own environment (by e.g. a configuration setting), or are we
just trying to find an optimal number so that these test don't fail anymore?

How dependent on the environment is OFBiz regarding these unit test?

Regards,

Pierre

2012/4/30 Adrian Crum <[hidden email]>

> The two are vastly different. Configuring ports is something the end user
> is responsible for. Cache unit tests that are failing need to be fixed.
> Configuration != failed unit tests.
>
> -Adrian
>
>
> On 4/30/2012 12:58 PM, Pierre Smits wrote:
>
>> This issue seems to be a same kind of problem as the change of test ports
>> in trunk.
>>
>> Why are we so adament that end users should and must apply patches in
>> their
>> own test environment regarding test ports, while we - on the other hand -
>> are trying to fix something in trunk that is along the same line?
>>
>> Regards,
>>
>> Pierre
>>
>> 2012/4/30 Adrian Crum<adrian.crum@sandglass-**software.com<[hidden email]>
>> >
>>
>>  I will give it a try, but it will have to wait until tomorrow.
>>>
>>> -Adrian
>>>
>>>
>>> On 4/30/2012 12:42 PM, Jacopo Cappellato wrote:
>>>
>>>  If, as Adam mentioned, it is an issue caused by the time-slice in your
>>>> box, then setting a greater timeout may fix the issue... if you will be
>>>> able to make it work with, let's say 600 ms (or even 1s) then I would
>>>> like
>>>> to commit the change to make the test a bit more robust (even if it
>>>> will be
>>>> slower).
>>>>
>>>> Jacopo
>>>>
>>>> On Apr 30, 2012, at 12:17 PM, Adrian Crum wrote:
>>>>
>>>>  On 4/30/2012 10:27 AM, Jacopo Cappellato wrote:
>>>>
>>>>> On Apr 23, 2012, at 3:47 PM, Adrian Crum wrote:
>>>>>>
>>>>>>  I tried experimenting with the sleep timing and I also replaced the
>>>>>>
>>>>>>> Thread.sleep call with a safer version, but the tests still failed.
>>>>>>>
>>>>>>>  interesting... but if you change the Thread.sleep timeout from 200
>>>>>> to
>>>>>> 2000 it works, right?
>>>>>>
>>>>>>  I changed it to 300. By the way, the test finally passed for the
>>>>> first
>>>>> time when I had another non-OFBiz process running at the same time
>>>>> that was
>>>>> making heavy use of the hard disk.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>>

[Adrian Crum-3]

This is NOT a configuration issue. Please stop trying to turn it into one.

-Adrian

On 4/30/2012 1:23 PM, Pierre Smits wrote:

> Adrian,
>
> I accept that there is a difference, but using vastly is an exaggeration.
>
> Are we going to provide a fix for this issue, whereby end-users can tweak
> this in there own environment (by e.g. a configuration setting), or are we
> just trying to find an optimal number so that these test don't fail anymore?
>
> How dependent on the environment is OFBiz regarding these unit test?
>
> Regards,
>
> Pierre
>
> 2012/4/30 Adrian Crum<[hidden email]>
>
>> The two are vastly different. Configuring ports is something the end user
>> is responsible for. Cache unit tests that are failing need to be fixed.
>> Configuration != failed unit tests.
>>
>> -Adrian
>>
>>
>> On 4/30/2012 12:58 PM, Pierre Smits wrote:
>>
>>> This issue seems to be a same kind of problem as the change of test ports
>>> in trunk.
>>>
>>> Why are we so adament that end users should and must apply patches in
>>> their
>>> own test environment regarding test ports, while we - on the other hand -
>>> are trying to fix something in trunk that is along the same line?
>>>
>>> Regards,
>>>
>>> Pierre
>>>
>>> 2012/4/30 Adrian Crum<adrian.crum@sandglass-**software.com<[hidden email]>
>>>   I will give it a try, but it will have to wait until tomorrow.
>>>> -Adrian
>>>>
>>>>
>>>> On 4/30/2012 12:42 PM, Jacopo Cappellato wrote:
>>>>
>>>>   If, as Adam mentioned, it is an issue caused by the time-slice in your
>>>>> box, then setting a greater timeout may fix the issue... if you will be
>>>>> able to make it work with, let's say 600 ms (or even 1s) then I would
>>>>> like
>>>>> to commit the change to make the test a bit more robust (even if it
>>>>> will be
>>>>> slower).
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Apr 30, 2012, at 12:17 PM, Adrian Crum wrote:
>>>>>
>>>>>   On 4/30/2012 10:27 AM, Jacopo Cappellato wrote:
>>>>>
>>>>>> On Apr 23, 2012, at 3:47 PM, Adrian Crum wrote:
>>>>>>>   I tried experimenting with the sleep timing and I also replaced the
>>>>>>>
>>>>>>>> Thread.sleep call with a safer version, but the tests still failed.
>>>>>>>>
>>>>>>>>   interesting... but if you change the Thread.sleep timeout from 200
>>>>>>> to
>>>>>>> 2000 it works, right?
>>>>>>>
>>>>>>>   I changed it to 300. By the way, the test finally passed for the
>>>>>> first
>>>>>> time when I had another non-OFBiz process running at the same time
>>>>>> that was
>>>>>> making heavy use of the hard disk.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>>

[Pierre Smits]

Is it so difficult to answer the questions?

I did not state that it should be a configuration setting. I was just
asking a few civilized questions in order to understand it more.

Regards,

Pierre


2012/4/30 Adrian Crum <[hidden email]>

> This is NOT a configuration issue. Please stop trying to turn it into one.
>
> -Adrian
>
>
> On 4/30/2012 1:23 PM, Pierre Smits wrote:
>
>> Adrian,
>>
>> I accept that there is a difference, but using vastly is an exaggeration.
>>
>> Are we going to provide a fix for this issue, whereby end-users can tweak
>> this in there own environment (by e.g. a configuration setting), or are we
>> just trying to find an optimal number so that these test don't fail
>> anymore?
>>
>> How dependent on the environment is OFBiz regarding these unit test?
>>
>> Regards,
>>
>> Pierre
>>
>> 2012/4/30 Adrian Crum<adrian.crum@sandglass-**software.com<[hidden email]>
>> >
>>
>>  The two are vastly different. Configuring ports is something the end user
>>> is responsible for. Cache unit tests that are failing need to be fixed.
>>> Configuration != failed unit tests.
>>>
>>> -Adrian
>>>
>>>
>>> On 4/30/2012 12:58 PM, Pierre Smits wrote:
>>>
>>>  This issue seems to be a same kind of problem as the change of test
>>>> ports
>>>> in trunk.
>>>>
>>>> Why are we so adament that end users should and must apply patches in
>>>> their
>>>> own test environment regarding test ports, while we - on the other hand
>>>> -
>>>> are trying to fix something in trunk that is along the same line?
>>>>
>>>> Regards,
>>>>
>>>> Pierre
>>>>
>>>> 2012/4/30 Adrian Crum<adrian.crum@sandglass-**s**oftware.com<http://software.com>
>>>> <adrian.crum@**sandglass-software.com<[hidden email]>
>>>> >
>>>>
>>>>  I will give it a try, but it will have to wait until tomorrow.
>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>> On 4/30/2012 12:42 PM, Jacopo Cappellato wrote:
>>>>>
>>>>>  If, as Adam mentioned, it is an issue caused by the time-slice in your
>>>>>
>>>>>> box, then setting a greater timeout may fix the issue... if you will
>>>>>> be
>>>>>> able to make it work with, let's say 600 ms (or even 1s) then I would
>>>>>> like
>>>>>> to commit the change to make the test a bit more robust (even if it
>>>>>> will be
>>>>>> slower).
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> On Apr 30, 2012, at 12:17 PM, Adrian Crum wrote:
>>>>>>
>>>>>>  On 4/30/2012 10:27 AM, Jacopo Cappellato wrote:
>>>>>>
>>>>>>  On Apr 23, 2012, at 3:47 PM, Adrian Crum wrote:
>>>>>>>
>>>>>>>>  I tried experimenting with the sleep timing and I also replaced the
>>>>>>>>
>>>>>>>>  Thread.sleep call with a safer version, but the tests still failed.
>>>>>>>>>
>>>>>>>>>  interesting... but if you change the Thread.sleep timeout from 200
>>>>>>>>>
>>>>>>>> to
>>>>>>>> 2000 it works, right?
>>>>>>>>
>>>>>>>>  I changed it to 300. By the way, the test finally passed for the
>>>>>>>>
>>>>>>> first
>>>>>>> time when I had another non-OFBiz process running at the same time
>>>>>>> that was
>>>>>>> making heavy use of the hard disk.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>