Thanks for issuing a ticket. I'll take a look at it.
Best Regards,
Igor
On Fri, Apr 23, 2021 at 1:40 PM teligenz.dheeraj
wrote:
> Team,
>
> I have used nodejs thin client to connect ignite. With single query at time
> on socket works fine. But when hit multiple request simultaneously, getting
Team,
I have used nodejs thin client to connect ignite. With single query at time
on socket works fine. But when hit multiple request simultaneously, getting
frequent error message "Invalid response id: XXX".
when we try to get 5-10 query per sec we getting below error random times.
debug
Done for NodeJs and PHP.
Tests added as well.
https://issues.apache.org/jira/browse/IGNITE-10022
https://github.com/apache/ignite/pull/5187
-Alexey
24.10.2018 17:41, Igor Sapego пишет:
Pavel,
Can we add a proper check and throw proper exception
when trying to deserialize enum value? NPE does
Hi Igor,
Yes, it sounds reasonable, agree.
P.
On Wed, Oct 24, 2018 at 7:42 AM Igor Sapego wrote:
> Pavel,
>
> Can we add a proper check and throw proper exception
> when trying to deserialize enum value? NPE does not say
> anything to a user.
>
> Best Regards,
> Igor
>
>
> On Wed, Oct 24,
Pavel,
Can we add a proper check and throw proper exception
when trying to deserialize enum value? NPE does not say
anything to a user.
Best Regards,
Igor
On Wed, Oct 24, 2018 at 5:34 PM Pavel Petroshenko
wrote:
> Hi Stepan,
>
> Nodejs and PHP clients do not support enum type registration
Hi Stepan,
Nodejs and PHP clients do not support enum type registration (and hence no
tests). So enum type must be registered from somewhere else in order to be
put or get from the Thin clients.
If you register the type say from Java, then put/get for Enum values should
work from the Thin
Alexey,
I'm trying to get Enum from cache which placed by different thin client and
find that i can't get it, only exception
And more when im trying to get Enum which is placed by nodejs client i also
can't do it, have same exception
code and output -
Also it would be better to set the 'atomic' cache to PARTITIONED mode to
equally split the data across all available nodes. This can be done by
setting the 'cacheMode' property to 'PARTITIONED'. Please see [1].
Ivan
[1]
Hi Pavel,
Thanks for trying to run the benchmark. The error arises because an Apache
Ignite node started with the default config does not have the cache with
name '*atomic*'. To run the benchmark you should do the following:
1. Checkout latest '*master*' branch from Apache Ignite repo [1].
Hi Ivan,
I've got through some build issues, but it's still crashing on master [1]
for me:
Thread 1. Client is started
Thread 1. ERROR: Cache does not exist [cacheId= -1407396309]
Thread 1. ERROR: Cache does not exist [cacheId= -1407396309]
Thread 1. ERROR: Cache does not exist [cacheId=
Hi Ivan,
Thanks for taking care of this. I will give the scripts a try and get back
to you if any questions.
Could you please update the JIRA ticket [1] so that we keep it up-to-date.
Thanks!
p.
[1] https://issues.apache.org/jira/browse/IGNITE-8733
On Thu, Jun 7, 2018 at 4:47 AM, Иван
Hi Igniters!
I've prepared two scripts to benchmark the throughput of Node.JS thin
client using 'atomic-put' operations [1]. They work in the following way:
- Main script 'bench-starter.js' starts the given number of thin clients as
sub-processes. AFAIK, Node.JS is one-threaded so we should fork
Hi Pavel,
Thanks for prompt improvements. I'll check them this week.
--
Denis
On Sun, May 27, 2018 at 5:04 PM, Pavel Petroshenko
wrote:
> Hi Denis,
>
> Thanks for your feedback on the documentation! I addressed all your
> comments from https://issues.apache.org/jira/browse/IGNITE-8589.
>
>
Hi Denis,
That's a good point, thanks. This should be a part of the "Usage" section.
I'll follow up in JIRA.
p.
On Thu, May 24, 2018 at 10:49 AM, Denis Magda wrote:
> Pavel,
>
> Recalled that we've not described how to authenticate and set up SSL from
> the client side.
Pavel,
Recalled that we've not described how to authenticate and set up SSL from
the client side. Please consider this for the doc. Left some notes in the
JIRA.
--
Denis
On Wed, May 23, 2018 at 12:25 PM, Denis Magda wrote:
> Alexey, Pavel,
>
> I've done a preliminary review
Alexey, Pavel,
I've done a preliminary review of the doc and moved it to the readme.io
page:
https://apacheignite.readme.io/v2.4/docs/nodejs-thin-client
The page is hidden. I'll grant you access to readme so that you can update
the doc taking my suggestions into account:
Hi,
FYI, HZ also has NodeJs client: https://github.com/
hazelcast/hazelcast-nodejs-client
May be it is worth to take a look?
--
Alexey Kuznetsov
Alexey,
If a lib is contributed to Ignite (accepted to its main sources like the
node.js thin client), then the documentation has to be in a single place
which is readme.io for now.
Having the docs both on readme.io and in sources is confusing and harder to
maintain.
If a lib doesn't not a part
- Let's rename SqlDataProcessingExample.js to just SqlExample.js and
describe it as an example that shows primary APIs to use with Ignite as
with an SQL database.
- Let's rename SqlQueryExample.js to SqlQueryEntiriesExample.js.
Updated.
Denis,
OK for the legacy docs.
Agree for the core docs (specs, common getting started, etc.).
But who/what does mandate that for totally all Ignite related docs?
Why do not follow an approach which many technologies/products follow? -
maintain a centralized list of references to different
Alexey,
Presently, Ignite hosts all the docs in readme.io without exception. It
means that once your contribution is accepted by the community the Node.JS
docs should be placed on readme.io.
You're right saying that we're planning to migrate from readme.io to
another documentation engine that
Denis,
> As for the docs, are you ready to bring them to readme.io? Just let
me know
> and I'll be happy to arrange an account for you and discuss the
structure.
I remember some discussion regarding moving the docs from readme.io to
GitHub pages in 2.6.
No?
In any case, in my opinion, a
Alexey,
Amazing progress and the overall state of the contribution! I'll try to
install and play with the client in the nearest days. As for now, please
consider the following suggestions.
Please do the following changes:
- Let's rename SqlDataProcessingExample.js to just SqlExample.js and
Hi Igor,
all types from the protocol v.2.4 are supported for both read and write.
See [1] for the mappings and explanation.
The idea is to minimize additional non-standard and/or 3rd-party
JavaScript Objects for that.
Timestamp and Enum require additional classes - no better options were
Alexey,
I've checked out the code. Looks good to me. Great job!
What about data types support? I can see Timestamp.
Are you planning to implement other types, e.g. Decimal,
Guid?
Best Regards,
Igor
On Fri, May 11, 2018 at 11:43 AM, Dmitriy Setrakyan
wrote:
> On Fri,
On Fri, May 11, 2018 at 9:14 AM, Alexey Kosenchuk <
alexey.kosenc...@nobitlost.com> wrote:
> Not yet. Need a help with that.
>
I think we definitely need a load test before we merge to master. Can
anyone in the community assist Alexey?
Not yet. Need a help with that.
-Alexey
11.05.2018 10:58, Dmitriy Setrakyan пишет:
This is great! Finally a native NodeJS client for Ignite.
Alexey, in addition to the functional tests, were you able to perform any
load tests?
D.
On Fri, May 11, 2018 at 12:07 AM, Alexey Kosenchuk <
This is great! Finally a native NodeJS client for Ignite.
Alexey, in addition to the functional tests, were you able to perform any
load tests?
D.
On Fri, May 11, 2018 at 12:07 AM, Alexey Kosenchuk <
alexey.kosenc...@nobitlost.com> wrote:
> Folks,
>
> The next version is ready -
> in the pull
Folks,
The next version is ready -
in the pull request [1] or directly in the repo [2].
The version includes:
- full API
- full implementation
- examples
- tests (cover the full API but might need to be updated/extended)
- docs
The details are in the readme [3]
Regards,
-Alexey
[1]
29 matches
Mail list logo