Re: Is there any change to integrate ignite into Android environment?
We are not running Ignite test suites on Android, thus, don't have a full picture of what works or fails. Please file a ticket with the stack trace and details about your Android environment. But, you have the REST protocol at your service that will work on any edge device. Use Android networking APIs to make calls to your Ignite cluster via REST: https://ignite.apache.org/docs/latest/restapi - Denis On Wed, Nov 11, 2020 at 6:58 PM xingjl6280 wrote: > Hi IIya, > > yes, I tried, with the java thin client. > > There's no issue with build, but get fatal error during client initiation. > Ignite try to call some virtual method of Object by reflection, but the > method doesn't exist. > I guess it's due to the difference of Android SDK and JDK. > > Actually, in many manufacturing scenarios, Apps are installed on Pad with > good performance and LAN network, > Ignite will provide those Apps with more convenient communication with > backend, or even IOT device. > > So the initial design of Ignite didn't take Android into consideration, > right? And there's no another version for Android? > I may give up this idea. > > Thank you > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >
Re: Is there any change to integrate ignite into Android environment?
Hi IIya, yes, I tried, with the java thin client. There's no issue with build, but get fatal error during client initiation. Ignite try to call some virtual method of Object by reflection, but the method doesn't exist. I guess it's due to the difference of Android SDK and JDK. Actually, in many manufacturing scenarios, Apps are installed on Pad with good performance and LAN network, Ignite will provide those Apps with more convenient communication with backend, or even IOT device. So the initial design of Ignite didn't take Android into consideration, right? And there's no another version for Android? I may give up this idea. Thank you -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Query on IgniteApplication running on java11
Hi, In my machine jdk 11 is installed and I am trying to write an Ignite application to run on this environment. In my pom.xml, I have added below maven-compiler-plugin configuration and compiled the code. org.apache.maven.plugins maven-compiler-plugin 3.8.0 --add-exports java.base/jdk.internal.misc=ALL-UNNAMED --add-exports java.base/sun.nio.ch=ALL-UNNAMED --add-exports java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED --add-exports jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED Now my question is do I need to use the same JVM_OPTs when I start the client application like below: java $JVM_OPTS -cp Currently I am not using the JVM_OPTS and the application is *running fine* but in below link it is mentioned it needs to be set. https://ignite.apache.org/docs/latest/quick-start/java#running-ignite-with-java-11-or-later May I know, will there be any issue if I do not use the JVM_OPTS ? Regards, Vishwas -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Performance of indexing on varchar columns without specific length
Hello! The actual VARCHAR lengths means less than you think. Instead, you can supply a correct INLINE_SIZE when creating this index: https://ignite.apache.org/docs/latest/SQL/sql-tuning#increasing-index-inline-size https://ignite.apache.org/docs/latest/SQL/indexes#configuring-index-inline-size By default it's 10, and some of those bytes are used for length, etc. Regards, -- Ilya Kasnacheev пт, 6 нояб. 2020 г. в 21:04, Shravya Nethula < shravya.neth...@aline-consulting.com>: > Hi, > > A table has two varchar columns, one column created with specific column > length and other created without any specific length as shown below: > CREATE TABLE person (id LONG PRIMARY KEY, name VARCHAR(64), last_name > VARCHAR) > > Can we create index on varchar columns without any specific length? In the > above scenario, can we create index on last_name column? > And while creating index on those columns, will there be any performance > difference on these columns? > > > Regards, > > Shravya Nethula, > > BigData Developer, > > > Hyderabad. > >
Re: Workaround for getting ContinuousQuery to support transactions
Hello!
I think it's OK to try.
Regards,
--
Ilya Kasnacheev
пн, 9 нояб. 2020 г. в 19:56, ssansoy :
> interesting! might just work. We will try it out.
> E.g. A chance of 500 V's. V has fields a, b, c, (b=foo on all records) and
> some client app wants to run a continuous query on all V where b=foo, or
> was
> =foo but now is not following the update.
>
> The writer updates 100 V's, by setting b=bar on all records, and some
> incrementing version int N
> The datastreamer transformer mutates V by adding a new field called
> "changes" which contains b=foo to denote that only the field b was changed,
> and it's old value was foo. (e.g. a set of {fieldname, oldvalue}, { )
> The writer updates the V_signal cache to denote a change was made, with
> version N.
>
> The client continuous query listens to the V_signal cache. When it receives
> an update (denoting V updates have occurred), it does a scanquery on V in
> the transformer, (scan query filters the records that were updated as part
> of version N, and either the fields we care about match our predicate, or
> the "changes" field are one of the ones we are interested in and match the
> predicate).
>
> These are batched up as a collection and returned to the client. Does this
> seem like a reasonable approach?
>
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>
Re: How to get column names for a query in Ignite thin client mode
Hello!
You can find out data types while using JDBC API, by using
ResultSetMetaData and DatabaseMetaData interfaces.
Regards,
--
Ilya Kasnacheev
пн, 9 нояб. 2020 г. в 10:42, Shravya Nethula <
shravya.neth...@aline-consulting.com>:
> Hi,
>
> Any update on this?
> Any help is much apppreciated!
>
> Regards,
>
> Shravya Nethula,
>
> BigData Developer,
>
>
> Hyderabad.
>
> --
> *From:* Shravya Nethula
> *Sent:* Thursday, November 5, 2020 4:54 PM
> *To:* user@ignite.apache.org
> *Cc:* Bhargav Kunamneni
> *Subject:* Re: How to get column names for a query in Ignite thin client
> mode
>
> Hi Alex,
>
> Thank you for the information.
> Is there a possibility of getting the datatypes in thick client mode?
>
> Regards,
>
> Shravya Nethula,
>
> BigData Developer,
>
>
> Hyderabad.
>
> --
> *From:* Alex Plehanov
> *Sent:* Thursday, November 5, 2020 12:03 PM
> *To:* user@ignite.apache.org
> *Cc:* Bhargav Kunamneni
> *Subject:* Re: How to get column names for a query in Ignite thin client
> mode
>
> Currently, only field names can be obtained, there is no information about
> field data types in thin client protocol.
>
> ср, 4 нояб. 2020 г. в 13:58, Shravya Nethula <
> shravya.neth...@aline-consulting.com>:
>
> Ilya and Alex,
>
> Thank you for information.
> Can you please also suggest how to get the datatypes of those columns
> obtained from the query?
>
>
> Regards,
>
> Shravya Nethula,
>
> BigData Developer,
>
>
> Hyderabad.
>
>
> --
> *From:* Alex Plehanov
> *Sent:* Tuesday, November 3, 2020 12:13 PM
> *To:* user@ignite.apache.org
> *Subject:* Re: How to get column names for a query in Ignite thin client
> mode
>
> Columns information is read by thin-client only after the first data
> request, so you need to read at least one row to get columns.
>
> вт, 3 нояб. 2020 г. в 09:31, Ilya Kazakov :
>
> Hello, Shravya! It is very interesting! I am trying to reproduce your
> case, and what I see. I can see column names in the thin client only after
> query execution.
>
> For example:
>
> ClientConfiguration clientConfig = new
> ClientConfiguration().setAddresses("127.0.0.1");
> try(IgniteClient thinClient = Ignition.startClient(clientConfig)){
> SqlFieldsQuery sql = new SqlFieldsQuery("SELECT * FROM T1");
> FieldsQueryCursor cursor = thinClient.query(sql);
> cursor.getAll();
> int count = cursor.getColumnsCount();
> System.out.println(count);
> List columnNames = new ArrayList<>();
> for (int i = 0; i < count; i++) {
> String columnName = cursor.getFieldName(i);
> columnNames.add(columnName);
> }
> System.out.println("columnNames:::"+columnNames);
> }
>
>
> But if this is the correct behavior I do not know yet, I will try to find
> out.
>
>
> Ilya Kazakov
>
> вт, 3 нояб. 2020 г. в 12:51, Shravya Nethula <
> shravya.neth...@aline-consulting.com>:
>
> Hi,
>
> *For Ignite thick client, the column names for a given sql query are
> coming up as expected with the following code:*
> public class ClientNode {
>
> public static void main(String[] args) {
> IgniteConfiguration igniteCfg = new IgniteConfiguration();
> igniteCfg.setClientMode(true);
>
> Ignite ignite = Ignition.start(igniteCfg);
> *IgniteCache foo **= ignite.getOrCreateCache("foo");*
>
> SqlFieldsQuery sql = new SqlFieldsQuery("SELECT * FROM person");
> *FieldsQueryCursor cursor = foo.query(sql);*
> int count = cursor.getColumnsCount();
> List columnNames = new ArrayList<>();
>
> for (int i = 0; i < count; i++) {
> String columnName = cursor.getFieldName(i);
> columnNames.add(columnName);
> }
> System.out.println("columnNames:::"+columnNames);
>
> } }
> *Output:*
> *columnNames:::[ID, NAME, LAST_NAME, AGE, CITY_ID, EMAIL_ID]
> *
> *On the other hand, for thin client, the column names are coming up as empty
> list.*
> The following is the code:
> public class ClientNode {
>
> public static void main(String[] args) {
> ClientConfiguration clientConfig = new ClientConfiguration();
> cc.setUserName("username");
> cc.setUserPassword("password");
>
> *IgniteClient thinClient = Ignition.startClient(clientConfig);*
>
> SqlFieldsQuery sql = new SqlFieldsQuery("SELECT * FROM person");
> *FieldsQueryCursor cursor = thinClient.query(sql);*
> int count = cursor.getColumnsCount();
> List columnNames = new ArrayList<>();
>
> for (int i = 0; i < count; i++) {
> String columnName = cursor.getFieldName(i);
> columnNames.add(columnName);
> }
> System.out.println("columnNames:::"+columnNames);
>
> } }
>
> *Output:**columnNames:::[ ]*
>
> While using IgniteCache.query(SqlFieldsQuery), the column names are
> coming up. But while using IgniteClient.query(SqlFieldsQuery), the column
>
Re: partition-exchanger system-critical thread blocked
Hello! Can you please find an actual stack trace from partition-exchanger thread in that log? One that starts with Thread [name="partition-exchanger" ? Regards, -- Ilya Kasnacheev вт, 10 нояб. 2020 г. в 15:54, Kamlesh Joshi : > Hi Igniters, > > > > Sometimes 'Blocked system-critical thread' errors are getting printed in > prod cluster logs. As per below logs, it's saying exchange-worker blocked > for 60s. There is no node join/left or cluster activation or cache > creation, still why partition exchange is triggered. Even it is triggered, > it is blocked for *60s *which is huge time from prod perspective. > > > > Below are error details, > > [2020-11-09T10:55:18,888][ERROR][sys-stripe-118-#119%EDIFCustomerCC%][G] > Blocked system-critical thread has been detected. This can lead to > cluster-wide undefined behaviour [threadName=partition-exchanger, > *blockedFor=60s*] > > [2020-11-09T10:55:18,888][WARN ][sys-stripe-118-#119%EDIFCustomerCC%][G] > Thread [name="exchange-worker-#344%EDIFCustomerCC%", id=391, > state=TIMED_WAITING, blockCnt=16, waitCnt=2469961] > > > > Cluster is responding but these errors priting, we are not understanding > what's the cause, could you please help us. > > > > Below is log snippet, > > > > [2020-11-09T10:51:21,458][INFO > ][db-checkpoint-thread-#384%EDIFCustomerCC%][GridCacheDatabaseSharedManager] > Checkpoint started [checkpointId=3bd28c8f-d9c9-4110-ab8c-24cf3a5c44a3, > startPtr=FileWALPointer [idx=1279664, fileOff=28148165, len=49557], > checkpointLockWait=0ms, checkpointLockHoldTime=34ms, > walCpRecordFsyncDuration=7ms, pages=84152, reason='timeout'] > > [2020-11-09T10:51:23,499][INFO > ][db-checkpoint-thread-#384%EDIFCustomerCC%][GridCacheDatabaseSharedManager] > Checkpoint finished [cpId=3bd28c8f-d9c9-4110-ab8c-24cf3a5c44a3, > pages=84152, markPos=FileWALPointer [idx=1279664, fileOff=28148165, > len=49557], walSegmentsCleared=5, walSegmentsCovered=[1279658 - 1279663], > markDuration=79ms, pagesWrite=1195ms, fsync=845ms, total=2119ms] > > [2020-11-09T10:51:36,788][INFO > ][wal-file-archiver%EDIFCustomerCC-#345%EDIFCustomerCC%][FileWriteAheadLogManager] > Starting to copy WAL segment [absIdx=1279664, segIdx=4, > origFile=/datastore1/wal/node00-651e4920-2fb4-4dd5-9258-52a9f359ac35/0004.wal, > dstFile=/datastore1/archive/node00-651e4920-2fb4-4dd5-9258-52a9f359ac35/01279664.wal] > > [2020-11-09T10:51:36,954][INFO > ][wal-file-archiver%EDIFCustomerCC-#345%EDIFCustomerCC%][FileWriteAheadLogManager] > Copied file > [src=/datastore1/wal/node00-651e4920-2fb4-4dd5-9258-52a9f359ac35/0004.wal, > dst=/datastore1/archive/node00-651e4920-2fb4-4dd5-9258-52a9f359ac35/01279664.wal] > > [2020-11-09T10:52:02,018][INFO > ][wal-file-archiver%EDIFCustomerCC-#345%EDIFCustomerCC%][FileWriteAheadLogManager] > Starting to copy WAL segment [absIdx=1279665, segIdx=5, > origFile=/datastore1/wal/node00-651e4920-2fb4-4dd5-9258-52a9f359ac35/0005.wal, > dstFile=/datastore1/archive/node00-651e4920-2fb4-4dd5-9258-52a9f359ac35/01279665.wal] > > [2020-11-09T10:52:02,200][INFO > ][wal-file-archiver%EDIFCustomerCC-#345%EDIFCustomerCC%][FileWriteAheadLogManager] > Copied file > [src=/datastore1/wal/node00-651e4920-2fb4-4dd5-9258-52a9f359ac35/0005.wal, > dst=/datastore1/archive/node00-651e4920-2fb4-4dd5-9258-52a9f359ac35/01279665.wal] > > [2020-11-09T10:52:36,541][INFO > ][wal-file-archiver%EDIFCustomerCC-#345%EDIFCustomerCC%][FileWriteAheadLogManager] > Starting to copy WAL segment [absIdx=1279666, segIdx=6, > origFile=/datastore1/wal/node00-651e4920-2fb4-4dd5-9258-52a9f359ac35/0006.wal, > dstFile=/datastore1/archive/node00-651e4920-2fb4-4dd5-9258-52a9f359ac35/01279666.wal] > > [2020-11-09T10:52:36,703][INFO > ][wal-file-archiver%EDIFCustomerCC-#345%EDIFCustomerCC%][FileWriteAheadLogManager] > Copied file > [src=/datastore1/wal/node00-651e4920-2fb4-4dd5-9258-52a9f359ac35/0006.wal, > dst=/datastore1/archive/node00-651e4920-2fb4-4dd5-9258-52a9f359ac35/01279666.wal] > > [2020-11-09T10:53:11,068][INFO > ][wal-file-archiver%EDIFCustomerCC-#345%EDIFCustomerCC%][FileWriteAheadLogManager] > Starting to copy WAL segment [absIdx=1279667, segIdx=7, > origFile=/datastore1/wal/node00-651e4920-2fb4-4dd5-9258-52a9f359ac35/0007.wal, > dstFile=/datastore1/archive/node00-651e4920-2fb4-4dd5-9258-52a9f359ac35/01279667.wal] > > [2020-11-09T10:53:11,239][INFO > ][wal-file-archiver%EDIFCustomerCC-#345%EDIFCustomerCC%][FileWriteAheadLogManager] > Copied file > [src=/datastore1/wal/node00-651e4920-2fb4-4dd5-9258-52a9f359ac35/0007.wal, > dst=/datastore1/archive/node00-651e4920-2fb4-4dd5-9258-52a9f359ac35/01279667.wal] > > [2020-11-09T10:53:45,694][INFO > ][wal-file-archiver%EDIFCustomerCC-#345%EDIFCustomerCC%][FileWriteAheadLogManager] > Starting to copy WAL segment [absIdx=1279668, segIdx=8, >
Re: Limit ignite-rest-http threads
Hello! I guess you can supply your own jetty XML configuration (in ClientConnectorConfiguration) and there you can limit # of its threads. Please refer to Jetty's docs. Regards, -- Ilya Kasnacheev пн, 9 нояб. 2020 г. в 14:37, ashishb888 : > Hi Vladimir, > > I want to limit those threads. I want to control the threads size for > ignite-rest-http. > > BR, > Ashish > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >
Re: Is there any change to integrate ignite into Android environment?
Hello! Did you actually try to do that? I recommend starting with some flavor of thin client since it is much simpler. Regards, -- Ilya Kasnacheev вт, 10 нояб. 2020 г. в 10:37, xingjl6280 : > Hi Denis, > > It's a Android Pad, with 8 cores CPU and 6GB RAM. > > We use the Pad to connect servers and some devices with Ubuntu running. > It's > only working in a stable LAN environgment. > > Is it possible? > > thank you > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >
Re: [2.9.0]Entryprocessor cannot be hot deployed properly via UriDeploymentSpi
Hello! Did that work under 2.8? Can you check If it wasn't, then maybe it is not implemented in the first place. If it is a regression, we could try to address that. Regards. -- Ilya Kasnacheev ср, 11 нояб. 2020 г. в 05:55, 18624049226 <18624049...@163.com>: > Any further conclusions? > > 在 2020/11/6 上午11:00, 18624049226 写道: > > Hi community, > > > > Entryprocessor cannot be hot deployed properly via > > UriDeploymentSpi,the operation steps are as follows: > > > > 1.put jar in the specified folder of uriList; > > > > 2.Use example-deploy.xml,start two ignite nodes; > > > > 3.Use the DeployClient to deploy the service named "deployService"; > > > > 4.Execute the test through ThickClientTest, and the result is correct; > > > > 5.Modify the code of DeployServiceImpl and DeployEntryProcessor, for > > example, change "Hello" to "Hi", then repackage it and put it into the > > specified folder of uriList; > > > > 6.Redeploy services by RedeployClient; > > > > 7.Execute the test again through ThickClientTest, and the result is > > incorrect,we will find that if the Entryprocessor accessed by the > > service is on another node, the Entryprocessor uses the old version of > > the class definition. > > > > > >
