CASSANDRA-18739 describes a reproducible NPE on restart with some UDFs.
The solution outlined in that ticket was not used and a much simpler
solution provided by Stefan Miklosovic was implemented. There are 2 pull
requests open for Cassandra 4.0 and 4.1 that have the fairly simple fix as
well as
OK, that seems clear now :)
I understood from our conversations
that "enable_user_defined_functions_threads: false" would disable the UDF'
specific class loader but it seems I understood wrongly, so the only way to
use custom packages in UDF is to modify source code.
Many thanks!
Le
...@gmail.com
Cc: ble...@apache.org
Subject: Re: UDF: adding custom jar to classpath
Hi Ekaterina,
I use 4.0.1.
But as I said I added a jar in classpath (/usr/share/cassandra/lib/ folder on
every node) and I see that the jar is loaded in the classpath from the
Cassandra command line. And I have
tation that we should add "allow_insecure_udfs:
>> true" and optionally "allow_extra_insecure_udfs: true" so that
>> "enable_user_defined_functions_threads: false" is really taken into account
>> (I understood like that). That would explain why my UDF still do
Hi everybody,
>
> I found in the documentation that we should add "allow_insecure_udfs:
> true" and optionally "allow_extra_insecure_udfs: true" so that
> "enable_user_defined_functions_threads: false" is really taken into account
> (I understood like
Sorry, I found that allow_insecure_udfs and allow_extra_insecure_udfs have
been introduced in 4.0.2 but I run 4.0.1, so that explains the error.
So for 4.0.1 "enable_user_defined_functions_threads: false" should be
enough, no advance on that I still don't know why my UDF does not compil
Hi Benjamin, Hi everybody,
I found in the documentation that we should add "allow_insecure_udfs: true"
and optionally "allow_extra_insecure_udfs: true" so that
"enable_user_defined_functions_threads: false" is really taken into account
(I understood like that). That
. 28 mars 2022 à 15:35, Benjamin Lerer a
>> écrit :
>>
>>> I do not think that allowing to customize UDF classes whitelist has been
>>> discussed before. Feel free to open a JIRA ticket :-)
>>> I have some plans to revisit how we securise UDFs as the current
nning configuration?
>
> Le lun. 28 mars 2022 à 15:35, Benjamin Lerer a écrit :
>
>> I do not think that allowing to customize UDF classes whitelist has been
>> discussed before. Feel free to open a JIRA ticket :-)
>> I have some plans to revisit how we securise UDFs as the
Unfortunately, it is not working even with
"enable_user_defined_functions_threads: false" in cassandra.yaml :/
Is there any way to check the running configuration?
Le lun. 28 mars 2022 à 15:35, Benjamin Lerer a écrit :
> I do not think that allowing to customize UDF classes white
I do not think that allowing to customize UDF classes whitelist has been
discussed before. Feel free to open a JIRA ticket :-)
I have some plans to revisit how we securise UDFs as the current threading
approach has some impact in terms of latency. That can be a good
opportunity to look
Thanks you very much! I will try that.
As you know, would it be a long-terms solution? Or is there any plan to add
the possibility to customize UDF classes whitelist?
Le lun. 28 mars 2022 à 14:31, Benjamin Lerer a écrit :
> Is there a way to customize that default behaviour?
>
>
see if it works.
Now that also means that you have to ensure that only trusted persons can
create UDF or UDA as it removes all safety mechanisms.
Le lun. 28 mars 2022 à 13:23, Sébastien Rebecchi
a écrit :
> Hi Benjamin,
>
> Thanks for the answer.
> Is there a way to customize that def
8 mars 2022 à 11:31, Sébastien Rebecchi
> a écrit :
>
>> Hello,
>>
>> I am trying to create a UDF based on custom methods.
>> So I set enable_user_defined_functions to true and added a jar in
>> "/usr/share/cassandra/lib/" folder on every node, restarted
.
Le lun. 28 mars 2022 à 11:31, Sébastien Rebecchi
a écrit :
> Hello,
>
> I am trying to create a UDF based on custom methods.
> So I set enable_user_defined_functions to true and added a jar in
> "/usr/share/cassandra/lib/" folder on every node, restarted the nodes and I
&
Hello,
I am trying to create a UDF based on custom methods.
So I set enable_user_defined_functions to true and added a jar in
"/usr/share/cassandra/lib/" folder on every node, restarted the nodes and I
can see from the command line that the jar is indeed used (in the classpat
>>> +1
>>>
>>> Best Regards,
>>>
>>> Aleksei Zotov.
>>>
>>>
>>> On Thu, Jan 20, 2022 at 11:52 AM Marcus Eriksson
>>> wrote:
>>>
>>>> +1
>>>>
>>>> On Tue, Jan 18,
18, 2022 at 11:30:01AM -0500, Ekaterina Dimitrova wrote:
>>> > Hi everyone,
>>> >
>>> > With the work to add Java 17 support for Cassandra, a new question
>>> around
>>> > the future of UDF was raised. The scripted UDF was using Nashorn which
>
8, 2022 at 11:30:01AM -0500, Ekaterina Dimitrova wrote:
>> > Hi everyone,
>> >
>> > With the work to add Java 17 support for Cassandra, a new question
>> around
>> > the future of UDF was raised. The scripted UDF was using Nashorn which
>> is
>
+1
Best Regards,
Aleksei Zotov.
On Thu, Jan 20, 2022 at 11:52 AM Marcus Eriksson wrote:
> +1
>
> On Tue, Jan 18, 2022 at 11:30:01AM -0500, Ekaterina Dimitrova wrote:
> > Hi everyone,
> >
> > With the work to add Java 17 support for Cassandra, a new question a
+1
On Tue, Jan 18, 2022 at 11:30:01AM -0500, Ekaterina Dimitrova wrote:
> Hi everyone,
>
> With the work to add Java 17 support for Cassandra, a new question around
> the future of UDF was raised. The scripted UDF was using Nashorn which is
> no longer packaged with the JDK. Th
or, but possibly provide hooks for people to write their own UDF
> "engines" and break out the current javascript implementation in to its own
> repository (but not ship it with Cassandra).
> >
> >
> > +1
> >
> > Just want to clarify, is the scripted UDF the o
Yes, just javascript.
On Wed, Jan 19, 2022 at 1:20 PM Yifan Cai wrote:
>>
>> I think we should deprecate scripted UDFs now and drop them from the next
>> major, but possibly provide hooks for people to write their own UDF
>> "engines" and break out the
>
> I think we should deprecate scripted UDFs now and drop them from the next
> major, but possibly provide hooks for people to write their own UDF
> "engines" and break out the current javascript implementation in to its own
> repository (but not ship it with Ca
katerina Dimitrova
> >>> wrote:
> >>> >
> >>> > Hi everyone,
> >>> >
> >>> > With the work to add Java 17 support for Cassandra, a new question
> >>> around the future of UDF was raised. The scripted UDF was using Nashor
12:31 użytkownik Brandon Williams
>> napisał:
>>
>>> +1
>>>
>>> On Tue, Jan 18, 2022 at 10:30 AM Ekaterina Dimitrova
>>> wrote:
>>> >
>>> > Hi everyone,
>>> >
>>> > With the work to add Java 17 supp
com> escreveu:
> +1 (Nb)
>
> śr., 19 sty 2022, 12:31 użytkownik Brandon Williams
> napisał:
>
>> +1
>>
>> On Tue, Jan 18, 2022 at 10:30 AM Ekaterina Dimitrova
>> wrote:
>> >
>> > Hi everyone,
>> >
>> > With the work to add Jav
+1 (Nb)
śr., 19 sty 2022, 12:31 użytkownik Brandon Williams
napisał:
> +1
>
> On Tue, Jan 18, 2022 at 10:30 AM Ekaterina Dimitrova
> wrote:
> >
> > Hi everyone,
> >
> > With the work to add Java 17 support for Cassandra, a new question
> around the fut
+1
On Tue, Jan 18, 2022 at 10:30 AM Ekaterina Dimitrova
wrote:
>
> Hi everyone,
>
> With the work to add Java 17 support for Cassandra, a new question around the
> future of UDF was raised. The scripted UDF was using Nashorn which is no
> longer packaged with the JDK. There
+1
> On Jan 18, 2022, at 8:38 AM, Jonathan Ellis wrote:
>
>
> +1
>
>> On Tue, Jan 18, 2022 at 10:34 AM C. Scott Andreas
>> wrote:
>> I also (+1nb) support a proposal to deprecate JavaScript UDFs; to offer an
>> interface for those who wo
+1
On Tue, Jan 18, 2022 at 10:34 AM C. Scott Andreas
wrote:
> I also (+1nb) support a proposal to deprecate JavaScript UDFs; to offer an
> interface for those who would like to supply a UDF implementation; and to
> extract/remove our current implementation.
>
> JDK17 support se
I also (+1nb) support a proposal to deprecate JavaScript UDFs; to offer an
interface for those who would like to supply a UDF implementation; and to
extract/remove our current implementation.
JDK17 support seems like a much higher priority than in-tree JS UDFs.
— Scott
> On Jan 18, 2022, a
Hi everyone,
With the work to add Java 17 support for Cassandra, a new question around
the future of UDF was raised. The scripted UDF was using Nashorn which is
no longer packaged with the JDK. There are options to add new dependencies
to Graal JS for example but it seems people are not sure
I'm +1 with this solution going in 4.0.
That said, this make we realize that through this dependency we've
ended up exposing (publicly) a bit too much to UDF. Namely, all we really
need/want to expose for UDF is the "value" classes (UDTValue, TupleValue,
Duration and LocalDate) and
;> Hi Robert,
>>>
>>> Thanks for taking on this work. Is this message a heads up that a patch
>> is
>>> coming/complete, or to spawn a discussion about including this in 4.0?
>>>
>>> Thanks,
>>>
>>> -Jason
>
>>
>>> Thanks for taking on this work. Is this message a heads up that a patch
>> is
>>> coming/complete, or to spawn a discussion about including this in 4.0?
>>>
>>> Thanks,
>>>
>>> -Jason
>>>
>>> On Tue, Sep 11, 2018 at
ch
> is
> > coming/complete, or to spawn a discussion about including this in 4.0?
> >
> > Thanks,
> >
> > -Jason
> >
> > On Tue, Sep 11, 2018 at 2:32 AM, Robert Stupp wrote:
> >
> >> In an effort to clean up our hygiene and limit the dependencies use
t 2:32 AM, Robert Stupp wrote:
>
>> In an effort to clean up our hygiene and limit the dependencies used by
>> UDFs/UDAs, I think we should refactor the UDF code parts and remove the
>> dependency to the Java Driver in that area without breaking existing
>> UDFs/UDAs.
>>
/complete, or to spawn a discussion about including this in 4.0?
Thanks,
-Jason
On Tue, Sep 11, 2018 at 2:32 AM, Robert Stupp wrote:
In an effort to clean up our hygiene and limit the dependencies used by
UDFs/UDAs, I think we should refactor the UDF code parts and remove the
dependency
ies used by
> UDFs/UDAs, I think we should refactor the UDF code parts and remove the
> dependency to the Java Driver in that area without breaking existing
> UDFs/UDAs.
>
> A working prototype is in this branch: https://github.com/snazy/
> cassandra/tree/feature/remove-udf-drive
In an effort to clean up our hygiene and limit the dependencies used by
UDFs/UDAs, I think we should refactor the UDF code parts and remove the
dependency to the Java Driver in that area without breaking existing UDFs/UDAs.
A working prototype is in this branch:
https://github.com/snazy
Hi All,
I am new to the Cassandra community and thank you in advance for your kindly
comments on an issue we met recently.
We have found that running query with direct UDF execution is ten time more
faster than the async UDF execution. The in-line comment: "Using async UDF
exec
42 matches
Mail list logo
