Log messages should use the facility name for the logger name instead of org.ccnx.ccn.CCNHandle for everything. This will make it easier to find specific facility related messages in large log files.

If a content object is retrieved with getLatestVersion, the attempt timeout is reset to the remaining time. In addition, the addition of the timeout to the call removes the need for the number of attempts (that was used to make sure we tried hard to get the newest content).

I believe this bug was resolved with a correction to the getPipelinedSegment method where it got stuck in an infinite loop because I kept getting a segment at [0] and didn't remove it when it was the wrong one.

Please let me know if this is still happening, it should have been resolved (a while ago now).

This was actually fixed and merged in a while ago now... forgot to update the issue.

Pushed branch 100183-need-more-user-log-facilities

How about FAC_USER0 through FAC_USER15.

Nick reports this is done on branch f-100182-optimize-binaryxmldecoder

Paul, I don't think this is really fixed yet. Both Nick and I have seen failures. I'll get you some logs to look at.

BinaryXMLCodec's peekTypeAndVal, decodeBlob, and decodeUString, as well as BinaryXMLDecoder's peekStartElementAsString, and peekStartElementAsLong should not check if _istream.markSupported() on every call.

This check can be performed once per input stream in BinaryXMLDecoder.initializeDecoding. It shouldn't be implemented in GenericXMLDecoder because not all decoders require marking be supported.

Nick says: Branch f-100181-log-stream-open-close is ready to merge into ccnx.

Done in commit 3d37019a35546928cf2175fa54e28e043e78e855

While here, remove no-longer-needed copy of tagname.csvdict.

(Formerly, the java library needed this at runtime, but now the values are in the java sources.)

• origin/100177-CCNFileInputStream-segment-name:
  Adjust logging level for base name/segment name check from FINE to FINEST
  Correct opening of stream with segment number present in content name
  Add logging to AccessControlManager.getDataKey to show resulting unwrapped data key
  Improve logging in KDFContentKeys to include segment number for which the key is being derived

This is fixed in 100179_fix-ServiceKeyDiscoveryTest

Fixed in 100168_fix-CCN_DEBUG_DATA

Maybe opens don't need to be because they are logged via flow control