Spot on Dan, much appreciated, good to see Brian still watches the list
too ;)
The policy providers are built for correctness & concurrency, first &
foremost, once we've got that licked, we can have a look at performance.
N.B. Looking at some of the terrible hashCode and equals implementation
>
> On 28 December 2011 12:02, Peter Firmstone wrote:
>
> > This just seems to be about making sure events arrive in order. I'm not
> > even sure where to start with this.
>
On Wed, Dec 28, 2011 at 7:33 AM, Dan Creswell
wrote:
> I notice there are a whole bunch of timeouts/pause variables
On 28 December 2011 12:02, Peter Firmstone wrote:
> This information applies to the following test:
>
> com/sun/jini/test/spec/lookupservice/test_set00/NotifyOnAttrAdd.td
> Test Failed: Test Failed: com.sun.jini.qa.harness.TestException: # of Events
> Received (31) != # of Events Expected (50)
>
>
This information applies to the following test:
com/sun/jini/test/spec/lookupservice/test_set00/NotifyOnAttrAdd.td
Test Failed: Test Failed: com.sun.jini.qa.harness.TestException: # of
Events Received (31) != # of Events Expected (50)
From the test documentation:
/** Performs actions necessar
Here's the context, including permissions, so yes RuntimePermission A
passes in this case, this is the passing test, now all I have to do is
figure out the domain that doesn't have RuntimePermission A in the
failing test, that should narrow it down.
context[0] = "ProtectionDomain
(file:/opt/
This is one of the contexts from the passing test during the check for
RuntimePermission B, unfortunately the codesource locations are missing
the path property com.sun.jini.qa.home.
Somehow this context passed RuntimePermission A, but you can't see that
in the ProtectionDomain toString(), alt
It might be relevant to the lost events, thanks, I'm working on the
AggregatePolicyProvider test that's failing at present, it appears to be
a different bug, but it's lower hanging fruit, so I'm trying to topple
it first.
Peter.
Patricia Shanahan wrote:
When I was looking at TaskManager, I ha
When I was looking at TaskManager, I had some concerns with how it was
being used, especially in connection with RetryTask.
Tasks get asked whether they need to wait for another task that in the
TaskManager queue. A RetryTask that has timed out and is waiting to
reschedule itself is completed
It seems it isn't too hard to lockup the test on the main trunk, using
jdb, then exiting the debugger, leaving the test in a hung state.
I've modified AggregratePolicyProvider in skunk (see recent commit),
after the mods I'm unable to get it to lock up after exiting the debugger.
From river t
...
On 27 December 2011 01:40, Peter Firmstone wrote:
> The following is specific to:
>
> com/sun/jini/test/impl/start/aggregatepolicyprovider/GetContextTest.td
>
> I've just come across the concurrency issue (experienced randomly when
> attempting to debug any of the failing tests) in the existi
The following is specific to:
com/sun/jini/test/impl/start/aggregatepolicyprovider/GetContextTest.td
I've just come across the concurrency issue (experienced randomly when
attempting to debug any of the failing tests) in the existing River
trunk code, after exiting the debugger, the test is in
Dan Creswell wrote:
Mmmm, trouble is the debugger itself (or at least its agent) could be
the problem - they aren't perfect devices, typically.
Considering I have trouble printing the ProtectionDomain in the debugger,
could this be a stale reference, or is there no relation?
Mightn'
- Original message -
> On 25 December 2011 21:54, Peter Firmstone wrote:
> > Dan Creswell wrote:
> > > > >
> > > > > Where "bug" is potentially a swallowed exception.
> > > > >
> > > > > Reggie for the most part holds a writeLock for any significant
> > > > > invocation from the client an
On 25 December 2011 21:54, Peter Firmstone wrote:
> Dan Creswell wrote:
Where "bug" is potentially a swallowed exception.
Reggie for the most part holds a writeLock for any significant
invocation from the client and events are dispatched via a
TaskManager. Seems like
Dan Creswell wrote:
Where "bug" is potentially a swallowed exception.
Reggie for the most part holds a writeLock for any significant
invocation from the client and events are dispatched via a
TaskManager. Seems like an unlikely source for problems. Am I right in
assuming the test itself is singl
On 25 December 2011 11:58, Peter wrote:
> I've noticed with the event bases tests, the more logging, security debug
> enabled, less events are dropped, or the test passes.
>
That's symptomatic of a race condition - as you slow things down with
logging etc the effect is to space things out and re
I've noticed with the event bases tests, the more logging, security debug
enabled, less events are dropped, or the test passes.
On one test, I've found after teardown commences, that permissions are denied,
the number denied coincided (at least on one test, will try more later) with
the number
For the following test:
com/sun/jini/test/impl/start/aggregatepolicyprovider/GetContextTest.td
I'm having trouble running the debugger:
main[1] threads
Group system:
(java.lang.ref.Reference$ReferenceHandler)0x124 Reference Handler
cond. waiting
(java.lang.ref.Finalizer$FinalizerThread)0
On 24 December 2011 11:36, Peter Firmstone wrote:
> I'm experiencing some failing tests:
>
> run.tests=com/sun/jini/test/spec/lookupservice/test_set00/MultipleEvntLeaseRenewals.td,\
> com/sun/jini/test/spec/lookupservice/test_set00/NotifyOnAttrAdd.td,\
> com/sun/jini/test/spec/lookupservice/test_s
19 matches
Mail list logo
