Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.5.0
    • Fix Version/s: None
    • Component/s: c
    • Labels:

      Description

      Avro-c does not currently provide message framing, the attached patch implements this improvement plus path throught for byte array encoding/decoding (don't copy anymore the bytes but use direct pointer).

        Activity

        Hide
        Gilles Gaillard added a comment -

        See also AVRO-777

        Show
        Gilles Gaillard added a comment - See also AVRO-777
        Hide
        Doug Cutting added a comment -

        This patch no longer applies cleanly. Gilles, will you be able to update it?

        Can someone familiar with Avro C please review this? Douglas? Bruce?

        Thanks!

        Show
        Doug Cutting added a comment - This patch no longer applies cleanly. Gilles, will you be able to update it? Can someone familiar with Avro C please review this? Douglas? Bruce? Thanks!
        Hide
        Lionel Delphin-Poulat added a comment -

        I wonder if work has been done on the subject since 2011. I tried to insert it in version 1.7.6 of the library as a first step to add rpc support introduced by Gilles Gaillard in AVRO-777. I have only a shallow understanding of avro and the improvements by Gilles.
        Most of the code contained in frame_memory_patch could be reported in version 1.7.6. However, there are some parts that are more delicate to insert. When the read type of the value is in AVRO_BYTES and message framing is used (in value-readc.c), the read_bytes method does not allocate memory but rather returns a pointer to the data. The pointed data should not be free. So in this case, the free function specified in avro_wrapped_alloc_new should free the avro_wrapped_buffer structure but not the data inside.

        1. Is my understanding correct?
        2. Does this mechanism apply for other value types? I think does not apply to simple types such as AVRO_FLOAT, AVRO_DOUBLE, but I wonder if it applies to more complex types such as AVRO_STRING, AVRO_ARRAY, AVRO_MAP, where memory copy might be avoided.

        Thanks!

        Show
        Lionel Delphin-Poulat added a comment - I wonder if work has been done on the subject since 2011. I tried to insert it in version 1.7.6 of the library as a first step to add rpc support introduced by Gilles Gaillard in AVRO-777 . I have only a shallow understanding of avro and the improvements by Gilles. Most of the code contained in frame_memory_patch could be reported in version 1.7.6. However, there are some parts that are more delicate to insert. When the read type of the value is in AVRO_BYTES and message framing is used (in value-readc.c), the read_bytes method does not allocate memory but rather returns a pointer to the data. The pointed data should not be free. So in this case, the free function specified in avro_wrapped_alloc_new should free the avro_wrapped_buffer structure but not the data inside. 1. Is my understanding correct? 2. Does this mechanism apply for other value types? I think does not apply to simple types such as AVRO_FLOAT, AVRO_DOUBLE, but I wonder if it applies to more complex types such as AVRO_STRING, AVRO_ARRAY, AVRO_MAP, where memory copy might be avoided. Thanks!

          People

          • Assignee:
            Unassigned
            Reporter:
            sebastien david
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development