Igniters,
In upcoming interop efforts we will need concurrent collections and
primitives in C++ layer. Obvious candidate is Boost, but it appears to be
too heavy. Another library I found is Intel's TBB (
https://www.threadingbuildingblocks.org/) - it is open-source and pretty
light.
Does anyone
Pavel Konstantinov created IGNITE-925:
-
Summary: We should correctly handle cross-cache query exceptions
Key: IGNITE-925
URL: https://issues.apache.org/jira/browse/IGNITE-925
Project: Ignite
On Wed, May 20, 2015 at 12:01 AM, Vladimir Ozerov voze...@gridgain.com
wrote:
C++11 users can use C++03 projects, but not vice-versa.
Are we sacrificing any features? (sorry, my C++ knowledge is limited).
On Wed, May 20, 2015 at 9:52 AM, Dmitriy Setrakyan dsetrak...@apache.org
wrote:
On
Igniters,
We need to decide which C++ version to use in interop. Currently wide
developer community is in progress of adopting C++11. But if we choose it,
users might have problems if their CPP projects using older C++ revisions
which are still very common.
I think we should stick to C++03
On Tue, May 19, 2015 at 11:27 PM, Vladimir Ozerov voze...@gridgain.com
wrote:
Igniters,
We need to decide which C++ version to use in interop. Currently wide
developer community is in progress of adopting C++11. But if we choose it,
users might have problems if their CPP projects using older
Hi,
I vote for Boost. From my understanding, it is the most comprehensive
extension library, and very widely adopted.
What do you mean by too heavy?
- Did you try to use it and compare dll sizes? How big is the difference?
- Does dll size really matter for us that much?
Thanks,
On Wed,
Anton Vinogradov created IGNITE-926:
---
Summary: Binary release should ends with -bin
Key: IGNITE-926
URL: https://issues.apache.org/jira/browse/IGNITE-926
Project: Ignite
Issue Type: Task
Ok, I've reopened the root issue
https://issues.apache.org/jira/browse/IGNITE-456 and will continue progress.
If there is any objections, let me know.
-- Artem --
On Tue, May 19, 2015 at 8:53 PM, Konstantin Boudnik c...@apache.org wrote:
Here's two reasons why current approach is secure
Brane,
I do not know in advance what exactly will be needed there, but it is
_very_ likley that we will need thread-locals, atomics (both CAS and
increments/decrements), java-like volatiles (i.e. membars), cirical
sections, read-write locks and concurrent dictionaries.
On Wed, May 20, 2015 at
On 20.05.2015 09:40, Vladimir Ozerov wrote:
This is not about resulting size of our lib. Moreover, we will not
statically link it to Ignite because in this case users will have troubles
when using both Boost and Ignite simultaneously.
The problem is that if we use Boost, we will force users to
Brane,
Thanks for clarifications, I mistakenly thought that smart pointers were
introduced only in C++11. If they are already in C++03 of course we should
take advantage of them.
On Wed, May 20, 2015 at 12:08 PM, Branko Čibej br...@apache.org wrote:
On 20.05.2015 09:47, Vladimir Ozerov wrote:
On 20.05.2015 09:47, Vladimir Ozerov wrote:
I do not think we will sacrifice anything. C++11 has lots new features such
as smart pointers and lamdas, but I do not see where we can use them on our
public API.
I would definitely recommend using C++03 (or C++98; the only differences
are in the
I do not think we will sacrifice anything. C++11 has lots new features such
as smart pointers and lamdas, but I do not see where we can use them on our
public API.
For example, both Hazelcast and GigaSpaces has the following API for cache
GET:
boost::shared_ptrMyVal val = cacheMyKey, MyVal.get();
Hi, Igniters,
In process of investigation of a user request Disable ignite console logs
(
http://apache-ignite-users.70518.x6.nabble.com/Disable-ignite-console-logs-td310.html#a330),
I've found inconsistency at implementations of IgniteLogger.isQuiet():
- Javadoc of the method says:
/**
Brane, the API has already been designed. In the best case all
functionality available in Java should be available in non-Java stuff (if
there are no technology limitations). I would not care about compile time -
Boost increases it, of course, but does not make compilation infinite.
Functionality,
There is one thing you could do, depending on which parts of Boost you
need. Boost has a tool to extract only the headers you actually need and
puts the extracted declarations into a custom namespace. If your
dependencies are header-only, you can include those bits in the Ignite
sources. That way,
On Wed, May 20, 2015 at 3:56 AM, moon soo Lee m...@apache.org wrote:
Hi,
Really appreciate for driving ignite-zeppelin integration.
If it is okay, i'd love to spend this week for prototyping interpreter for
ignite.
Thanks Moon, sounds good!
Please let us know if you have any questions
Guys,
We have uploaded release candidate to
https://dist.apache.org/repos/dist/dev/incubator/ignite/1.1.0-rc7/
Tag name is
ignite-1.1.0-incubating-rc7
RC7 changes:
Fixed unexpected LICENSE, NOTICE and DEPENDENCIES files in sources zip.
Fixed LICENSE, NOTICE files content inside ignite-core jar.
There's user ignite-ci, that I created a while ago, but it isn't mandatory to
use it of course ;)
On Thu, May 21, 2015 at 12:23AM, Artiom Shutak wrote:
I've created new Jira user without granting him some additional privileges.
The user cannot move jira status, but he can add any attachment
Hi Moon!
as mentor on both projects but more as as just somebody
who's really curious to see this happen I'd be really excited
to help with prototyping wrt. testing/etc. Please share your
work ASAP. I'm so anxious to get my hands on it!
Thanks,
Roman.
On Wed, May 20, 2015 at 3:56 AM, moon soo
On Wed, May 20, 2015 at 6:26 AM, Yakov Zhdanov yzhda...@gridgain.com
wrote:
I still insist that this should be implemented with great care.
I tend to agree with Cos here. Let's implement this feature. If we get some
malicious contributor attaching bad patches, we will catch it very quickly
and
Hi,
I'll be happy to help with Ignite-Zeppelin integration. It would be great
if you assign the ticket to me.
On Wed, May 20, 2015 at 1:56 PM, moon soo Lee m...@apache.org wrote:
Hi,
Really appreciate for driving ignite-zeppelin integration.
If it is okay, i'd love to spend this week for
Alexey Goncharuk created IGNITE-929:
---
Summary: IgniteCache.close should not delete the cache from the
cluster
Key: IGNITE-929
URL: https://issues.apache.org/jira/browse/IGNITE-929
Project: Ignite
Igniters (especially Sergi),
What happens if I use Java primitives like Doubles as values? Are they
indexed? I just created a simple example which loads some data and executes
this query: 'select max(_val) from Double'. Indexes are not created and the
speed of the query is the same as the speed
On 20.05.2015 21:36, Dmitriy Setrakyan wrote:
On Wed, May 20, 2015 at 6:26 AM, Yakov Zhdanov yzhda...@gridgain.com
wrote:
I still insist that this should be implemented with great care.
I tend to agree with Cos here. Let's implement this feature. If we get some
malicious contributor
Please use the subject tag [RESULT][VOTE] for votes that are complete,
regardless of the vote result; and [CANCELLED][VOTE] for votes that are
cancelled for any reason. Nobody uses [CLOSED][VOTE] anywhere.
-- Brane
Igniters,
Current implementation of clear() method doesn't clear entries if there are
near readers for them. This makes this method ultimately unusable if near
cache is configured (behavior is unpredictable and counterintuitive).
At the same time, the purpose of the method is to invalidate the
Igniters,
As we all know, transactional cache updates persistence store from a client
node, while loads are still done on primary node. But it's not always
possible to have a database connection on client. There is a workaround -
send a closure to server node and start a transaction there. You
Mario Ivankovits created IGNITE-928:
---
Summary: Array out of bounds in IgniteUtils.filterReachable
Key: IGNITE-928
URL: https://issues.apache.org/jira/browse/IGNITE-928
Project: Ignite
29 matches
Mail list logo
