JLPCActor: good news and bad

40 views
Skip to first unread message

William la Forge

unread,
Jul 20, 2012, 9:55:02 PM7/20/12
to AgileWikiDevelopers
The rewrite now works for many of the JActor tests. Still a bit of a problem with exception handling, but I think we're close.

In the last speedup, which was checked in but not released, I combined two objects--which is what made it faster. Turns out that was a design flaw. I've fixed it, but that means the next release will likely be only as fast as the last release.

I also spend a fair amount of time thinking about the complexity of the code. I was hopeful that it could be broken into 2 or more layers, but I now suspect that that is not possible. So it looks like the complexity can not be avoided.

Bill

William la Forge

unread,
Jul 22, 2012, 3:56:21 AM7/22/12
to AgileWikiDevelopers
The new JLPCActor now works for all the JActor tests, but transaction processing now exhibits a lot of strange bugs. Obviously I missed something in the rewrite of JActor. The question is, what?

William la Forge

unread,
Jul 23, 2012, 10:10:56 PM7/23/12
to AgileWikiDevelopers
Fixed another hole in the JLPCActor logic, this one dealing with marking a request as inactive when processed synchronously.

JFile is still not working, but I did a push on JActor, as the code now works better than the last push.

I also now believe that I can do the speedup that was included in the previous push but removed from this one. But that speedup will wait until JFile is working again. Hopefully that will be soon.

Other work has been piling up, but I very much want to get JFile working first if I can.

Bill

William la Forge

unread,
Jul 25, 2012, 1:04:20 AM7/25/12
to AgileWikiDevelopers
Fixed THE bug I was tracking down in JFile. Now the intermediate JFile bug that I experienced after the speedup and before the rewrite is back. I had hoped that the rewrite would have expunged this bug, but it looks like there is no such thing as a free lunch.

The intermittent bug is due to a pipeline race condition. I'll just note that it is difficult to create such race conditions with JActor, but there it is--a race condition with thread-save code. Wild!

Raoul Duke

unread,
Jul 25, 2012, 1:10:40 PM7/25/12
to agilewiki...@googlegroups.com
On Tue, Jul 24, 2012 at 10:04 PM, William la Forge <lafo...@gmail.com> wrote:
> The intermittent bug is due to a pipeline race condition. I'll just note
> that it is difficult to create such race conditions with JActor, but there
> it is--a race condition with thread-save code. Wild!

this is both exciting and terrifying. :-) good job keeping up the good fight!

William la Forge

unread,
Jul 25, 2012, 9:42:37 PM7/25/12
to agilewiki...@googlegroups.com
Yes, intermediate bugs can be fun. I'm going to spend some time reviewing the code at this point.

Overall, the code is cleaner and has shrunk a bit. And I have a much better understanding, though the whole thing still doesn't quite fit in my head.

Bill


--
You received this message because you are subscribed to the Google Groups "AgileWikiDevelopers" group.
To post to this group, send email to agilewiki...@googlegroups.com.
To unsubscribe from this group, send email to agilewikidevelo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/agilewikidevelopers?hl=en.


William la Forge

unread,
Jul 29, 2012, 12:59:18 AM7/29/12
to agilewiki...@googlegroups.com
I'm still working on this, though I've taken some time off for our incorporation and income taxes.

I am also still not firing on all cylinders. Working on this has not been very uplifting, to say the least--at least not yet anyway!

I've done enough code reviews of the code and more than enough poking around in the code. I have had a few insights. But at this point I need to create some "minimal" test cases to force failure, and then debug them. Those test cases, from what I understand, need to do things like return a result from a prior request within the synchronous result processing of another request. "Fun" stuff!

William la Forge

unread,
Jul 29, 2012, 3:19:54 AM7/29/12
to agilewiki...@googlegroups.com
Finally, a bit of progress to report.

I've created a test that fails. The failure occurs when calling processResponse on a pending RP from a previous request. The failure is that the mailbox's current request is wrong after the call to RP.processResponse.

Gotta fix that. :-)

William la Forge

unread,
Jul 29, 2012, 3:47:46 AM7/29/12
to agilewiki...@googlegroups.com
OK, made a small change to JActor and the new test case now works, though JFile tests still fail.

Looks like I need to create more test cases. :-/

William la Forge

unread,
Jul 30, 2012, 3:11:33 AM7/30/12
to agilewiki...@googlegroups.com
I've got a new test, many. It does not work correctly--trial returns control back to the start rp, not the trial rp.

Next I've got to figure out how this happened and fix it.

Small steps, but finally we have some forward movement. 

William la Forge

unread,
Jul 30, 2012, 10:17:47 PM7/30/12
to agilewiki...@googlegroups.com
Enhanced the many test a bit. Found/fixed another bug, but JFile tests still fail.

I will continue working on JActor tests--this is proving to be quite productive.

William la Forge

unread,
Jul 30, 2012, 10:42:43 PM7/30/12
to agilewiki...@googlegroups.com
I am very encouraged now. I made another enhancement to the many test and the test failed.

Cheers!

William la Forge

unread,
Jul 31, 2012, 4:39:57 AM7/31/12
to agilewiki...@googlegroups.com
Now I fixed that bug uncovered by enhancing the many test and now the JFile tests work too. :-)

I think I'll spend a bit more time enhancing the many test before removing all those print statements. :-D
Reply all
Reply to author
Forward
0 new messages