The JUnit end-to-end tests in EndToEndTestSource and EndToEndTestSink will fail if they are run in the opposite order as each other. That is, EndToEndTestSink.gets() needs to run when EndToEndTestSource.puts() is running, and EndToEndTestSink.server() needs to run when EndToEndTestSource.server() is running.

But JUnit make no guarantees about the ordering of the tests.

Note - logging has to be turned down to provoke this problem with any frequency.

When under heavy activity, the java pipelining code gets confused and gets into a state where it consumes a lot of cpu and makes no evident progress.

Attached are some extracts from a ktrace on FreeBSD-8.1-RC2.

I've got a fix for this particular problem, I think. It is similar to the problem that was fixed in the repo in commit b2711eb425432398c5cc67bd53924b8382f46e03.

Fixing it and trying tests with reduced logging has exposed a problem in the pipelining code that Rebecca has known about for a while, and which has similar symptoms. I'm going to put in a separate issue for that.

Can you send a link to a buildbot test, or a point in the log?

On both Solaris and FreeBSD, on recent builds, 'make test' has been seen to get stuck, using cpu but apparently making no forward progress.

Can drop some metadata and get one more path entry in same space, which means 2x as many packets per tree. Need to make it backward compatible. Need to make C library match. Both need to be able to verify old and new forms.

Publish repository key using localhost key discovery, make it easier to configure where repo publishes its key. Any real app that wants to depend on name enumeration, checked writes, etc, needs to be able to validate who a repository is.

This is in github, and is now being used by ccnd to send its keys around. It is also available to other apps.

Noticed while looking at logs: an interest in / (possibly with excludes) from off-machine can result in content for a localhost-restricted namespace to be sent in response.

Note that the receiving ccnd will (properly) discard the content, so it should not cause major operational problems.

This is done, at least for the current self-reg protocols.

This is doen (has not been pushed to github yet).

This is working pretty well now.

... like input streams.

When the pipeline code in CCNAbstractInputStream starts up, it does not necessarily know the full base name if the version is not set (for a versioned stream). In this case, it should not send out an interest for the first segment without the version in the name.