P2P activities revamped

[Borislav Iordanov]

Hi,

I finished an initial version of the tasks/conversations/activities
refactoring. I wrote about it at:

http://code.google.com/p/hypergraphdb/wiki/CommunicationImplementation

which is more of a "user doc" than a design document, but I think
that, combined with Javadocs (just updated at
http://www.kobrix.com/javadocs/hgcore/index.html) and the code of
course should be enough :)

It was easier to write new classes than modify existing ones, so most
concepts were carried over, but in a (I believe) improved API. The
essential architectural difference is that there's no tasks or
conversations. Only activities and the framework doesn't care how many
peers participate in an activity. There are sub-activities and state
transitions can be called upon sub-activity state changes. The other
main difference is that activities are no tied to a thread anymore.
Each activity still has an action queue, but now a scheduler takes
care of allocating actions to the thread pool. Finally, method
transitions can be conveniently defined through Java annotations from
now one.

It's all documented in detail in the above wiki.

The only activity that I really rewrote with the new version of the
framework is 'AffirmIdentity', just a proof of concept. I moved the
replication related classes to a new package
'org.hypergraph.peer.replication' and cleaned up the API a little
bit. But some old APIs remain to be cleaned. I kept just so that the
replication implementation still compiles (though obviously it won't
work).

I need to update the documentation about message attributes. From now
on, 'conversation-id' will identify the current activity and two
custom attributes define the parent activity (is this is a
sub-activity) as well as the activity type:

public static final String PARENT_SCOPE = "x-parent-scope";
public static final String ACTIVITY_TYPE = "x-activity-type";

The ACTIVITY_TYPE should replace the former "action" attribute.
Otherwise, 'reply-with' and 'in-reply-to' are not used at this moment
and could be leveraged by specific activity implementations.

Cipri, one question about the JXTAServer: why the following call?

serverSocket.setSoTimeout(100);

with it, I end up getting a lot of connection timeouts. When I comment
it out, it works mostly like a charm....

Cheers,
Boris

--
"Frozen brains tell no tales."

-- Buckethead

[Ciprian Costa]

Hi Boris,

   Great to hear this, sounds good.

   The setting I think remained from when I was testing the system, it should be removed.

   I was thinking about rewriting the replication so that it does not block when some atoms are not received for some reason. This sounds like a good time to do that, since it is no longer working any way.

Regards,
Cipri