C* uses a hard coded security manager, which is only effective when called from
a UDF. I’ve experimented using Java’s security manager for the whole C*
process, but a) the performance impact was too high and b) it had too many side
effects in the whole code base. TL;DR - it was too complicated ;
Robert,
Thank you for the answer.
Do you know if there is a possibility to replace current security manager
configuration with my own ?
I still want to try run Jython :)
One more question. You wrote about limiting languages to Java and
Javascript.
What about Scala ?
M.
2016-11-05 20:20 GMT+01:0
Maciek,
I fear that Python - or better: Jython - UDFs no longer work since C* 3.0.
Back in C* 2.2.x, there was the idea to allow the use of “all” JSR223 languages
for UDFs - basically all languages that are listed in the lib/jsr223 directory.
UDFs in 2.2.x were not “sandboxed” - i.e. unrestrict
Indeed. I did throw a comment on 11990 - not sure if that triggers emails
to those participants, but was hoping someone would take a look.
On Sat, Nov 5, 2016 at 2:26 AM, DuyHai Doan wrote:
> So from code review, the error message you get from the log is coming from
> the CASSANDRA-11990: http
Yep, already done: https://issues.apache.org/jira/browse/CASSANDRA-12877
On Fri, Nov 4, 2016 at 11:15 PM, Jonathan Haddad wrote:
> Can you file a Jira for this? Would be good to make sure 3.10 doesn't get
> released with this bug.
> On Fri, Nov 4, 2016 at 6:11 PM Voytek Jarnot
> wrote:
>
>> Tho
"But then don't I need to evict for every batch of writes?"
Yes, that's why I think an in-memory distributed data structure is the good
fit for your scenario. Using a log structured merged tree like C* for this
use-case is not the most efficient choice
On Sat, Nov 5, 2016 at 11:52 AM, Kant Kodali
But then don't I need to evict for every batch of writes? I thought cache
would make sense when reads/writes > 1 per say. What do you think?
On Sat, Nov 5, 2016 at 3:33 AM, DuyHai Doan wrote:
> "I have a requirement where I need to know last value that is written
> successfully so I could read t
"I have a requirement where I need to know last value that is written
successfully so I could read that value and do some computation and include
it in the subsequent write"
Maybe keeping the last written value in a distributed cache is cheaper than
doing a read before write in Cassandra ?
On Sat
I have a requirement where I need to know last value that is written
successfully so I could read that value and do some computation and include
it in the subsequent write. For now we are doing read before write which
significantly degrades the performance. Light weight transactions are more
of a c
So from code review, the error message you get from the log is coming from
the CASSANDRA-11990:
https://github.com/ifesdjeen/cassandra/commit/dc4ae57f452e19adbe5a6a2c85f8a4b5a24d4103#diff-eae81aa3b81f9b1e07b109c446447a50R357
Now, it's just the consequence of the problem (throwing an assertion
erro
10 matches
Mail list logo
