Thank you Stefan.
“ Other than that, I do not remember I have touched /
worked with any other mentioned parameter she elaborated on between
4.0 and 4.1 so I can not comment on that.”
Not sure what do you mean here as the parameters which are affected are all
duration, data rate and data storage.
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 would explain why my UDF still
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 compile
then
Le m
Hi Sebastian,
Do you use the latest 4.0.3 version? Those options were added in 4.0.2 I
believe, so if you try them with an earlier version - below message is what
you would get as they didn’t exist.
Best regards,
Ekaterina
On Wed, 6 Apr 2022 at 9:53, Sébastien Rebecchi
wrote:
> Hi Benjamin, Hi
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 "enable_user_defined_functions: true"
and "enable_user_defined_functions_threads: false
The property you are setting permits some kinds of privilege escalation, but by
default classes outside of those pre-defined by the whitelist are not
permitted. This is imposed here:
https://github.com/apache/cassandra/blob/210793f943dc522161fd26b6192f38a5c83fa131/src/java/org/apache/cassandra/c
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 mer. 6 avr. 2
Hi All
A quick update - I am working with someone on a potential first Cassandra
related podcast. We are just looking at the questions and interview format etc
to see how that could work.
Thanks
Sharan
On 2022/04/02 11:43:32 Mick Semb Wever wrote:
> >
> >
> > For those who are not familiar wit
Hi Paulo
We have great news - the Performance Engineering track has been accepted so we
will be looking to encourage and promote CFP submissions for it. We are also
looking for reviewers to help us rate the submissions---if you are still
interested in doing that. ;-)
Thanks
Sharan
On 2022/03
Sharan,
FWIW - Patrick and I are also working on putting together a Cassandra
podcast in the near future. Perhaps we could work together? Drop me a
message at aaron.plo...@datastax.com, and I'd be happy to set up some time
to discuss.
Thanks,
Aaron
On Wed, Apr 6, 2022 at 10:07 AM Sharan Foga
I would say keep the old ones and add new ones to be compatible in addition.
Now your catch led me to more thinking and I think throwing
ConfigurationException deserves more attention. I noticed in
DatabaseDescriptor there are setters that are leaking it to JMX since
cassandra-3.0. I am not sure wh
On Tue, 5 Apr 2022 12:20:49 +0100, you wrote:
>I would strongly recommend keeping Python 3.6 compatibility until
>2024-06-30 when the CentOS 7 maintenance updates is stopped.
I would point out that the RHEL 8.* (as seen on Rocky Linux 8.5)
releases come with Python 3.6 and I don't see anything n
>
> I noticed in DatabaseDescriptor there are setters that are leaking it to
> JMX since cassandra-3.0. I am not sure whether we can just change it to
> IllegalArgumentException which will be then also thrown on startup where
> they were ConfigurationExceptions before
My concern here is maintenan
That’s great to hear. I would also be available to help review submissions.
> On Apr 6, 2022, at 8:14 AM, Sharan Foga wrote:
>
> Hi Paulo
>
> We have great news - the Performance Engineering track has been accepted so
> we will be looking to encourage and promote CFP submissions for it. We a
This. RHEL8 is going to be around for a long while, so I'd say
python-3.6 should not be dropped for a long while. 2029 EOL is the date
I see on the RHEL8 Planning Guide[0]..
I saw the RHEL7/CentOS7 comments earlier and immediately thought about
RHEL8 and python-3.6, since I'm working in that O
15 matches
Mail list logo