[jira] [Commented] (CASSANDRA-9613) Omit (de)serialization of state variable in UDAs

2016-07-12 Thread Tyler Hobbs (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-9613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373138#comment-15373138
 ] 

Tyler Hobbs commented on CASSANDRA-9613:


I think it should be fine to commit the patch as-is.  The tests look okay (all 
failures are known failures).

+1

> Omit (de)serialization of state variable in UDAs
> 
>
> Key: CASSANDRA-9613
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9613
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> Currently the result of each UDA's state function call is serialized and then 
> deserialized for the next state-function invocation and optionally final 
> function invocation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-9613) Omit (de)serialization of state variable in UDAs

2016-07-09 Thread Robert Stupp (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-9613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15369341#comment-15369341
 ] 

Robert Stupp commented on CASSANDRA-9613:
-

Yes, there's no built-in function that is actually usable as a state or final 
function.
The contract for all functions (built-ins and UDFs) is still to pass serialized 
arguments (deserialization is part of the code in {{JavaSourceUDF.txt}} and the 
respective scripted UDF impl). This patch is only an optimization for the state 
variable since that is probably of a type that has a higher serialisation cost 
(e.g. map, tuple, udt). But it would be a generally affordable optimization to 
let built-in and especially UDFs take the non-serialized representation - 
thinking of "constant" arguments to UDFs. But at the moment we don't have the 
case where we pass "constant" arguments to UDFs (state functions especially).

Added comments to {{generateArguments}} and the new utest and triggered CI.

> Omit (de)serialization of state variable in UDAs
> 
>
> Key: CASSANDRA-9613
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9613
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> Currently the result of each UDA's state function call is serialized and then 
> deserialized for the next state-function invocation and optionally final 
> function invocation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-9613) Omit (de)serialization of state variable in UDAs

2016-07-05 Thread Tyler Hobbs (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-9613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15363462#comment-15363462
 ] 

Tyler Hobbs commented on CASSANDRA-9613:


I apologize for letting this sit in review for a while.

Overall, I think the patch is good.  I have a few review comments:
* The reason for "UDAs only support UDFs" is pretty clear (the built-in 
functions don't support non-serialized arguments), but I'm worried about 
breaking compatibility here.  It seems like it would be better to support 
built-ins but take the performance hit and serialize arguments for now.  Right 
now it's probably not very common to use a built-in for the state function (I 
can't think of any that make a lot of sense), so I think we can take our time 
optimizing this case.
* It's a little hard to tell what's going on in {{generateArguments}}.  That's 
not a new thing, but it would be good to make it a little clearer now.  Maybe 
comments showing expected output?
* The new test is slightly confusing.  I understand what it does now, but it 
took me a minute to figure out.  A quick comment explaining how it works would 
be useful.

Other than that, can you rebase and start a final trunk test run?

> Omit (de)serialization of state variable in UDAs
> 
>
> Key: CASSANDRA-9613
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9613
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> Currently the result of each UDA's state function call is serialized and then 
> deserialized for the next state-function invocation and optionally final 
> function invocation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-9613) Omit (de)serialization of state variable in UDAs

2016-05-10 Thread Robert Stupp (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-9613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15278519#comment-15278519
 ] 

Robert Stupp commented on CASSANDRA-9613:
-

It's supposed to be PA. Utests should already cover everything, just added one 
to verify object identity 

> Omit (de)serialization of state variable in UDAs
> 
>
> Key: CASSANDRA-9613
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9613
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> Currently the result of each UDA's state function call is serialized and then 
> deserialized for the next state-function invocation and optionally final 
> function invocation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CASSANDRA-9613) Omit (de)serialization of state variable in UDAs

2016-05-10 Thread Tyler Hobbs (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-9613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15278500#comment-15278500
 ] 

Tyler Hobbs commented on CASSANDRA-9613:


[~snazy] is this supposed to be Patch Available, or do you still need to extend 
the patch?

> Omit (de)serialization of state variable in UDAs
> 
>
> Key: CASSANDRA-9613
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9613
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> Currently the result of each UDA's state function call is serialized and then 
> deserialized for the next state-function invocation and optionally final 
> function invocation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)