[jira] [Created] (IGNITE-1893) sh-files in yardstick ignite have no executable attribute

Pavel Konstantinov created IGNITE-1893: -- Summary: sh-files in yardstick ignite have no executable attribute Key: IGNITE-1893 URL: https://issues.apache.org/jira/browse/IGNITE-1893 Project: Ignite

[GitHub] ignite pull request: IGNITE-1887 Change queryId generation from se...

GitHub user nva opened a pull request: https://github.com/apache/ignite/pull/223 IGNITE-1887 Change queryId generation from sequence to random. You can merge this pull request into a Git repository by running: $ git pull https://github.com/nva/ignite ignite-1887 Alternatively

[jira] [Created] (IGNITE-1892) Incorrect focus on table fields

Vasiliy Sisko created IGNITE-1892: - Summary: Incorrect focus on table fields Key: IGNITE-1892 URL: https://issues.apache.org/jira/browse/IGNITE-1892 Project: Ignite Issue Type: Sub-task

Re: OSGi migration may require a special marshaller

Raul, I think I see your point and agree. However, in Ignite 1.5 the OptimizedMarshaller will be deprecated in favor of internal cross-platform Binary format. I think we should wait till 1.5 is released and then implement your fix in 1.6 within the scope of Ignite binary protocol. Just one ask,

Re: OSGi Manifest headers and feature repository pushed (IGNITE-1527)

Raul, As far as I know, here is what you get with bundles: 1. Bundle can be loaded independently from other bundles. This is false in Ignite. Every optional dependency in Ignite has to be loaded together with ignite-core module. For example, “ignite-kafka" module should be a fragment, because it

Re: OSGi Manifest headers and feature repository pushed (IGNITE-1527)

No, Dmitriy. The policy should be to use the right technique for each job, and to be respectful with the concepts in the underlying standards. Fragments and Bundles must be used where they belong and according to their roles in the OSGi specification. Users don't need to know the rationale. They

Re: OSGi Manifest headers and feature repository pushed (IGNITE-1527)

Raul, Personally, I find this policy to be a bit too scientific and it is likely to confuse most of our users. From a consistency standpoint why not pick one path, Bundle or Fragment, and roll with it. According to OSGI Wiki [1], a Fragment is something that belongs to a parent bundle and shares

[GitHub] ignite pull request: Do not destroy LOCAL cache on close()

GitHub user vkulichenko opened a pull request: https://github.com/apache/ignite/pull/222 Do not destroy LOCAL cache on close() You can merge this pull request into a Git repository by running: $ git pull https://github.com/vkulichenko/incubator-ignite ignite-local-cache-close

[jira] [Created] (IGNITE-1891) SSL on Windows

/2001:0:9d38:6ab8:2099:222b:4db9:9941:47500], discPort=47500, order=1, intOrder=1, lastExchangeTime=1447267436638, loc=false, ver=1.5.0#2015-sha1:388a8921, isClient=false], topic=TOPIC_CACHE, msg=GridDhtPartitionsSingleMessage [parts={-2100569601=GridDhtPartitionMap [nodeId=de92d445-9162-43b1-

Re: Ignite-1.5 Release

At the moment I am getting closer to finish with IGNITE-1816 - optional compaction of portable object footers. In general feature works. In the nearest time I am going to perform some microbenchmarks to understand implications. Two things left: - I have to rework lots of binary object unit tests be

Re: IGFS URI authority: simplify handling of IGFS and Grid names.

I also agree (I think). Would prohibiting nulls also make sense? On Wed, Nov 11, 2015 at 4:04 AM, Vladimir Ozerov wrote: > +1 > > User should have minimal chance to do a mistake in common scenarios. > > On Wed, Nov 11, 2015 at 1:47 PM, Ivan V. > wrote: > > > Hi, dev, > > currently IGFS URI has

[GitHub] ignite pull request: IGNITE-1788: duplicate checking is removed.

GitHub user iveselovskiy opened a pull request: https://github.com/apache/ignite/pull/221 IGNITE-1788: duplicate checking is removed. You can merge this pull request into a Git repository by running: $ git pull https://github.com/iveselovskiy/ignite ignite-1788 Alternatively

[jira] [Created] (IGNITE-1890) ignitevisorcmd: description for "-dl" key for "log" command should be updated

Vasilisa Sidorova created IGNITE-1890: -- Summary: ignitevisorcmd: description for "-dl" key for "log" command should be updated Key: IGNITE-1890 URL: https://issues.apache.org/jira/browse/IGNITE-1890

[GitHub] ignite pull request: IGNITE-1694 .Net: More efficient way to call ...

GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/220 IGNITE-1694 .Net: More efficient way to call native methods. You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptupitsyn/ignite ignite-1694 Alt

Re: OSGi migration may require a special marshaller

On Wed, Nov 11, 2015 at 1:48 AM, Dmitriy Setrakyan wrote: > Raul, we cannot be adding package name and version in all cases, as it will > have a negative impact on performance, especially when there is an > *optimistic* approach that requires no over-the-wire overhead whatsoever. > Why do we nee

Re: OptimizedClassDescriptor verifyChecksum object set as optional

Hi Jiang, I'm a bit confused why you can't give different names to the services located in different modules. If each service has a different name then my approach will work for you, doesn't it? But if my service is by ModuleA.ExampleServiceImpl call ModuleB.ExampleServiceImpl,

Re: Ignite-1.5 Release

Hi Vladislav, Please see below.. On 11/11/2015 12:33 PM, Vladisav Jelisavcic wrote: Yakov, sorry for running a bit late. Vladislav, do you have any updates for https://issues.apache.org/jira/browse/IGNITE-638? Or any questions? --Yakov I have problems with some fail-over scenarios; It see

Re: Fifo eviction for atomic cache

I'm wrong Correct ticket is https://issues.apache.org/jira/browse/IGNITE-1889 On Wed, Nov 11, 2015 at 3:25 PM, Sergey Kozlov wrote: > Thanks Andrey for notes! > > I've file the ticket https://issues.apache.org/jira/browse/IGNITE-1888 > > > On Wed, Nov 11, 2015 at 3:16 PM, Andrey Gura wrote: >

[jira] [Created] (IGNITE-1889) FIFO eviction for atomic cache after removeAll

Sergey Kozlov created IGNITE-1889: - Summary: FIFO eviction for atomic cache after removeAll Key: IGNITE-1889 URL: https://issues.apache.org/jira/browse/IGNITE-1889 Project: Ignite Issue Type:

Re: Fifo eviction for atomic cache

Thanks Andrey for notes! I've file the ticket https://issues.apache.org/jira/browse/IGNITE-1888 On Wed, Nov 11, 2015 at 3:16 PM, Andrey Gura wrote: > Not quite. Actual the following operations sequence lead to this behavior: > > 1. put entries > 2. remove all entries > 3. put entries > > On We

Re: Fifo eviction for atomic cache

Not quite. Actual the following operations sequence lead to this behavior: 1. put entries 2. remove all entries 3. put entries On Wed, Nov 11, 2015 at 2:59 PM, Sergey Kozlov wrote: > It seems this behavior caused removeAll on empty cache executed before > puts. > > On Wed, Nov 11, 2015 at 1:16

Re: IGFS URI authority: simplify handling of IGFS and Grid names.

+1 User should have minimal chance to do a mistake in common scenarios. On Wed, Nov 11, 2015 at 1:47 PM, Ivan V. wrote: > Hi, dev, > currently IGFS URI has form > igfs://[igfs-name[:grid-name]]@[host[:port]]/[path] . > This connection can be established with "in-process" routine (used mostly >

Re: Fifo eviction for atomic cache

It seems this behavior caused removeAll on empty cache executed before puts. On Wed, Nov 11, 2015 at 1:16 PM, Sergey Kozlov wrote: > Hi > > I've tested some cache configurations with eviction policy and found a bit > strange behavior. > > For instance the cache configuration is following and I w

Re: OSGi Manifest headers and feature repository pushed (IGNITE-1527)

Hey Dmitriy, On Wed, Nov 11, 2015 at 1:52 AM, Dmitriy Setrakyan wrote: > Can you please describe again the philosophy between choosing a fragment or > a bundle for Ignite dependencies. I couldn’t fully grasp it from your > explanation. > Yes, sorry, I was somewhat brief (it was late here ;-)).

IGNITE-1681: loadAll threshold is not configurable for CacheStoreBalancingWrapper (MERGED)

Michael, Thanks a lot for the contribution! I've reviewed and merged your changes into the release branch. Please refer to minor comments from me left in the latest post: https://issues.apache.org/jira/browse/IGNITE-1681 Look forward to new contributions from you! Denis

Re: 127.0.0.1 in VmIpFinder

The issue wasn't reproduced on my Mac running under El Captain. On 11/10/2015 3:30 PM, Denis Magda wrote: Val, I've tried to run the nodes using the configuration discussed below on OS X Yosemity. Works perfectly fine, both nodes joined the topology and see each other. Will try to check on O

IGFS URI authority: simplify handling of IGFS and Grid names.

Hi, dev, currently IGFS URI has form igfs://[igfs-name[:grid-name]]@[host[:port]]/[path] . This connection can be established with "in-process" routine (used mostly in tests), or with SHMEM, or with TCP protocol. Current logic of "igfs-name" and "grid-name" handling is as follows. In case of in-pro

Re: Ignite interpreter for Zeppelin

Cos, Zeppelin daemon automtically creates interpreter.json file during start (see conf directory). Ignite related content looks like this: "2B44YVSN1": { "id": "2B44YVSN1", "name": "ignite", "group": "ignite", "properties": { "ignite.peerClassLoadingEnabled": "

Fifo eviction for atomic cache

Hi I've tested some cache configurations with eviction policy and found a bit strange behavior. For instance the cache configuration is following and I want to have only 50 recent entries in cache (swap is disabled): 1. I

Re: Ignite-1.5 Release

Vladislav, how can I take a look at the code and run your tests? --Yakov 2015-11-11 12:33 GMT+03:00 Vladisav Jelisavcic : > Yakov, > > sorry for running a bit late. > > > Vladislav, do you have any updates for > > https://issues.apache.org/jira/browse/IGNITE-638? Or any questions? > > > > --Yak

Re: Ignite-1.5 Release

Yakov, sorry for running a bit late. > Vladislav, do you have any updates for > https://issues.apache.org/jira/browse/IGNITE-638? Or any questions? > > --Yakov I have problems with some fail-over scenarios; It seems that if the two nodes are in the middle of acquiring or releasing the semaphore

Work on IGNITE-708 can be continued.

Gianfranco, Need to remove background partition exchange is a very important ticked and it's not blocked by any other tickets at this moment. I will be nice to include this improvement to next release. Let me know in case you heed help or pull req