FAQ
I've got a strange problem with a query that runs fine when run from a
Linux machine, but fails if it runs from Windows. The exception thrown in
the reducer is:

cascading.CascadingException: unable to compare Tuples, likely a CoGroup is being attempted on fields of different types or custom comparators are incorrectly set on Fields
  at cascading.tuple.hadoop.util.TupleElementComparator.compare(TupleElementComparator.java:80)

...

Caused by: java.lang.ClassCastException: clojure.lang.PersistentArrayMap cannot be cast to java.lang.Comparable
  at clojure.lang.Util.compare(Util.java:153)


which led me to these logs from the mappers feeding into this reducer:


Mapper 1:
==========
2013-07-08 09:48:18,690 INFO cascading.flow.hadoop.FlowMapper: sourcing from: PailTap["PailScheme[['pail_root', '!data']->[ALL]]"]["/tmp/t_schutte/Lambda/LocalFsPrefix/Dua2bRw-20130708094647/master/13"]"]
2013-07-08 09:48:18,690 INFO cascading.flow.hadoop.FlowMapper: sinking to: CoGroup(f99eb7c6-b5de-4f46-859f-bb9b1d42e672*42519c89-e0c7-4fa2-8076-4e34e67d058f)[by:f99eb7c6-b5de-4f46-859f-bb9b1d42e672:[{2}:'?transaction-id', '!__gen32']42519c89-e0c7-4fa2-8076-4e34e67d058f:[{2}:'?transaction-id', '!__gen32']]

Mapper 2:
==========
2013-07-08 09:48:02,648 INFO cascading.flow.hadoop.FlowMapper: sourcing from: PailTap["PailScheme[['pail_root', '!data']->[ALL]]"]["/tmp/t_schutte/Lambda/LocalFsPrefix/Dua2bRw-20130708094647/master/10/2"]"]
2013-07-08 09:48:02,648 INFO cascading.flow.hadoop.FlowMapper: sinking to: CoGroup(f99eb7c6-b5de-4f46-859f-bb9b1d42e672*42519c89-e0c7-4fa2-8076-4e34e67d058f)[by:f99eb7c6-b5de-4f46-859f-bb9b1d42e672:[{2}:'?transaction-id', '!__gen32']42519c89-e0c7-4fa2-8076-4e34e67d058f:[{2}:'?transaction-id', '!__gen32']]


Now, the relevant parts of the query are:
((tx-item-tap pail-path) :> _ ?item-data) (extract-id-and-value ?item-data
[:id :hash] [:value :type] :> ?transaction-id ?item-type _)
((taps/transaction-seller-tap pail-path) :> _ ?seller-edge-data)
(thrift/unpack-edge ?seller-edge-data :> ?seller-edge-map) (get-in
?seller-edge-map [:transaction :hash] :> ?transaction-id)

The problem is clearly the fact that the query is turning my "_" into a
real var (!__gen32) and trying to CoGroup on it. That var would be a
Clojure map. When the query is run from Linux that !__gen32 var isn't in
the CoGroup, just the ?transaction-id.

So the question are two-fold:
1) Why is Cascalog turning that "_" into a var and trying to group on it
2) Why does it work when run from Linux but not from Windows?

Anyone have any ideas or could point me in the right direction? This one
has be stumped.

Thanks,

Dave


--
You received this message because you are subscribed to the Google Groups "cascalog-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cascalog-user+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • David Kincaid at Jul 8, 2013 at 5:26 pm
    I think I've narrowed the problem down to this piece of code in
    cascalog.vars:

    (let [i (atom 0)]
       (defn gen-unique-suffix []
         (str "__gen" (swap! i inc))))

    I turned on debugging for the query (using with-debug macro) and I can see
    that on a Windows machine it is creating duplicate vars (e.g. !__gen32) in
    two different places. The first one is created in the raw-predicates. I see
    this same name used in two very different operations under the "Adding op
    to tail". If the same query is run on a Linux machine the var names are
    different between the two operations.

    On Monday, July 8, 2013 10:47:22 AM UTC-5, David Kincaid wrote:

    I've got a strange problem with a query that runs fine when run from a
    Linux machine, but fails if it runs from Windows. The exception thrown in
    the reducer is:

    cascading.CascadingException: unable to compare Tuples, likely a CoGroup is being attempted on fields of different types or custom comparators are incorrectly set on Fields
    at cascading.tuple.hadoop.util.TupleElementComparator.compare(TupleElementComparator.java:80)

    ...

    Caused by: java.lang.ClassCastException: clojure.lang.PersistentArrayMap cannot be cast to java.lang.Comparable
    at clojure.lang.Util.compare(Util.java:153)


    which led me to these logs from the mappers feeding into this reducer:


    Mapper 1:
    ==========
    2013-07-08 09:48:18,690 INFO cascading.flow.hadoop.FlowMapper: sourcing from: PailTap["PailScheme[['pail_root', '!data']->[ALL]]"]["/tmp/t_schutte/Lambda/LocalFsPrefix/Dua2bRw-20130708094647/master/13"]"]
    2013-07-08 09:48:18,690 INFO cascading.flow.hadoop.FlowMapper: sinking to: CoGroup(f99eb7c6-b5de-4f46-859f-bb9b1d42e672*42519c89-e0c7-4fa2-8076-4e34e67d058f)[by:f99eb7c6-b5de-4f46-859f-bb9b1d42e672:[{2}:'?transaction-id', '!__gen32']42519c89-e0c7-4fa2-8076-4e34e67d058f:[{2}:'?transaction-id', '!__gen32']]

    Mapper 2:
    ==========
    2013-07-08 09:48:02,648 INFO cascading.flow.hadoop.FlowMapper: sourcing from: PailTap["PailScheme[['pail_root', '!data']->[ALL]]"]["/tmp/t_schutte/Lambda/LocalFsPrefix/Dua2bRw-20130708094647/master/10/2"]"]
    2013-07-08 09:48:02,648 INFO cascading.flow.hadoop.FlowMapper: sinking to: CoGroup(f99eb7c6-b5de-4f46-859f-bb9b1d42e672*42519c89-e0c7-4fa2-8076-4e34e67d058f)[by:f99eb7c6-b5de-4f46-859f-bb9b1d42e672:[{2}:'?transaction-id', '!__gen32']42519c89-e0c7-4fa2-8076-4e34e67d058f:[{2}:'?transaction-id', '!__gen32']]


    Now, the relevant parts of the query are:
    ((tx-item-tap pail-path) :> _ ?item-data) (extract-id-and-value ?item-data
    [:id :hash] [:value :type] :> ?transaction-id ?item-type _)
    ((taps/transaction-seller-tap pail-path) :> _ ?seller-edge-data)
    (thrift/unpack-edge ?seller-edge-data :> ?seller-edge-map) (get-in
    ?seller-edge-map [:transaction :hash] :> ?transaction-id)

    The problem is clearly the fact that the query is turning my "_" into a
    real var (!__gen32) and trying to CoGroup on it. That var would be a
    Clojure map. When the query is run from Linux that !__gen32 var isn't in
    the CoGroup, just the ?transaction-id.

    So the question are two-fold:
    1) Why is Cascalog turning that "_" into a var and trying to group on it
    2) Why does it work when run from Linux but not from Windows?

    Anyone have any ideas or could point me in the right direction? This one
    has be stumped.

    Thanks,

    Dave

    --
    You received this message because you are subscribed to the Google Groups "cascalog-user" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to cascalog-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Sam Ritchie at Jul 8, 2013 at 7:32 pm
    Hmm, perhaps a multi-threading issue. The develop branch has updated
    this function to use Clojure's (gensym), which should fix the issue.
    David Kincaid July 8, 2013 12:26 PM
    I think I've narrowed the problem down to this piece of code in
    cascalog.vars:

    (let [i (atom 0)]
    (defn gen-unique-suffix []
    (str "__gen" (swap! i inc))))

    I turned on debugging for the query (using with-debug macro) and I can
    see that on a Windows machine it is creating duplicate vars (e.g.
    !__gen32) in two different places. The first one is created in the
    raw-predicates. I see this same name used in two very different
    operations under the "Adding op to tail". If the same query is run on
    a Linux machine the var names are different between the two operations.


    On Monday, July 8, 2013 10:47:22 AM UTC-5, David Kincaid wrote:
    --
    You received this message because you are subscribed to the Google
    Groups "cascalog-user" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to cascalog-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.


    David Kincaid July 8, 2013 10:47 AM
    I've got a strange problem with a query that runs fine when run from a
    Linux machine, but fails if it runs from Windows. The exception thrown
    in the reducer is:

    cascading.CascadingException: unable to compare Tuples, likely a
    CoGroup is being attempted on fields of different types or custom
    comparators are incorrectly set on Fields
    at
    cascading.tuple.hadoop.util.TupleElementComparator.compare(TupleElementComparator.java:80)
    ...
    Caused by: java.lang.ClassCastException: clojure.lang.PersistentArrayMap cannot be cast to java.lang.Comparable
    at clojure.lang.Util.compare(Util.java:153)
    which led me to these logs from the mappers feeding into this reducer:
    Mapper 1:
    ==========
    2013-07-08 09:48:18,690 INFO cascading.flow.hadoop.FlowMapper: sourcing from: PailTap["PailScheme[['pail_root', '!data']->[ALL]]"]["/tmp/t_schutte/Lambda/LocalFsPrefix/Dua2bRw-20130708094647/master/13"]"]
    2013-07-08 09:48:18,690 INFO cascading.flow.hadoop.FlowMapper: sinking to: CoGroup(f99eb7c6-b5de-4f46-859f-bb9b1d42e672*42519c89-e0c7-4fa2-8076-4e34e67d058f)[by:f99eb7c6-b5de-4f46-859f-bb9b1d42e672:[{2}:'?transaction-id', '!__gen32']42519c89-e0c7-4fa2-8076-4e34e67d058f:[{2}:'?transaction-id', '!__gen32']]

    Mapper 2:
    ==========
    2013-07-08 09:48:02,648 INFO cascading.flow.hadoop.FlowMapper: sourcing from: PailTap["PailScheme[['pail_root', '!data']->[ALL]]"]["/tmp/t_schutte/Lambda/LocalFsPrefix/Dua2bRw-20130708094647/master/10/2"]"]
    2013-07-08 09:48:02,648 INFO cascading.flow.hadoop.FlowMapper: sinking to: CoGroup(f99eb7c6-b5de-4f46-859f-bb9b1d42e672*42519c89-e0c7-4fa2-8076-4e34e67d058f)[by:f99eb7c6-b5de-4f46-859f-bb9b1d42e672:[{2}:'?transaction-id', '!__gen32']42519c89-e0c7-4fa2-8076-4e34e67d058f:[{2}:'?transaction-id', '!__gen32']]

    Now, the relevant parts of the query are:
    ((tx-item-tap pail-path) :> _ ?item-data)
    (extract-id-and-value ?item-data [:id :hash] [:value :type] :>
    ?transaction-id ?item-type _)
    ((taps/transaction-seller-tap pail-path) :> _ ?seller-edge-data)
    (thrift/unpack-edge ?seller-edge-data :> ?seller-edge-map)
    (get-in ?seller-edge-map [:transaction :hash] :> ?transaction-id)

    The problem is clearly the fact that the query is turning my "_" into
    a real var (!__gen32) and trying to CoGroup on it. That var would be a
    Clojure map. When the query is run from Linux that !__gen32 var isn't
    in the CoGroup, just the ?transaction-id.

    So the question are two-fold:
    1) Why is Cascalog turning that "_" into a var and trying to group on it
    2) Why does it work when run from Linux but not from Windows?

    Anyone have any ideas or could point me in the right direction? This
    one has be stumped.

    Thanks,

    Dave

    --
    You received this message because you are subscribed to the Google
    Groups "cascalog-user" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to cascalog-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    Sam Ritchie, Twitter Inc
    703.662.1337
    @sritchie

    --
    You received this message because you are subscribed to the Google Groups "cascalog-user" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to cascalog-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • David Kincaid at Jul 8, 2013 at 8:12 pm
    Why would it behave differently between Windows and Linux? That's the part
    that's making me crazy.
    On Monday, July 8, 2013 2:32:43 PM UTC-5, Sam Ritchie wrote:

    Hmm, perhaps a multi-threading issue. The develop branch has updated this
    function to use Clojure's (gensym), which should fix the issue.

    David Kincaid <javascript:>
    July 8, 2013 12:26 PM
    I think I've narrowed the problem down to this piece of code in
    cascalog.vars:

    (let [i (atom 0)]
    (defn gen-unique-suffix []
    (str "__gen" (swap! i inc))))

    I turned on debugging for the query (using with-debug macro) and I can see
    that on a Windows machine it is creating duplicate vars (e.g. !__gen32) in
    two different places. The first one is created in the raw-predicates. I see
    this same name used in two very different operations under the "Adding op
    to tail". If the same query is run on a Linux machine the var names are
    different between the two operations.


    --
    You received this message because you are subscribed to the Google Groups "cascalog-user" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to cascalog-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kyrill Alyoshin at Jul 9, 2013 at 4:46 am
    Sam, I am working with Dave on this.

    This issue happens with 100% certainty on Windows - always fails, which
    makes me wonder if something else may be at fault here rather than
    concurrency. It sure is a tricky one...

    -Kyrill
    On Monday, July 8, 2013 3:32:43 PM UTC-4, Sam Ritchie wrote:

    Hmm, perhaps a multi-threading issue. The develop branch has updated this
    function to use Clojure's (gensym), which should fix the issue.

    David Kincaid <javascript:>
    July 8, 2013 12:26 PM
    I think I've narrowed the problem down to this piece of code in
    cascalog.vars:

    (let [i (atom 0)]
    (defn gen-unique-suffix []
    (str "__gen" (swap! i inc))))

    I turned on debugging for the query (using with-debug macro) and I can see
    that on a Windows machine it is creating duplicate vars (e.g. !__gen32) in
    two different places. The first one is created in the raw-predicates. I see
    this same name used in two very different operations under the "Adding op
    to tail". If the same query is run on a Linux machine the var names are
    different between the two operations.


    On Monday, July 8, 2013 10:47:22 AM UTC-5, David Kincaid wrote:
    --
    You received this message because you are subscribed to the Google Groups
    "cascalog-user" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to cascalog-use...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.


    David Kincaid <javascript:>
    July 8, 2013 10:47 AM
    I've got a strange problem with a query that runs fine when run from a
    Linux machine, but fails if it runs from Windows. The exception thrown in
    the reducer is:

    cascading.CascadingException: unable to compare Tuples, likely a CoGroup
    is being attempted on fields of different types or custom comparators are
    incorrectly set on Fields
    at
    cascading.tuple.hadoop.util.TupleElementComparator.compare(TupleElementComparator.java:80)
    ...

    Caused by: java.lang.ClassCastException: clojure.lang.PersistentArrayMap cannot be cast to java.lang.Comparable
    at clojure.lang.Util.compare(Util.java:153)

    which led me to these logs from the mappers feeding into this reducer:

    Mapper 1:
    ==========
    2013-07-08 09:48:18,690 INFO cascading.flow.hadoop.FlowMapper: sourcing from: PailTap["PailScheme[['pail_root', '!data']->[ALL]]"]["/tmp/t_schutte/Lambda/LocalFsPrefix/Dua2bRw-20130708094647/master/13"]"]
    2013-07-08 09:48:18,690 INFO cascading.flow.hadoop.FlowMapper: sinking to: CoGroup(f99eb7c6-b5de-4f46-859f-bb9b1d42e672*42519c89-e0c7-4fa2-8076-4e34e67d058f)[by:f99eb7c6-b5de-4f46-859f-bb9b1d42e672:[{2}:'?transaction-id', '!__gen32']42519c89-e0c7-4fa2-8076-4e34e67d058f:[{2}:'?transaction-id', '!__gen32']]

    Mapper 2:
    ==========
    2013-07-08 09:48:02,648 INFO cascading.flow.hadoop.FlowMapper: sourcing from: PailTap["PailScheme[['pail_root', '!data']->[ALL]]"]["/tmp/t_schutte/Lambda/LocalFsPrefix/Dua2bRw-20130708094647/master/10/2"]"]
    2013-07-08 09:48:02,648 INFO cascading.flow.hadoop.FlowMapper: sinking to: CoGroup(f99eb7c6-b5de-4f46-859f-bb9b1d42e672*42519c89-e0c7-4fa2-8076-4e34e67d058f)[by:f99eb7c6-b5de-4f46-859f-bb9b1d42e672:[{2}:'?transaction-id', '!__gen32']42519c89-e0c7-4fa2-8076-4e34e67d058f:[{2}:'?transaction-id', '!__gen32']]


    Now, the relevant parts of the query are:
    ((tx-item-tap pail-path) :> _ ?item-data)
    (extract-id-and-value ?item-data [:id :hash] [:value :type] :>
    ?transaction-id ?item-type _)
    ((taps/transaction-seller-tap pail-path) :> _ ?seller-edge-data)
    (thrift/unpack-edge ?seller-edge-data :> ?seller-edge-map)
    (get-in ?seller-edge-map [:transaction :hash] :> ?transaction-id)

    The problem is clearly the fact that the query is turning my "_" into a
    real var (!__gen32) and trying to CoGroup on it. That var would be a
    Clojure map. When the query is run from Linux that !__gen32 var isn't in
    the CoGroup, just the ?transaction-id.

    So the question are two-fold:
    1) Why is Cascalog turning that "_" into a var and trying to group on it
    2) Why does it work when run from Linux but not from Windows?

    Anyone have any ideas or could point me in the right direction? This one
    has be stumped.

    Thanks,

    Dave

    --
    You received this message because you are subscribed to the Google Groups
    "cascalog-user" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to cascalog-use...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.




    --
    Sam Ritchie, Twitter Inc
    703.662.1337
    @sritchie
    --
    You received this message because you are subscribed to the Google Groups "cascalog-user" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to cascalog-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Sam Ritchie at Jul 9, 2013 at 2:34 pm
    Yeah, this is really strange. That function uses an atomic integer, so
    I'm not sure how this would happen.
    Kyrill Alyoshin July 8, 2013 3:18 PM
    Sam, I am working with Dave on this.

    This issue happens with 100% certainty on Windows - always fails,
    which makes me wonder if something else may be at fault here rather
    than concurrency. It sure is a tricky one...

    -Kyrill

    On Monday, July 8, 2013 3:32:43 PM UTC-4, Sam Ritchie wrote: --
    You received this message because you are subscribed to the Google
    Groups "cascalog-user" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to cascalog-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.


    Sam Ritchie July 8, 2013 2:32 PM
    Hmm, perhaps a multi-threading issue. The develop branch has updated
    this function to use Clojure's (gensym), which should fix the issue.


    David Kincaid July 8, 2013 12:26 PM
    I think I've narrowed the problem down to this piece of code in
    cascalog.vars:

    (let [i (atom 0)]
    (defn gen-unique-suffix []
    (str "__gen" (swap! i inc))))

    I turned on debugging for the query (using with-debug macro) and I can
    see that on a Windows machine it is creating duplicate vars (e.g.
    !__gen32) in two different places. The first one is created in the
    raw-predicates. I see this same name used in two very different
    operations under the "Adding op to tail". If the same query is run on
    a Linux machine the var names are different between the two operations.


    On Monday, July 8, 2013 10:47:22 AM UTC-5, David Kincaid wrote:
    --
    You received this message because you are subscribed to the Google
    Groups "cascalog-user" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to cascalog-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.


    David Kincaid July 8, 2013 10:47 AM
    I've got a strange problem with a query that runs fine when run from a
    Linux machine, but fails if it runs from Windows. The exception thrown
    in the reducer is:

    cascading.CascadingException: unable to compare Tuples, likely a
    CoGroup is being attempted on fields of different types or custom
    comparators are incorrectly set on Fields
    at
    cascading.tuple.hadoop.util.TupleElementComparator.compare(TupleElementComparator.java:80)
    ...
    Caused by: java.lang.ClassCastException: clojure.lang.PersistentArrayMap cannot be cast to java.lang.Comparable
    at clojure.lang.Util.compare(Util.java:153)
    which led me to these logs from the mappers feeding into this reducer:
    Mapper 1:
    ==========
    2013-07-08 09:48:18,690 INFO cascading.flow.hadoop.FlowMapper: sourcing from: PailTap["PailScheme[['pail_root', '!data']->[ALL]]"]["/tmp/t_schutte/Lambda/LocalFsPrefix/Dua2bRw-20130708094647/master/13"]"]
    2013-07-08 09:48:18,690 INFO cascading.flow.hadoop.FlowMapper: sinking to: CoGroup(f99eb7c6-b5de-4f46-859f-bb9b1d42e672*42519c89-e0c7-4fa2-8076-4e34e67d058f)[by:f99eb7c6-b5de-4f46-859f-bb9b1d42e672:[{2}:'?transaction-id', '!__gen32']42519c89-e0c7-4fa2-8076-4e34e67d058f:[{2}:'?transaction-id', '!__gen32']]

    Mapper 2:
    ==========
    2013-07-08 09:48:02,648 INFO cascading.flow.hadoop.FlowMapper: sourcing from: PailTap["PailScheme[['pail_root', '!data']->[ALL]]"]["/tmp/t_schutte/Lambda/LocalFsPrefix/Dua2bRw-20130708094647/master/10/2"]"]
    2013-07-08 09:48:02,648 INFO cascading.flow.hadoop.FlowMapper: sinking to: CoGroup(f99eb7c6-b5de-4f46-859f-bb9b1d42e672*42519c89-e0c7-4fa2-8076-4e34e67d058f)[by:f99eb7c6-b5de-4f46-859f-bb9b1d42e672:[{2}:'?transaction-id', '!__gen32']42519c89-e0c7-4fa2-8076-4e34e67d058f:[{2}:'?transaction-id', '!__gen32']]

    Now, the relevant parts of the query are:
    ((tx-item-tap pail-path) :> _ ?item-data)
    (extract-id-and-value ?item-data [:id :hash] [:value :type] :>
    ?transaction-id ?item-type _)
    ((taps/transaction-seller-tap pail-path) :> _ ?seller-edge-data)
    (thrift/unpack-edge ?seller-edge-data :> ?seller-edge-map)
    (get-in ?seller-edge-map [:transaction :hash] :> ?transaction-id)

    The problem is clearly the fact that the query is turning my "_" into
    a real var (!__gen32) and trying to CoGroup on it. That var would be a
    Clojure map. When the query is run from Linux that !__gen32 var isn't
    in the CoGroup, just the ?transaction-id.

    So the question are two-fold:
    1) Why is Cascalog turning that "_" into a var and trying to group on it
    2) Why does it work when run from Linux but not from Windows?

    Anyone have any ideas or could point me in the right direction? This
    one has be stumped.

    Thanks,

    Dave

    --
    You received this message because you are subscribed to the Google
    Groups "cascalog-user" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to cascalog-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    Sam Ritchie, Twitter Inc
    703.662.1337
    @sritchie

    --
    You received this message because you are subscribed to the Google Groups "cascalog-user" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to cascalog-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • David Kincaid at Jul 9, 2013 at 4:45 pm
    Yeah. I'd like to understand it, but it's probably not worth the time. I
    built a 1.10.2 jar off the develop branch and we're using that for now. It
    does fix the issue as you expected.

    Thanks,

    Dave
    On Tuesday, July 9, 2013 9:34:15 AM UTC-5, Sam Ritchie wrote:

    Yeah, this is really strange. That function uses an atomic integer, so I'm
    not sure how this would happen.

    Kyrill Alyoshin <javascript:>
    July 8, 2013 3:18 PM
    Sam, I am working with Dave on this.

    This issue happens with 100% certainty on Windows - always fails, which
    makes me wonder if something else may be at fault here rather than
    concurrency. It sure is a tricky one...

    -Kyrill

    On Monday, July 8, 2013 3:32:43 PM UTC-4, Sam Ritchie wrote: --
    You received this message because you are subscribed to the Google Groups
    "cascalog-user" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to cascalog-use...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.


    Sam Ritchie <javascript:>
    July 8, 2013 2:32 PM
    Hmm, perhaps a multi-threading issue. The develop branch has updated this
    function to use Clojure's (gensym), which should fix the issue.


    David Kincaid <javascript:>
    July 8, 2013 12:26 PM
    I think I've narrowed the problem down to this piece of code in
    cascalog.vars:

    (let [i (atom 0)]
    (defn gen-unique-suffix []
    (str "__gen" (swap! i inc))))

    I turned on debugging for the query (using with-debug macro) and I can see
    that on a Windows machine it is creating duplicate vars (e.g. !__gen32) in
    two different places. The first one is created in the raw-predicates. I see
    this same name used in two very different operations under the "Adding op
    to tail". If the same query is run on a Linux machine the var names are
    different between the two operations.


    On Monday, July 8, 2013 10:47:22 AM UTC-5, David Kincaid wrote:
    --
    You received this message because you are subscribed to the Google Groups
    "cascalog-user" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to cascalog-use...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.


    David Kincaid <javascript:>
    July 8, 2013 10:47 AM
    I've got a strange problem with a query that runs fine when run from a
    Linux machine, but fails if it runs from Windows. The exception thrown in
    the reducer is:

    cascading.CascadingException: unable to compare Tuples, likely a CoGroup
    is being attempted on fields of different types or custom comparators are
    incorrectly set on Fields
    at
    cascading.tuple.hadoop.util.TupleElementComparator.compare(TupleElementComparator.java:80)
    ...

    Caused by: java.lang.ClassCastException: clojure.lang.PersistentArrayMap cannot be cast to java.lang.Comparable
    at clojure.lang.Util.compare(Util.java:153)

    which led me to these logs from the mappers feeding into this reducer:

    Mapper 1:
    ==========
    2013-07-08 09:48:18,690 INFO cascading.flow.hadoop.FlowMapper: sourcing from: PailTap["PailScheme[['pail_root', '!data']->[ALL]]"]["/tmp/t_schutte/Lambda/LocalFsPrefix/Dua2bRw-20130708094647/master/13"]"]
    2013-07-08 09:48:18,690 INFO cascading.flow.hadoop.FlowMapper: sinking to: CoGroup(f99eb7c6-b5de-4f46-859f-bb9b1d42e672*42519c89-e0c7-4fa2-8076-4e34e67d058f)[by:f99eb7c6-b5de-4f46-859f-bb9b1d42e672:[{2}:'?transaction-id', '!__gen32']42519c89-e0c7-4fa2-8076-4e34e67d058f:[{2}:'?transaction-id', '!__gen32']]

    Mapper 2:
    ==========
    2013-07-08 09:48:02,648 INFO cascading.flow.hadoop.FlowMapper: sourcing from: PailTap["PailScheme[['pail_root', '!data']->[ALL]]"]["/tmp/t_schutte/Lambda/LocalFsPrefix/Dua2bRw-20130708094647/master/10/2"]"]
    2013-07-08 09:48:02,648 INFO cascading.flow.hadoop.FlowMapper: sinking to: CoGroup(f99eb7c6-b5de-4f46-859f-bb9b1d42e672*42519c89-e0c7-4fa2-8076-4e34e67d058f)[by:f99eb7c6-b5de-4f46-859f-bb9b1d42e672:[{2}:'?transaction-id', '!__gen32']42519c89-e0c7-4fa2-8076-4e34e67d058f:[{2}:'?transaction-id', '!__gen32']]


    Now, the relevant parts of the query are:
    ((tx-item-tap pail-path) :> _ ?item-data)
    (extract-id-and-value ?item-data [:id :hash] [:value :type] :>
    ?transaction-id ?item-type _)
    ((taps/transaction-seller-tap pail-path) :> _ ?seller-edge-data)
    (thrift/unpack-edge ?seller-edge-data :> ?seller-edge-map)
    (get-in ?seller-edge-map [:transaction :hash] :> ?transaction-id)

    The problem is clearly the fact that the query is turning my "_" into a
    real var (!__gen32) and trying to CoGroup on it. That var would be a
    Clojure map. When the query is run from Linux that !__gen32 var isn't in
    the CoGroup, just the ?transaction-id.

    So the question are two-fold:
    1) Why is Cascalog turning that "_" into a var and trying to group on it
    2) Why does it work when run from Linux but not from Windows?

    Anyone have any ideas or could point me in the right direction? This one
    has be stumped.

    Thanks,

    Dave

    --
    You received this message because you are subscribed to the Google Groups
    "cascalog-user" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to cascalog-use...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.




    --
    Sam Ritchie, Twitter Inc
    703.662.1337
    @sritchie
    --
    You received this message because you are subscribed to the Google Groups "cascalog-user" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to cascalog-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcascalog-user @
categoriesclojure, hadoop
postedJul 8, '13 at 3:47p
activeJul 9, '13 at 4:45p
posts7
users3
websiteclojure.org
irc#clojure

People

Translate

site design / logo © 2021 Grokbase