Re: In memory code and query executions
Agreed with Nate. This is generally one of those "if you have to ask how it's done, you shouldn't be doing it" ideas. To add to his points above, deploying new versions of you app with this model is an operational nightmare. Now you've tightly coupled new versions of your app to doing a full cluster restart. You're also not going to find many people who have done this to help you out when you run into problems. Every issue you hit, when you ask on the ML, will likely result in "well you're doing something unsupported so good luck, have fun, but we can't help you". On Wed, May 4, 2016 at 11:16 AM Nate McCallwrote: > On Mon, May 2, 2016 at 11:04 AM, Corry Opdenakker > wrote: > >> Hi all, >> >> Is it possible to execute queries towards an embedded cassandra db whyle >> bypassing completely the TCP (or IPC) protocol stack? >> > > tl,dr: it is not for the faint of heart and you must understand *exactly* > what you are doing. > > First I have to ask is there something specific that is not working the > way you anticipate? > > Short answer is yes, though: > https://github.com/apache/cassandra/tree/cassandra-2.1/examples/client_only > > This was removed in > 2.1 because very few people were using it and it was > confusing to have there as an "example." > > I would not call this embedded so much as running a "client-mode proxy" > but same idea. > > Apparantly the embedded cassandra is by default accessed using localhost >> as hostname which will result in an IPC optimized connection I assume. >> > > Not quite sure what you mean here? > > >> Is there a way to fully omit the Tcp/ipc stack and execute queries >> directly in-memory at the cassandra database? preferrably in a (query >> resultset -> to -> appcode) zero-copy approach. >> >> > Again, yes per the link above, but you would need to modify a few things > for recent versions. The general approach is there however. You could even > go a level below QueryProcessor and invoke methods on StorageProxy > directly, bypassing the parse/PS lookup. > > That all said, you need to understand: > - These are all internal APIs and as such can and will change > substantially without warning even between point releases > - Understanding the internals to use them correctly at this level requires > a deep understanding of the code base > - You will be bypassing a substantial amount of validation and could > easily insert data that will corrupt your table > - You can potentially put a lot more pressure on portions of the system > that anticipate upstream throttling > > In sum: it's possible, but put something in production first using > standard APIs before you go this deep. This is not the level at which you > want to write your first app against Cassandra. > > > -- > - > Nate McCall > Austin, TX > @zznate > > CTO > Apache Cassandra Consulting > http://www.thelastpickle.com >
Re: In memory code and query executions
On Mon, May 2, 2016 at 11:04 AM, Corry Opdenakkerwrote: > Hi all, > > Is it possible to execute queries towards an embedded cassandra db whyle > bypassing completely the TCP (or IPC) protocol stack? > tl,dr: it is not for the faint of heart and you must understand *exactly* what you are doing. First I have to ask is there something specific that is not working the way you anticipate? Short answer is yes, though: https://github.com/apache/cassandra/tree/cassandra-2.1/examples/client_only This was removed in > 2.1 because very few people were using it and it was confusing to have there as an "example." I would not call this embedded so much as running a "client-mode proxy" but same idea. Apparantly the embedded cassandra is by default accessed using localhost as > hostname which will result in an IPC optimized connection I assume. > Not quite sure what you mean here? > Is there a way to fully omit the Tcp/ipc stack and execute queries > directly in-memory at the cassandra database? preferrably in a (query > resultset -> to -> appcode) zero-copy approach. > > Again, yes per the link above, but you would need to modify a few things for recent versions. The general approach is there however. You could even go a level below QueryProcessor and invoke methods on StorageProxy directly, bypassing the parse/PS lookup. That all said, you need to understand: - These are all internal APIs and as such can and will change substantially without warning even between point releases - Understanding the internals to use them correctly at this level requires a deep understanding of the code base - You will be bypassing a substantial amount of validation and could easily insert data that will corrupt your table - You can potentially put a lot more pressure on portions of the system that anticipate upstream throttling In sum: it's possible, but put something in production first using standard APIs before you go this deep. This is not the level at which you want to write your first app against Cassandra. -- - Nate McCall Austin, TX @zznate CTO Apache Cassandra Consulting http://www.thelastpickle.com
Re: CAS operation does not return value on failure
Probably better to ask this on the Java driver user list. -- Jack Krupansky On Wed, May 4, 2016 at 11:46 AM, horschiwrote: > Hi, > > I am doing some testing on CAS operations and I am frequently having the > issue that my resultset says wasApplied()==false, but it does not contain > any value. > > > This behaviour of course leads to the following Exception when I try to > read it: > > Caused by: java.lang.IllegalArgumentException: value is not a column > defined in this metadata > at > com.datastax.driver.core.ColumnDefinitions.getAllIdx(ColumnDefinitions.java:273) > at > com.datastax.driver.core.ColumnDefinitions.getFirstIdx(ColumnDefinitions.java:279) > at > com.datastax.driver.core.ArrayBackedRow.getIndexOf(ArrayBackedRow.java:68) > at > com.datastax.driver.core.AbstractGettableData.getBytes(AbstractGettableData.java:131) > > > > My questions now are: > > Is it to be expected that a failing CAS operation sometimes does this? > > if yes: Shouldn't there a possibility on the driver side to handle this in > a better was, e.g. add a "hasColumn()" method or something to the ResultSet? > > if no: Is that perhaps a symptom to a greater issue in cassandra? > > > kind regards, > Christian > > PS: I also appreciate general feedback on the entire C* CAS topic :-) > > >
CAS operation does not return value on failure
Hi, I am doing some testing on CAS operations and I am frequently having the issue that my resultset says wasApplied()==false, but it does not contain any value. This behaviour of course leads to the following Exception when I try to read it: Caused by: java.lang.IllegalArgumentException: value is not a column defined in this metadata at com.datastax.driver.core.ColumnDefinitions.getAllIdx(ColumnDefinitions.java:273) at com.datastax.driver.core.ColumnDefinitions.getFirstIdx(ColumnDefinitions.java:279) at com.datastax.driver.core.ArrayBackedRow.getIndexOf(ArrayBackedRow.java:68) at com.datastax.driver.core.AbstractGettableData.getBytes(AbstractGettableData.java:131) My questions now are: Is it to be expected that a failing CAS operation sometimes does this? if yes: Shouldn't there a possibility on the driver side to handle this in a better was, e.g. add a "hasColumn()" method or something to the ResultSet? if no: Is that perhaps a symptom to a greater issue in cassandra? kind regards, Christian PS: I also appreciate general feedback on the entire C* CAS topic :-)