Hi community,
I'd like to share my investigations about the subject.
Even if the caches is off-heap and contains no data, the JVM heap memory
consumed. I'm calling this feature "empty cache memory overhead"
("overhead" later for shot).
The size of the memory consumed depends on many factors,
Roman Shtykh created IGNITE-4539:
Summary: RocketMQ data streamer
Key: IGNITE-4539
URL: https://issues.apache.org/jira/browse/IGNITE-4539
Project: Ignite
Issue Type: New Feature
Alexandr Kuramshin created IGNITE-4538:
--
Summary: BinaryObjectImpl: lack of context information upon
deserialization
Key: IGNITE-4538
URL: https://issues.apache.org/jira/browse/IGNITE-4538
Denis Magda created IGNITE-4537:
---
Summary: Update Notifier must not transfer system properties
Key: IGNITE-4537
URL: https://issues.apache.org/jira/browse/IGNITE-4537
Project: Ignite
Issue
Yakov,
I was actually asking about the public API for messaging
(IgniteMessaging#sendOrdered
method). Here is the JavaDoc:
* The {@code timeout} parameter specifies how long an out-of-order message
will stay in a queue,
* waiting for messages that are ordered ahead of it to arrive. If timeout
GitHub user alexpaschenko opened a pull request:
https://github.com/apache/ignite/pull/1419
IGNITE-4531 Use correct property name in BinaryProperty.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite
Sergi,
What does ‘more effective query plan’ exactly means? Will the aggregation
happen on the data nodes and why this flag set to ‘true’ leads to strange
behavior described here [1] which sounds like a bug?
As for the documentation how would you rewrite existed setCollocated
explanation [2]
GitHub user ascherbakoff opened a pull request:
https://github.com/apache/ignite/pull/1418
ignite-4523
Allow distributed SQL query execution over explicit set of partitions
You can merge this pull request into a Git repository by running:
$ git pull
Yes, this flag indeed is very obscure. Basically it means that if you have
some query with aggregates (at the top level right now) and you know that
you will do GROUP BY by affinity key, then Ignite can generate a more
effective query plan with this flag set.
Sergi
2017-01-10 2:22 GMT+03:00
By the way, I'm working on wiki page about Ignite.NET development:
https://cwiki.apache.org/confluence/display/IGNITE/Ignite.NET+Development
On Tue, Jan 10, 2017 at 11:34 AM, Pavel Tupitsyn
wrote:
> "Pick a Ticket" updated with Ignite.NET section.
>
> On Tue, Jan 10, 2017
GitHub user tledkov-gridgain opened a pull request:
https://github.com/apache/ignite/pull/1417
IGNITE-3400: add available size check before data blocks writing
You can merge this pull request into a Git repository by running:
$ git pull
Alexey Goncharuk created IGNITE-4536:
Summary: Update metrics for new offheap storage
Key: IGNITE-4536
URL: https://issues.apache.org/jira/browse/IGNITE-4536
Project: Ignite
Issue Type:
Alexey Goncharuk created IGNITE-4535:
Summary: Add option to store deserialized values on-heap
Key: IGNITE-4535
URL: https://issues.apache.org/jira/browse/IGNITE-4535
Project: Ignite
Alexey Goncharuk created IGNITE-4534:
Summary: Implement offheap eviction policies based on page memory
Key: IGNITE-4534
URL: https://issues.apache.org/jira/browse/IGNITE-4534
Project: Ignite
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/1392
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
Github user ptupitsyn closed the pull request at:
https://github.com/apache/ignite/pull/1413
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/1384
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
GitHub user iveselovskiy opened a pull request:
https://github.com/apache/ignite/pull/1416
Ignite 4503
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-4503
Alternatively you can review and apply
GitHub user DmitriyGovorukhin opened a pull request:
https://github.com/apache/ignite/pull/1415
Ignite gg 11414
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-gg-11414
Alternatively you can review
GitHub user dkarachentsev opened a pull request:
https://github.com/apache/ignite/pull/1414
Ignite 4525
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-4525
Alternatively you can review and apply
I like the idea to use the full range notation like 10.0.0.1..10.0.0.100.
One issue we may face is the using of the addresses from different networks
like 10.0.0.201..10.0.1.100.
On Tue, Jan 10, 2017 at 1:35 PM, Yakov Zhdanov wrote:
> Guys, before I file a ticket - should
I would place it under Ignite for consistency with other streamers.
--Yakov
GitHub user ptupitsyn opened a pull request:
https://github.com/apache/ignite/pull/1413
IGNITE-4532 .NET: Fix build warnings
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ptupitsyn/ignite ignite-4532
Alternatively you can
We dont have any specific case. You can close this ticket.
2017-01-06 21:26 GMT+03:00 Denis Magda :
> + dev list
>
> Nikita, if this is not the feature that is needed then we can close the
> ticket and I would suggest you picking up another one.
>
> —
> Denis
>
> > On Jan 6,
Guys, before I file a ticket - should we support range notation for each
byte in IP address? I think we should.
--Yakov
Val, timeout still makes sense for task sessions. It is possible that all
jobs mapped to node have been completed, but node still receives
attributes. Attributes are sent in ordered messages. It may happen so that
node may start processing jobs for that task again and this way all the
attributes
GitHub user alexpaschenko opened a pull request:
https://github.com/apache/ignite/pull/1412
Ignite 4489
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-4489
Alternatively you can review and apply
I think we should fix log output as well and replace all "grid" occurences
with "instance".
On Tue, Jan 10, 2017 at 12:55 PM, Alexander Fedotov <
alexander.fedot...@gmail.com> wrote:
> Hi,
>
> I think we should leave null as a default value for unnamed Ignite
> instances. At least that change
Hi,
I think we should leave null as a default value for unnamed Ignite
instances. At least that change should be considered out of the current
scope.
What about naming, I'm also renaming log occurrences of "grid" and "grid
name" where it stands reasonable.
Are there places in the logging logic
Alexandr Kuramshin created IGNITE-4533:
--
Summary: GridDhtPartitionsExchangeFuture stores unnecessary
messages after processing done
Key: IGNITE-4533
URL: https://issues.apache.org/jira/browse/IGNITE-4533
"Pick a Ticket" updated with Ignite.NET section.
On Tue, Jan 10, 2017 at 12:11 AM, Denis Magda wrote:
> Great, Sergey thanks! I’ve added you to the contributors list on Ignite’s
> main site.
> https://ignite.apache.org/community/resources.html#people <
>
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/1396
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
32 matches
Mail list logo