• Jun 5, 2013
  • Jun 4, 2013

    1.0.0-M9.4

    Relaxes jvalue content-type restrictions slightly to allow for the he…
    …ader to be absent.
    
    Removes some bad abstraction & consolidates error handling in HttpServiceUpstreamHandler.
  • May 20, 2013

    1.0.0-M9.3

    Async parser overhaul
    
  • May 20, 2013

    1.0.0-M9.2

    Tagging M9.2 with improved JValue toString
    
  • May 14, 2013

    1.0.0-M9.1

    Tagging M9.1 release with relaxed content type checking
    
  • May 13, 2013

    1.0.0-M9

    Tagging M9 to allow further unrelated work on SNAPSHOT
    
  • May 9, 2013

    1.0.0-M8.11

    Fix major problems in the AsyncParser design.
    The async parser was introduced to handle a very specific use case:
    parsing a (whitespace delimited) stream of relatively small (<1M) JSON
    objects. Its design, buffering strategy, and strategy for resuming
    parsing were all based on this scenario. In scenarios where the user
    wanted to use many small chunks to parse a much larger value (i.e. 60M)
    parser performance would degrate horribly compared to the synchronous
    (all-at-once) parser.
    
    Furthermore, the error-recovery strategy was based around similar
    assumptions, and was not reliable in general (without frim commitments
    from the user about delimiters and escaping it is hard to see how it
    could be).
    
    This commit does several things:
    
     1. Fix the major performance problems seen when async parsing one
        large value. While this is still not an ideal situation,
        performance is now roughly on-par with the equivalent sync parser.
    
     2. Remove the error-recovery option for the AsyncParser. It didn't
        work reliably and was not being relied on by anyone.
    
     3. Create 3 different async parsing modes:
    
        a. Streaming: This is the existing behavior (returning a collection
           of whitespace-delimited JSON values).
    
        b. Json: This mode expects the input to be a single well-formed
           JSON value. In the future this should become the default
           behavior.
    
        c. Unwrapping: This mode is like (b) but if the JSON value is an
           array, the parser will instead parse the contents of the array
           as a stream and return those values, rather than the outer
           array.
    
        Mode (c) is especially exciting, since for situations where users
        need to parse very large arrays of values. Unlike the sync parser
        (or the async parser in modes (a) and (b)) unwrapping means that
        the parser itself does not need to accumulate and store all the
        parsed objects itself.
    
     4. The commit adds some additional tests and benchmarks to measure the
        performance of these parsers.
    
    None of the synchronous parsers should be affected by these changes.
  • Apr 25, 2013

    1.0.0-M8.10

    DispatchError should not wrap an HttpException, since it should never…
    … be handled through the exception channel.
  • Apr 25, 2013

    1.0.0-M8.9

    Fixes potentially oversized HTTP status lines due to HttpException ha…
    …ndling.
    
    Changed to use scalaz 7.0.0 final
  • Apr 23, 2013

    1.0.0-M8.8

    Made lifting of extractors and decomposers to versioned instances use…
    … the PML pattern.