[jira] [Created] (IGNITE-1844) Automatically create IgfsGroupDataBlocksKeyMapper for IGFS configuration

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-1844:
--

 Summary: Automatically create IgfsGroupDataBlocksKeyMapper for 
IGFS configuration
 Key: IGNITE-1844
 URL: https://issues.apache.org/jira/browse/IGNITE-1844
 Project: Ignite
  Issue Type: Wish
  Components: general
Reporter: Pavel Konstantinov
Priority: Minor


Currently user MUST set IgfsGroupDataBlocksKeyMapper in IGFS configuration.

I'm suggest to create default IgfsGroupDataBlocksKeyMapper and make it not 
mandatory for user.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-1846) CPP: Adopt portable API changes.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-1846:
---

 Summary: CPP: Adopt portable API changes.
 Key: IGNITE-1846
 URL: https://issues.apache.org/jira/browse/IGNITE-1846
 Project: Ignite
  Issue Type: Task
  Components: general, interop
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
Priority: Blocker
 Fix For: 1.5


Important API changes will be introduced as a part of IGNITE-950. 
Once these changes are in place, we need to port them to CPP.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-1845) .Net: Adopt poratble API changes.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-1845:
---

 Summary: .Net: Adopt poratble API changes.
 Key: IGNITE-1845
 URL: https://issues.apache.org/jira/browse/IGNITE-1845
 Project: Ignite
  Issue Type: Task
  Components: general, interop
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
Priority: Blocker
 Fix For: 1.5


Important API changes will be introduced as a part of IGNITE-950. 
Once these changes are in place, we need to port them to .Net.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-1847) Portables: add "field" method to PortableMetadata.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-1847:
---

 Summary: Portables: add "field" method to PortableMetadata.
 Key: IGNITE-1847
 URL: https://issues.apache.org/jira/browse/IGNITE-1847
 Project: Ignite
  Issue Type: Task
  Components: general, interop
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
Priority: Critical
 Fix For: 1.5


1) Add "PortableField field()" method to PortableMetadata. Currently it is 
located on "PortableObject", which is wrong.
2) PortableObject "field" and "hasField" methods must go through cached 
PortableFields.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: log4j2 garbage files

[Raul Kripalani]

Hey guys,

Sorry I missed Artem's request for a review. Glad you got the chance, Denis.

Regards,

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

On Tue, Nov 3, 2015 at 10:03 AM, Denis Magda  wrote:

> Guys, I've merged the fix into the master.
>
> Thanks,
> Denis
>
>
> On 10/30/2015 3:43 PM, Gianfranco Murador wrote:
>
>> Hi Artem, I have no write permission to merge the fix
>> On Oct 30, 2015 11:43 AM, "Artem Shutak"  wrote:
>>
>> Hi Raul,
>>>
>>> Oh, I was sure I deleted these files.
>>>
>>> Fixed in my PR: https://github.com/apache/ignite/pull/188. Raul,
>>> Gianfranco, please, review and merge the fix.
>>>
>>> Thanks,
>>> -- Artem --
>>>
>>> On Thu, Oct 29, 2015 at 9:46 PM, Raul Kripalani 
>>> wrote:
>>>
>>> Gianfranco, Artem,

 Could you please check why we have garbage source files ending in a

>>> twiddle
>>>
 ~ inside the log4j2 module?




>>> https://github.com/apache/ignite/tree/master/modules/log4j2/src/main/java/org/apache/ignite/logger/log4j2
>>>
 Thanks,

 *Raúl Kripalani*
 PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data
 and
 Messaging Engineer
 http://about.me/raulkripalani |
 http://www.linkedin.com/in/raulkripalani
 http://blog.raulkr.net | twitter: @raulvk


>

[jira] [Created] (IGNITE-1849) cache.size() method causes three TASK_* events

[Sergey Kozlov (JIRA)]

Sergey Kozlov created IGNITE-1849:
-

 Summary: cache.size() method causes three TASK_* events
 Key: IGNITE-1849
 URL: https://issues.apache.org/jira/browse/IGNITE-1849
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: ignite-1.4
Reporter: Sergey Kozlov
Assignee: Yakov Zhdanov
 Fix For: 1.5


cache.size() causes following events:
TASK_STARTED
TASK_REDUCED
TASK_FINISHED
But the method should be within CACHE_* event group and one requires a new type 
event like CACHE_ATTR_READ. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Questions about TeamCity CI organization

[Artem Shutak]

Hi Raul,

1. Yes, this is correct separation. If you are working on some new feature
usually in development process you want to run only your build, may be 2,
but not all tests. And only when a feature is close to complete you want to
run all tests.

2. There are at least 2 goals:
- Don't run all tests in process of development - see point 1
- the test execution can be distributed across many nodes

3. I don't see any issue here. At first, we use a standard maven test
procedure. At second, a test execution for some tasks (cache for example)
takes 30-60 minutes, maven build takes 2 minutes (from 30-60 min).
And yes, there're lots of problems which will need to solve to escape a
rebuilding a project each time but it will not give any speed up.

4. Spark, Kafka, Mesos - new modules. Tests for the modules were not added
by mistake. I think a person who commit new module should add a
corresponding test plan to TC.
I don't see tests into 'rest-http' module. As I understand this
functionality covered by tests in another modules.

Do you have some proposals about CI organization? I think there is no needs
to change something.

Thanks,
-- Artem --

On Tue, Nov 3, 2015 at 12:27 AM, Dmitriy Setrakyan 
wrote:

> I am also curious to get answers to the questions posted by Raul. Can
> someone knowledgeable in TC configuration respond?
>
> D.
>
> On Mon, Oct 26, 2015 at 6:14 AM, Raul Kripalani  wrote:
>
> > Hey guys,
> >
> > I have a few questions about the way our builds are organised in
> TeamCity.
> >
> > 1. All build configurations seem to be building the entire project tree.
> Is
> > this correct?
> >
> > 2. The goal of the build configurations here is to partition the tests so
> > that the test execution can be distributed across all 15 worker nodes,
> > right?
> >
> > 3. Would it make sense to have a single top-level build for the project
> > tree that actually builds the code? This one would in turn trigger the
> > individual test suites – each in a build configuration such that then can
> > continue to be distributed across the worker cloud? Or do we face a
> problem
> > with Maven SNAPSHOTs potentially overwriting each other if multiple
> builds
> > are running concurrently? To me, it seems overkill to build the entire
> > project tree over and over again only to execute a given test suite (if I
> > understood correctly).
> >
> > 4. Are tests for ignite-spark, ignite-kafka, ignite-mesos,
> > ignite-rest-http, etc. ever run? I don't find specific build
> configurations
> > for them... Are they included in other configs?
> >
> > Thanks,
> >
> > *Raúl Kripalani*
> > PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> > Messaging Engineer
> > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> > http://blog.raulkr.net | twitter: @raulvk
> >
>

Re: log4j2 garbage files

[Denis Magda]

Guys, I've merged the fix into the master.

Thanks,
Denis

On 10/30/2015 3:43 PM, Gianfranco Murador wrote:

Hi Artem, I have no write permission to merge the fix
On Oct 30, 2015 11:43 AM, "Artem Shutak"  wrote:


Hi Raul,

Oh, I was sure I deleted these files.

Fixed in my PR: https://github.com/apache/ignite/pull/188. Raul,
Gianfranco, please, review and merge the fix.

Thanks,
-- Artem --

On Thu, Oct 29, 2015 at 9:46 PM, Raul Kripalani  wrote:


Gianfranco, Artem,

Could you please check why we have garbage source files ending in a

twiddle

~ inside the log4j2 module?




https://github.com/apache/ignite/tree/master/modules/log4j2/src/main/java/org/apache/ignite/logger/log4j2

Thanks,

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

Re: OSGi migration may require a special marshaller

[Romain Gilles]

Hi Raul,
 - Do you plan to use the TCCL when marshalling in OSGi env? If yes how?
 - I like the point 2. Maybe for a graph of object that come from different
packages / bundles you may have to recursively capture the package version
of the individual element of your graph.
 - For the point 3 I wonder if it will not over-complexify the solution. As
a developer you will have to think about it. And it is not obvious in the
code where things are serialized or not. You may use lambda in your
application code therefore the current package become what you call a DTO
package. The current state of ignite does not enforce you to specify it for
"classical" classloading application. If you introduce this extra step for
OSGi ready application you will maybe discourage people to use OSGi.

To comeback to our solution. We start we a strong assumption: our cluster
is homogeneous in term of code so, of course, it simplify our life :).

BTW if you can introduce an extension point in the class resolution
mechanism it can be interesting for end user in order to allow them to
optimize it based on there specific use cases.

Romain.

Le mar. 3 nov. 2015 à 00:21, Raul Kripalani  a écrit :

> Hi Andrey,
>
> Thanks for the participation in this topic.
>
> I don't like the solution to incorporate the bundle symbolic name in the
> serialised form. Nothing guarantees that the classdef will be located under
> the same bundle in both source and target machines. We also have to take
> into account that OSGi allows for multiple versions of the same
> bundle/packages to co-exist in the same  container. So it becomes more
> complex.
>
> Using the TCCL should work when serialising, but it'll probably be of no
> use when deserialising on the other end.
>
> I need to enhance Ignite to:
>
> 1. Use the TCCL when marshalling on one end.
> 2. Incorporate the package version of the class in the serialised form if
> Ignite is running in an OSGi environment.
> 3. On the receiver end, discover cache entities / DTOs in all bundles
> through a custom OSGi manifest header or the like, as I explained before.
> Package version must be taken into account.
>
> What do you think?
>
> Raúl.
> On 2 Nov 2015 17:25, "Andrey Kornev"  wrote:
>
> > Raul,
> >
> > The fundamental hurdle we need to jump over to make Ignite OSGi-enabled
> is
> > the marshalling. More specifically the issue is with deserialization of
> the
> > classes that are provided by the bundles other than the Ignite bundle
> > itself.
> >
> > When the Ignite transport layer receives a message it needs to figure out
> > how to deserialize the bytes and for that it needs to know the bundle
> that
> > provides the class to be deserailized. At this point TCCL is of no use.
> To
> > make things more complex, the class may contain other classes that come
> > from other bundles, and so on recursively. This means that each object in
> > the hierarchy must be serialized with its bundle name (or bundle id), so
> > that the deserializer will then be able to correctly resolve the class
> > while traversing the object hierarchy during deserialization.
> >
> > Unfortunately, Ignite's OptimizedMarshaller is lacking the ability to
> plug
> > in a custom class resolver. Romain's solution was to use Kryo that does
> > provide a way to customize class resolution. It has solved the problem of
> > capturing the bundle info and he was able to successfully run Ignite as a
> > bundle in an OSGi container (after some repackaging and inclusion of the
> > manifest). But Kryo-based marshalling introduced a lot of complexity to
> the
> > code and incorrect use of Kryo's numerous serializers caused some weird
> > hard-to-debug issues in the Ignite core (like duplicate cache entries due
> > to incorrect marshalling of the GridDhtPArtitonFullMap class -- go
> > figure!). Overall the Kryo-based solution is brittle and hard to
> maintain.
> >
> > I feel the correct solution to OSGi problem would be to
> > 1) enhance the OptimizedMarshaller to allow custom class resolution.
> > 2) provide an OSGi-enabled OptimizedMarshaller (in addition to the
> > original one) to be used in OSGi environment.
> >
> > Regards
> > Andrey
> >
> > > From: ra...@apache.org
> > > Date: Mon, 2 Nov 2015 12:41:47 +
> > > Subject: Re: OSGi migration may require a special marshaller
> > > To: dev@ignite.apache.org
> > >
> > > Hi Romain,
> > >
> > > I'm working on the OSGi compatibility of Ignite. I appreciate your
> input.
> > >
> > > I'm thinking about the situation you describe and I wonder if you're
> > > exporting Ignite as an OSGi service which is then consumed from other
> > > bundles. Under this situation, it would be quite easy to reproduce the
> > > behaviour you describe if Ignite is not resolving classes via the TCCL.
> > > Need to dig deeper into that.
> > >
> > > Off the top of my head, there are two alternatives to solve it:
> > >
> > > 1. Use the TCCL for marshalling/unmarshalling (if not already 

about apache ignite's document localization(Simplified Chinese)

[李玉珏]

Hi：

I am a software architecter from China, is very interested in Ignite, 
Ignite design is very good, very powerful, is a very potential 
technology, I hope to promote the promotion of Ignite in China through 
the translation of Ignite's documentation, so that Ignite can be used as 
soon as possible by more people in china.
I have launched a translation project on the oschina.net, for the 
management of the Chinese version of the documentation, address is: 
http://git.oschina.net/liyuj/ignite-doc-cn, has been a part of the 
translation of the BasicConcepts, I will try to speed up the 
translation, the end of this year will be 1.4.0 version of the manual 
translation is completed.
I hope that the official of Ignite can be placed on the official website 
of the Chinese manual, which is more convenient for more people to see him!


Thanks!

Re: Ignite-1.5 Release

[Nikolay Tikhonov]

I implemented changes related to IGNITE-426 task. Currently investigating
performance degradation for atomic caches. I expect the ticket to be merged
in 2 days.

On Tue, Nov 3, 2015 at 6:47 PM, Alexey Goncharuk  wrote:

> IGNITE-950 is taking more time to be merged than I originally estimated. We
> had a couple of silly bugs, such as loosing cache operation context on
> async cache operations, which led to hard-to debug failures in the platform
> integration code.
> I also added some sanity checks to indexing and found that I ran benchmarks
> for new binary format on a model with externalizable classes, so the result
> I've got were invalid, need more time to fix the model and re-run
> benchmarks.
>
> I am currently waiting for another CI run, will give an update in several
> hours.
>
> 2015-11-03 17:51 GMT+03:00 Vladimir Ozerov :
>
> > Here are my current status for all interop-related stuff (you can view
> > these tickets using query "project = IGNITE AND status in (Open, "In
> > Progress", Reopened, Resolved, "Patch Available") AND component = interop
> > AND fixVersion = 1.5"):
> >
> > *IGNITE-1819 - Remove metadataEnabled flag in Java*
> > Trivial. Waiting for IGNITE-950 merge.
> >
> > *IGNITE-1845, IGNITE-1846 - portable API renamings in CPP and .Net*
> > Trivial. Waiting for IGNITE-950 merge.
> >
> > *IGNITE-1803 - Optimized field lookup for queries*
> > Ready. Waiting for IGNITE-950 to merge.
> >
> > *IGNITE-1847 - Add "field" method to portable metadata.*
> > Not started yet. Waiting for IGNITE-950 to merge.
> >
> > *IGNITE-1816 - Optionally do not write field IDs to portable object
> > footer.*
> > Not started yet.
> >
> > + Several minor tickets.
> >
> > All in all, I expect all these tickets to be ready in 2 days.
> >
> >
> >
> > On Tue, Nov 3, 2015 at 1:43 AM, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > > wrote:
> >
> > > I'm sorry, I meant to write "changes related to IGNITE-1486 *ticket*".
> > The
> > > changes are in ignite-950-new branch because it is a result of work on
> > > multiple sub-tickets and it is currently used as an integration branch.
> > >
> > > 2015-11-03 1:39 GMT+03:00 Dmitriy Setrakyan :
> > >
> > > > Alexey,
> > > >
> > > > I am confused. Why do you have 2 branches?
> > > >
> > > > D.
> > > >
> > > > On Mon, Nov 2, 2015 at 2:32 PM, Alexey Goncharuk <
> > > > alexey.goncha...@gmail.com
> > > > > wrote:
> > > >
> > > > > I am finalizing changes related to IGNITE-1486 branch. Currently
> the
> > > API
> > > > > changes are finished and now I am mostly fixing the CI tests. In
> > fact,
> > > I
> > > > > just submitted the latest fix related to the new .NET platform
> > > > > functionality and hope CI tests will pass, in this case it will be
> > > ready
> > > > to
> > > > > be merged tomorrow morning.
> > > > > It would be nice if other community members reviewed my changes in
> > > > > ignite-950-new branch before it gets to master.
> > > > >
> > > > > 2015-11-02 22:27 GMT+03:00 Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >:
> > > > >
> > > > > > Thanks Vladislav!
> > > > > >
> > > > > > Would also be nice to get an update from other committers
> involved
> > in
> > > > the
> > > > > > outlined tickets. Specifically whether the ticket has been merged
> > to
> > > > > master
> > > > > > or not, and if not, what should be the expectation.
> > > > > >
> > > > > > Thanks,
> > > > > > D.
> > > > > >
> > > > > > On Mon, Nov 2, 2015 at 11:23 AM, Vladisav Jelisavcic <
> > > > > vladis...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > >10. I would also like to include distributed Semaphore.
> > Vladislav,
> > > > any
> > > > > > > >chance you can finish with it this week?
> > > > > > > >https://issues.apache.org/jira/browse/IGNITE-
> > > > > > > >638
> > > > > > >
> > > > > > > I will have it done by thursday.
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Vladisav
> > > > > > >
> > > > > > > On Mon, Nov 2, 2015 at 6:40 PM, Dmitriy Setrakyan <
> > > > > dsetrak...@apache.org
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On Mon, Nov 2, 2015 at 6:58 AM, M G 
> > wrote:
> > > > > > > >
> > > > > > > > > Can/will this include
> > > > > > > https://issues.apache.org/jira/browse/IGNITE-1681
> > > > > > > > ?
> > > > > > > > >
> > > > > > > >
> > > > > > > > I don’t see why not. Would be nice if one of the committers
> > could
> > > > > pick
> > > > > > up
> > > > > > > > the review for this patch.
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > On Mon, Nov 2, 2015 at 1:51 PM, Anton Vinogradov <
> > > > > > > > avinogra...@gridgain.com
> > > > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Branch ignite-1.5 created.
> > > > > > > > > >
> > > > > > > > > > On Mon, Nov 2, 2015 at 4:39 PM, Anton Vinogradov <
> > > > > > > > > avinogra...@gridgain.com
> > 

Re: OSGi migration may require a special marshaller

[Raul Kripalani]

Hey guys,

About the TCCL, I need to dig deeper into how serialisation is being done
now. If, at any point, we are resolving a class through the classloader of
a particular class, e.g. Ignition.getClass().getClassLoader(), etc. we are
using the class space of the bundle containing that class. If we are using
a class from Ignite, we obviously wouldn't be able to find a custom DTO
provided by a user.

In Camel we have found this problem several times and we've solved it by
changing the TCCL, or using the TCCL [1] [2] to resolve classes.

As I said, I need to look into this deeper and I'll have some time on
Thursday, so I hope you don't mind waiting a little bit. I have already
"bundle-fied" most of Ignite modules in the corresponding branch [3], so my
next step is to test out the Ignite examples inside an OSGi environment
(Karaf 4).

[1] https://issues.apache.org/jira/browse/CAMEL-5748
[2] https://issues.apache.org/jira/browse/CAMEL-5722
[3] https://github.com/apache/ignite/tree/ignite-1527

Regards,

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

On Tue, Nov 3, 2015 at 10:38 AM, Romain Gilles 
wrote:

> Hi Raul,
>  - Do you plan to use the TCCL when marshalling in OSGi env? If yes how?
>  - I like the point 2. Maybe for a graph of object that come from different
> packages / bundles you may have to recursively capture the package version
> of the individual element of your graph.
>  - For the point 3 I wonder if it will not over-complexify the solution. As
> a developer you will have to think about it. And it is not obvious in the
> code where things are serialized or not. You may use lambda in your
> application code therefore the current package become what you call a DTO
> package. The current state of ignite does not enforce you to specify it for
> "classical" classloading application. If you introduce this extra step for
> OSGi ready application you will maybe discourage people to use OSGi.
>
> To comeback to our solution. We start we a strong assumption: our cluster
> is homogeneous in term of code so, of course, it simplify our life :).
>
> BTW if you can introduce an extension point in the class resolution
> mechanism it can be interesting for end user in order to allow them to
> optimize it based on there specific use cases.
>
> Romain.
>
> Le mar. 3 nov. 2015 à 00:21, Raul Kripalani  a écrit :
>
> > Hi Andrey,
> >
> > Thanks for the participation in this topic.
> >
> > I don't like the solution to incorporate the bundle symbolic name in the
> > serialised form. Nothing guarantees that the classdef will be located
> under
> > the same bundle in both source and target machines. We also have to take
> > into account that OSGi allows for multiple versions of the same
> > bundle/packages to co-exist in the same  container. So it becomes more
> > complex.
> >
> > Using the TCCL should work when serialising, but it'll probably be of no
> > use when deserialising on the other end.
> >
> > I need to enhance Ignite to:
> >
> > 1. Use the TCCL when marshalling on one end.
> > 2. Incorporate the package version of the class in the serialised form if
> > Ignite is running in an OSGi environment.
> > 3. On the receiver end, discover cache entities / DTOs in all bundles
> > through a custom OSGi manifest header or the like, as I explained before.
> > Package version must be taken into account.
> >
> > What do you think?
> >
> > Raúl.
> > On 2 Nov 2015 17:25, "Andrey Kornev"  wrote:
> >
> > > Raul,
> > >
> > > The fundamental hurdle we need to jump over to make Ignite OSGi-enabled
> > is
> > > the marshalling. More specifically the issue is with deserialization of
> > the
> > > classes that are provided by the bundles other than the Ignite bundle
> > > itself.
> > >
> > > When the Ignite transport layer receives a message it needs to figure
> out
> > > how to deserialize the bytes and for that it needs to know the bundle
> > that
> > > provides the class to be deserailized. At this point TCCL is of no use.
> > To
> > > make things more complex, the class may contain other classes that come
> > > from other bundles, and so on recursively. This means that each object
> in
> > > the hierarchy must be serialized with its bundle name (or bundle id),
> so
> > > that the deserializer will then be able to correctly resolve the class
> > > while traversing the object hierarchy during deserialization.
> > >
> > > Unfortunately, Ignite's OptimizedMarshaller is lacking the ability to
> > plug
> > > in a custom class resolver. Romain's solution was to use Kryo that does
> > > provide a way to customize class resolution. It has solved the problem
> of
> > > capturing the bundle info and he was able to successfully run Ignite
> as a
> > > bundle in an OSGi container (after some 

[GitHub] ignite pull request: IGNITE-1850.

[iveselovskiy]

GitHub user iveselovskiy opened a pull request:

https://github.com/apache/ignite/pull/198

IGNITE-1850.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/iveselovskiy/ignite ignite-1850

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/198.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #198


commit a89a6f6f0b718cb8fc8d79cd3c65233d15612c18
Author: iveselovskiy 
Date:   2015-11-03T17:05:43Z

IGNITE-1850.




---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: OSGi migration may require a special marshaller

[Dmitriy Setrakyan]

Romain,

Can you comment on the ClassLoaderResolver suggestion that I proposed
earlier? Will it solve your problem?

D.

On Tue, Nov 3, 2015 at 2:38 AM, Romain Gilles 
wrote:

> Hi Raul,
>  - Do you plan to use the TCCL when marshalling in OSGi env? If yes how?
>  - I like the point 2. Maybe for a graph of object that come from different
> packages / bundles you may have to recursively capture the package version
> of the individual element of your graph.
>  - For the point 3 I wonder if it will not over-complexify the solution. As
> a developer you will have to think about it. And it is not obvious in the
> code where things are serialized or not. You may use lambda in your
> application code therefore the current package become what you call a DTO
> package. The current state of ignite does not enforce you to specify it for
> "classical" classloading application. If you introduce this extra step for
> OSGi ready application you will maybe discourage people to use OSGi.
>
> To comeback to our solution. We start we a strong assumption: our cluster
> is homogeneous in term of code so, of course, it simplify our life :).
>
> BTW if you can introduce an extension point in the class resolution
> mechanism it can be interesting for end user in order to allow them to
> optimize it based on there specific use cases.
>
> Romain.
>
> Le mar. 3 nov. 2015 à 00:21, Raul Kripalani  a écrit :
>
> > Hi Andrey,
> >
> > Thanks for the participation in this topic.
> >
> > I don't like the solution to incorporate the bundle symbolic name in the
> > serialised form. Nothing guarantees that the classdef will be located
> under
> > the same bundle in both source and target machines. We also have to take
> > into account that OSGi allows for multiple versions of the same
> > bundle/packages to co-exist in the same  container. So it becomes more
> > complex.
> >
> > Using the TCCL should work when serialising, but it'll probably be of no
> > use when deserialising on the other end.
> >
> > I need to enhance Ignite to:
> >
> > 1. Use the TCCL when marshalling on one end.
> > 2. Incorporate the package version of the class in the serialised form if
> > Ignite is running in an OSGi environment.
> > 3. On the receiver end, discover cache entities / DTOs in all bundles
> > through a custom OSGi manifest header or the like, as I explained before.
> > Package version must be taken into account.
> >
> > What do you think?
> >
> > Raúl.
> > On 2 Nov 2015 17:25, "Andrey Kornev"  wrote:
> >
> > > Raul,
> > >
> > > The fundamental hurdle we need to jump over to make Ignite OSGi-enabled
> > is
> > > the marshalling. More specifically the issue is with deserialization of
> > the
> > > classes that are provided by the bundles other than the Ignite bundle
> > > itself.
> > >
> > > When the Ignite transport layer receives a message it needs to figure
> out
> > > how to deserialize the bytes and for that it needs to know the bundle
> > that
> > > provides the class to be deserailized. At this point TCCL is of no use.
> > To
> > > make things more complex, the class may contain other classes that come
> > > from other bundles, and so on recursively. This means that each object
> in
> > > the hierarchy must be serialized with its bundle name (or bundle id),
> so
> > > that the deserializer will then be able to correctly resolve the class
> > > while traversing the object hierarchy during deserialization.
> > >
> > > Unfortunately, Ignite's OptimizedMarshaller is lacking the ability to
> > plug
> > > in a custom class resolver. Romain's solution was to use Kryo that does
> > > provide a way to customize class resolution. It has solved the problem
> of
> > > capturing the bundle info and he was able to successfully run Ignite
> as a
> > > bundle in an OSGi container (after some repackaging and inclusion of
> the
> > > manifest). But Kryo-based marshalling introduced a lot of complexity to
> > the
> > > code and incorrect use of Kryo's numerous serializers caused some weird
> > > hard-to-debug issues in the Ignite core (like duplicate cache entries
> due
> > > to incorrect marshalling of the GridDhtPArtitonFullMap class -- go
> > > figure!). Overall the Kryo-based solution is brittle and hard to
> > maintain.
> > >
> > > I feel the correct solution to OSGi problem would be to
> > > 1) enhance the OptimizedMarshaller to allow custom class resolution.
> > > 2) provide an OSGi-enabled OptimizedMarshaller (in addition to the
> > > original one) to be used in OSGi environment.
> > >
> > > Regards
> > > Andrey
> > >
> > > > From: ra...@apache.org
> > > > Date: Mon, 2 Nov 2015 12:41:47 +
> > > > Subject: Re: OSGi migration may require a special marshaller
> > > > To: dev@ignite.apache.org
> > > >
> > > > Hi Romain,
> > > >
> > > > I'm working on the OSGi compatibility of Ignite. I appreciate your
> > input.
> > > >
> > > > I'm thinking about the situation you describe and I wonder if 

Re: Questions about TeamCity CI organization

[Raul Kripalani]

Hi Artem,

Thanks for the clarifications.

At first, it did seem overkill that we're building the code over and over
again in each build configuration – when the ultimate goal is just to run a
subset of tests.

But you are right in that the build itself takes very little time
comparatively to the tests. Separating the build on one side (single build
config) and tests on the other (1 build config per test group) can be
difficult and risky because it's hard to guarantee that tests distributed
for execution across a cluster will run against exactly the same SNAPSHOT
built by the top-level job.

Logically it would be more efficient, but practically it would be to
over-optimise in the current context.

BTW – We need to add TC management to the Ignite Wiki. In particular, the
committer merging a new module (or Test Suite) should ensure that it's
covered by a TC job.

Thanks,

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

On Tue, Nov 3, 2015 at 12:05 PM, Artem Shutak  wrote:

> Hi Raul,
>
> 1. Yes, this is correct separation. If you are working on some new feature
> usually in development process you want to run only your build, may be 2,
> but not all tests. And only when a feature is close to complete you want to
> run all tests.
>
> 2. There are at least 2 goals:
> - Don't run all tests in process of development - see point 1
> - the test execution can be distributed across many nodes
>
> 3. I don't see any issue here. At first, we use a standard maven test
> procedure. At second, a test execution for some tasks (cache for example)
> takes 30-60 minutes, maven build takes 2 minutes (from 30-60 min).
> And yes, there're lots of problems which will need to solve to escape a
> rebuilding a project each time but it will not give any speed up.
>
> 4. Spark, Kafka, Mesos - new modules. Tests for the modules were not added
> by mistake. I think a person who commit new module should add a
> corresponding test plan to TC.
> I don't see tests into 'rest-http' module. As I understand this
> functionality covered by tests in another modules.
>
> Do you have some proposals about CI organization? I think there is no needs
> to change something.
>
> Thanks,
> -- Artem --
>
> On Tue, Nov 3, 2015 at 12:27 AM, Dmitriy Setrakyan 
> wrote:
>
> > I am also curious to get answers to the questions posted by Raul. Can
> > someone knowledgeable in TC configuration respond?
> >
> > D.
> >
> > On Mon, Oct 26, 2015 at 6:14 AM, Raul Kripalani 
> wrote:
> >
> > > Hey guys,
> > >
> > > I have a few questions about the way our builds are organised in
> > TeamCity.
> > >
> > > 1. All build configurations seem to be building the entire project
> tree.
> > Is
> > > this correct?
> > >
> > > 2. The goal of the build configurations here is to partition the tests
> so
> > > that the test execution can be distributed across all 15 worker nodes,
> > > right?
> > >
> > > 3. Would it make sense to have a single top-level build for the project
> > > tree that actually builds the code? This one would in turn trigger the
> > > individual test suites – each in a build configuration such that then
> can
> > > continue to be distributed across the worker cloud? Or do we face a
> > problem
> > > with Maven SNAPSHOTs potentially overwriting each other if multiple
> > builds
> > > are running concurrently? To me, it seems overkill to build the entire
> > > project tree over and over again only to execute a given test suite
> (if I
> > > understood correctly).
> > >
> > > 4. Are tests for ignite-spark, ignite-kafka, ignite-mesos,
> > > ignite-rest-http, etc. ever run? I don't find specific build
> > configurations
> > > for them... Are they included in other configs?
> > >
> > > Thanks,
> > >
> > > *Raúl Kripalani*
> > > PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data
> and
> > > Messaging Engineer
> > > http://about.me/raulkripalani |
> http://www.linkedin.com/in/raulkripalani
> > > http://blog.raulkr.net | twitter: @raulvk
> > >
> >
>

Hello

[Pradeep Sekar]

-- 
_pradeep

Re: Ignite-1.5 Release

[Alexey Goncharuk]

Good news for the IGNITE-950 ticket - CI looks good, changes will be merged
to ignite-1282 integration branch after benchmarks re-run.

2015-11-03 21:37 GMT+03:00 Nikolay Tikhonov :

> I implemented changes related to IGNITE-426 task. Currently investigating
> performance degradation for atomic caches. I expect the ticket to be merged
> in 2 days.
>
> On Tue, Nov 3, 2015 at 6:47 PM, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> > wrote:
>
> > IGNITE-950 is taking more time to be merged than I originally estimated.
> We
> > had a couple of silly bugs, such as loosing cache operation context on
> > async cache operations, which led to hard-to debug failures in the
> platform
> > integration code.
> > I also added some sanity checks to indexing and found that I ran
> benchmarks
> > for new binary format on a model with externalizable classes, so the
> result
> > I've got were invalid, need more time to fix the model and re-run
> > benchmarks.
> >
> > I am currently waiting for another CI run, will give an update in several
> > hours.
> >
> > 2015-11-03 17:51 GMT+03:00 Vladimir Ozerov :
> >
> > > Here are my current status for all interop-related stuff (you can view
> > > these tickets using query "project = IGNITE AND status in (Open, "In
> > > Progress", Reopened, Resolved, "Patch Available") AND component =
> interop
> > > AND fixVersion = 1.5"):
> > >
> > > *IGNITE-1819 - Remove metadataEnabled flag in Java*
> > > Trivial. Waiting for IGNITE-950 merge.
> > >
> > > *IGNITE-1845, IGNITE-1846 - portable API renamings in CPP and .Net*
> > > Trivial. Waiting for IGNITE-950 merge.
> > >
> > > *IGNITE-1803 - Optimized field lookup for queries*
> > > Ready. Waiting for IGNITE-950 to merge.
> > >
> > > *IGNITE-1847 - Add "field" method to portable metadata.*
> > > Not started yet. Waiting for IGNITE-950 to merge.
> > >
> > > *IGNITE-1816 - Optionally do not write field IDs to portable object
> > > footer.*
> > > Not started yet.
> > >
> > > + Several minor tickets.
> > >
> > > All in all, I expect all these tickets to be ready in 2 days.
> > >
> > >
> > >
> > > On Tue, Nov 3, 2015 at 1:43 AM, Alexey Goncharuk <
> > > alexey.goncha...@gmail.com
> > > > wrote:
> > >
> > > > I'm sorry, I meant to write "changes related to IGNITE-1486
> *ticket*".
> > > The
> > > > changes are in ignite-950-new branch because it is a result of work
> on
> > > > multiple sub-tickets and it is currently used as an integration
> branch.
> > > >
> > > > 2015-11-03 1:39 GMT+03:00 Dmitriy Setrakyan :
> > > >
> > > > > Alexey,
> > > > >
> > > > > I am confused. Why do you have 2 branches?
> > > > >
> > > > > D.
> > > > >
> > > > > On Mon, Nov 2, 2015 at 2:32 PM, Alexey Goncharuk <
> > > > > alexey.goncha...@gmail.com
> > > > > > wrote:
> > > > >
> > > > > > I am finalizing changes related to IGNITE-1486 branch. Currently
> > the
> > > > API
> > > > > > changes are finished and now I am mostly fixing the CI tests. In
> > > fact,
> > > > I
> > > > > > just submitted the latest fix related to the new .NET platform
> > > > > > functionality and hope CI tests will pass, in this case it will
> be
> > > > ready
> > > > > to
> > > > > > be merged tomorrow morning.
> > > > > > It would be nice if other community members reviewed my changes
> in
> > > > > > ignite-950-new branch before it gets to master.
> > > > > >
> > > > > > 2015-11-02 22:27 GMT+03:00 Dmitriy Setrakyan <
> > dsetrak...@apache.org
> > > >:
> > > > > >
> > > > > > > Thanks Vladislav!
> > > > > > >
> > > > > > > Would also be nice to get an update from other committers
> > involved
> > > in
> > > > > the
> > > > > > > outlined tickets. Specifically whether the ticket has been
> merged
> > > to
> > > > > > master
> > > > > > > or not, and if not, what should be the expectation.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > D.
> > > > > > >
> > > > > > > On Mon, Nov 2, 2015 at 11:23 AM, Vladisav Jelisavcic <
> > > > > > vladis...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > >10. I would also like to include distributed Semaphore.
> > > Vladislav,
> > > > > any
> > > > > > > > >chance you can finish with it this week?
> > > > > > > > >https://issues.apache.org/jira/browse/IGNITE-
> > > > > > > > >638
> > > > > > > >
> > > > > > > > I will have it done by thursday.
> > > > > > > >
> > > > > > > > Best regards,
> > > > > > > > Vladisav
> > > > > > > >
> > > > > > > > On Mon, Nov 2, 2015 at 6:40 PM, Dmitriy Setrakyan <
> > > > > > dsetrak...@apache.org
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > On Mon, Nov 2, 2015 at 6:58 AM, M G 
> > > wrote:
> > > > > > > > >
> > > > > > > > > > Can/will this include
> > > > > > > > https://issues.apache.org/jira/browse/IGNITE-1681
> > > > > > > > > ?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > I don’t see why not. Would be nice if one of the 

Re: Ignite-1.5 Release

[Alexey Kuznetsov]

I'm working on IGNITE-1753 Rework CacheJdbcPojoStore to new API (
https://issues.apache.org/jira/browse/IGNITE-1753).
Issue is implemented and waiting for  IGNITE-950 to be merged into
ignite-1282.

On Wed, Nov 4, 2015 at 5:22 AM, Alexey Goncharuk  wrote:

> Good news for the IGNITE-950 ticket - CI looks good, changes will be merged
> to ignite-1282 integration branch after benchmarks re-run.
>
> 2015-11-03 21:37 GMT+03:00 Nikolay Tikhonov :
>
> > I implemented changes related to IGNITE-426 task. Currently investigating
> > performance degradation for atomic caches. I expect the ticket to be
> merged
> > in 2 days.
> >
> > On Tue, Nov 3, 2015 at 6:47 PM, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > > wrote:
> >
> > > IGNITE-950 is taking more time to be merged than I originally
> estimated.
> > We
> > > had a couple of silly bugs, such as loosing cache operation context on
> > > async cache operations, which led to hard-to debug failures in the
> > platform
> > > integration code.
> > > I also added some sanity checks to indexing and found that I ran
> > benchmarks
> > > for new binary format on a model with externalizable classes, so the
> > result
> > > I've got were invalid, need more time to fix the model and re-run
> > > benchmarks.
> > >
> > > I am currently waiting for another CI run, will give an update in
> several
> > > hours.
> > >
> > > 2015-11-03 17:51 GMT+03:00 Vladimir Ozerov :
> > >
> > > > Here are my current status for all interop-related stuff (you can
> view
> > > > these tickets using query "project = IGNITE AND status in (Open, "In
> > > > Progress", Reopened, Resolved, "Patch Available") AND component =
> > interop
> > > > AND fixVersion = 1.5"):
> > > >
> > > > *IGNITE-1819 - Remove metadataEnabled flag in Java*
> > > > Trivial. Waiting for IGNITE-950 merge.
> > > >
> > > > *IGNITE-1845, IGNITE-1846 - portable API renamings in CPP and .Net*
> > > > Trivial. Waiting for IGNITE-950 merge.
> > > >
> > > > *IGNITE-1803 - Optimized field lookup for queries*
> > > > Ready. Waiting for IGNITE-950 to merge.
> > > >
> > > > *IGNITE-1847 - Add "field" method to portable metadata.*
> > > > Not started yet. Waiting for IGNITE-950 to merge.
> > > >
> > > > *IGNITE-1816 - Optionally do not write field IDs to portable object
> > > > footer.*
> > > > Not started yet.
> > > >
> > > > + Several minor tickets.
> > > >
> > > > All in all, I expect all these tickets to be ready in 2 days.
> > > >
> > > >
> > > >
> > > > On Tue, Nov 3, 2015 at 1:43 AM, Alexey Goncharuk <
> > > > alexey.goncha...@gmail.com
> > > > > wrote:
> > > >
> > > > > I'm sorry, I meant to write "changes related to IGNITE-1486
> > *ticket*".
> > > > The
> > > > > changes are in ignite-950-new branch because it is a result of work
> > on
> > > > > multiple sub-tickets and it is currently used as an integration
> > branch.
> > > > >
> > > > > 2015-11-03 1:39 GMT+03:00 Dmitriy Setrakyan  >:
> > > > >
> > > > > > Alexey,
> > > > > >
> > > > > > I am confused. Why do you have 2 branches?
> > > > > >
> > > > > > D.
> > > > > >
> > > > > > On Mon, Nov 2, 2015 at 2:32 PM, Alexey Goncharuk <
> > > > > > alexey.goncha...@gmail.com
> > > > > > > wrote:
> > > > > >
> > > > > > > I am finalizing changes related to IGNITE-1486 branch.
> Currently
> > > the
> > > > > API
> > > > > > > changes are finished and now I am mostly fixing the CI tests.
> In
> > > > fact,
> > > > > I
> > > > > > > just submitted the latest fix related to the new .NET platform
> > > > > > > functionality and hope CI tests will pass, in this case it will
> > be
> > > > > ready
> > > > > > to
> > > > > > > be merged tomorrow morning.
> > > > > > > It would be nice if other community members reviewed my changes
> > in
> > > > > > > ignite-950-new branch before it gets to master.
> > > > > > >
> > > > > > > 2015-11-02 22:27 GMT+03:00 Dmitriy Setrakyan <
> > > dsetrak...@apache.org
> > > > >:
> > > > > > >
> > > > > > > > Thanks Vladislav!
> > > > > > > >
> > > > > > > > Would also be nice to get an update from other committers
> > > involved
> > > > in
> > > > > > the
> > > > > > > > outlined tickets. Specifically whether the ticket has been
> > merged
> > > > to
> > > > > > > master
> > > > > > > > or not, and if not, what should be the expectation.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > D.
> > > > > > > >
> > > > > > > > On Mon, Nov 2, 2015 at 11:23 AM, Vladisav Jelisavcic <
> > > > > > > vladis...@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > >10. I would also like to include distributed Semaphore.
> > > > Vladislav,
> > > > > > any
> > > > > > > > > >chance you can finish with it this week?
> > > > > > > > > >https://issues.apache.org/jira/browse/IGNITE-
> > > > > > > > > >638
> > > > > > > > >
> > > > > > > > > I will have it done by thursday.
> > > > > > > > >
> > > > > > > > 

Re: about apache ignite's document localization(Simplified Chinese)

[Dmitriy Setrakyan]

(adding the contributor to the CC)

Hi,

I am sorry, I do not know your name, but it is a great contribution!

Can I ask you to properly subscribe to the dev list? You need to send an
email to “dev-subscr...@ignite.apache.org” and then follow the simply
instructions in the reply. This will make further communication a lot
easier.

Thanks,
D.

On Tue, Nov 3, 2015 at 12:07 PM, Sergi Vladykin 
wrote:

> Hi,
>
> Thats pretty cool! Thanks a lot for your help!
>
> I think we can add this link to Ignite website as unofficial documentation
> translation when it will be ready, but now I can't open the link you've
> provided in my browser.
>
> Sergi
>
>
> 2015-11-03 15:38 GMT+03:00 李玉珏@163 <18624049...@163.com>:
>
> > Hi：
> >
> > I am a software architecter from China, is very interested in Ignite,
> > Ignite design is very good, very powerful, is a very potential
> technology,
> > I hope to promote the promotion of Ignite in China through the
> translation
> > of Ignite's documentation, so that Ignite can be used as soon as possible
> > by more people in china.
> > I have launched a translation project on the oschina.net, for the
> > management of the Chinese version of the documentation, address is:
> > http://git.oschina.net/liyuj/ignite-doc-cn, has been a part of the
> > translation of the BasicConcepts, I will try to speed up the translation,
> > the end of this year will be 1.4.0 version of the manual translation is
> > completed.
> > I hope that the official of Ignite can be placed on the official website
> > of the Chinese manual, which is more convenient for more people to see
> him!
> >
> > Thanks!
> >
> >
>

Re: OSGi migration may require a special marshaller

[Romain Gilles]

Hi Dmitriy,
I think your solution is good. Maybe I will change it a little bit... :P
I think you should delegate the Class resolution to the resolver. Because
for example with your current solution the marshaller may before (or after)
store the fqn of the class (maybe only the first time it encounter it) but
in order to save the classloader context resolution the implementation of
the resolver may have to save the package name of the given object and some
extra info therefore the content package name will be serialized two times.
Ok, it's not a big deal.
But now if the resolver identify that it can reuse the same class loader
for a couple of classes. It will be interesting for it to have a
serialization context in order to save, let say, classloader/id mapping in
order to save the id instead of a more longer representation.
So I propose something like that:
*public interface ClassResolver {*
*// This method is invoked on the sender side to *
*// marshal the information about the class.*
*// where the context is a map style object that is reset/new for each
object graph serialization.*
*public byte[] writeClass(Object o, Context context) throws
IgniteException;*

*// This method is invoked on the receiving side to*
*// retrieve the class based on provided information.*
*// where the context is a map style object that is reset/new for each
object graph serialization.*
*public Class readClass(byte[], Context context) throws
IgniteException;*
*}*

I think your proposal will solve our issue and maybe also open a door for
the osgi development.
Let me know what do you think about me proposal? :)

Thanks,

Romain

Le mar. 3 nov. 2015 à 20:05, Dmitriy Setrakyan  a
écrit :

> Romain,
>
> Can you comment on the ClassLoaderResolver suggestion that I proposed
> earlier? Will it solve your problem?
>
> D.
>
> On Tue, Nov 3, 2015 at 2:38 AM, Romain Gilles 
> wrote:
>
> > Hi Raul,
> >  - Do you plan to use the TCCL when marshalling in OSGi env? If yes how?
> >  - I like the point 2. Maybe for a graph of object that come from
> different
> > packages / bundles you may have to recursively capture the package
> version
> > of the individual element of your graph.
> >  - For the point 3 I wonder if it will not over-complexify the solution.
> As
> > a developer you will have to think about it. And it is not obvious in the
> > code where things are serialized or not. You may use lambda in your
> > application code therefore the current package become what you call a DTO
> > package. The current state of ignite does not enforce you to specify it
> for
> > "classical" classloading application. If you introduce this extra step
> for
> > OSGi ready application you will maybe discourage people to use OSGi.
> >
> > To comeback to our solution. We start we a strong assumption: our cluster
> > is homogeneous in term of code so, of course, it simplify our life :).
> >
> > BTW if you can introduce an extension point in the class resolution
> > mechanism it can be interesting for end user in order to allow them to
> > optimize it based on there specific use cases.
> >
> > Romain.
> >
> > Le mar. 3 nov. 2015 à 00:21, Raul Kripalani  a écrit :
> >
> > > Hi Andrey,
> > >
> > > Thanks for the participation in this topic.
> > >
> > > I don't like the solution to incorporate the bundle symbolic name in
> the
> > > serialised form. Nothing guarantees that the classdef will be located
> > under
> > > the same bundle in both source and target machines. We also have to
> take
> > > into account that OSGi allows for multiple versions of the same
> > > bundle/packages to co-exist in the same  container. So it becomes more
> > > complex.
> > >
> > > Using the TCCL should work when serialising, but it'll probably be of
> no
> > > use when deserialising on the other end.
> > >
> > > I need to enhance Ignite to:
> > >
> > > 1. Use the TCCL when marshalling on one end.
> > > 2. Incorporate the package version of the class in the serialised form
> if
> > > Ignite is running in an OSGi environment.
> > > 3. On the receiver end, discover cache entities / DTOs in all bundles
> > > through a custom OSGi manifest header or the like, as I explained
> before.
> > > Package version must be taken into account.
> > >
> > > What do you think?
> > >
> > > Raúl.
> > > On 2 Nov 2015 17:25, "Andrey Kornev"  wrote:
> > >
> > > > Raul,
> > > >
> > > > The fundamental hurdle we need to jump over to make Ignite
> OSGi-enabled
> > > is
> > > > the marshalling. More specifically the issue is with deserialization
> of
> > > the
> > > > classes that are provided by the bundles other than the Ignite bundle
> > > > itself.
> > > >
> > > > When the Ignite transport layer receives a message it needs to figure
> > out
> > > > how to deserialize the bytes and for that it needs to know the bundle
> > > that
> > > > provides the class to be deserailized. At this 

RE: OSGi migration may require a special marshaller

[Andrey Kornev]

Dmitriy,

I think your approach will work, but I let Romain respond. 

Also, in terms of the implementation, please keep in mind that the resolver 
must be called for each non-JDK and non-Ignite core class (it would probably 
make sense to eschew storing class loaders for such classes in favor of 
compactness of the serialized representation -- see below). Also, it's worth 
keeping a cache of already resolved class loaders per marshaller invocation 
(this is probably the context that Romain has mentioned in his previous 
posting) to minimize the number of the resolver calls.

In terms of the resolver's implementation, the simplest way to serialize the 
class loader would be by capturing two pieces of information (both strings): 
the bundle symbolic name and the bundle version. This approach however may 
result in bloating of the serialized representation: I'd roughly estimate the 
overhead per element to be at least 20-30 bytes (the length of the symbolic 
name string, plus the length of the version string). There are way to reduce 
the overhead (like serializing the hash code of the bundle id string rather 
than the string itself, and then come up with a clever way of resolving the 
hash collisions), but they all come at cost of increased complexity...

An alternative approach would be rely on the special bundle id which is an 
integer and is generated by the OSGi container. But in this case, all nodes 
must ensure that all the bundles have consistent ids (bundle A with id 42 on 
node N1, has the same id on every other node) which is not easy -- while not 
entirely impossible -- to guarantee. As long as the nodes are homogeneous (have 
the same set of bundles deployed) the OSGi container is guaranteed to assign to 
the bundles the same ids.

Thanks
Andrey

> From: dsetrak...@apache.org
> Date: Tue, 3 Nov 2015 16:29:41 -0800
> Subject: Re: OSGi migration may require a special marshaller
> To: dev@ignite.apache.org
> 
> Romain,
> 
> In the upcoming release we will be deprecating the OptimizedMarshaller and
> will be switching to a default internal marshaller (which is based on the
> new PortableMarshaller donated by GridGain).
> 
> Having said that, we may be able to pass BinaryWriter and BinaryReader
> instead of byte arrays. This will be pretty close to passing the stream, as
> suggested by Andrey.
> 
> Also, I still think that we should only resolve class loaders and not the
> class itself. The main reason is that Ignite will encode class names into
> an integer hash code and will store the integer->class-fqn mapping in
> internal replicated cache. I doubt users will get more efficient than an
> integer (4 bytes) for a class name.
> 
> On the receiving side, once we are able to get the right class loader, we
> can easily get the proper class by calling ClassLoader.findClass(class-fqn).
> 
> Thoughts?
> 
> D.
> 
> On Tue, Nov 3, 2015 at 2:01 PM, Romain Gilles 
> wrote:
> 
> > Hi,
> > Maybe a missing point. I think but I'm not sure that in the
> > OptimizedMarshaller there is a caching of already serialized classes. Due
> > to the dynamic nature of OSGi this may lead to memory leak. In fact if a
> > bundle is refreshed, it will produce a new BundleRevision and therefore a
> > new classloader. And if you don't release the class from the previous
> > BundleRevision then you endup with memory leak. So maybe the Marshaller
> > interface or somewhere should provide a way to free those classes /
> > classloaders.
> >
> > Regards,
> >
> > Romain
> >
> > Le mar. 3 nov. 2015 à 22:42, Andrey Kornev  a
> > écrit :
> >
> > > Romain/Dmitriy,
> > >
> > > I prefer Romain's approach, but just curious, in the API you guys are
> > > proposing why use a byte[] rather than OutputStream/InputStream? With a
> > > byte[], one would inevitably end up wrapping it into a byte stream class.
> > > Also, the stream-based interface would be more in line with the
> > Marshaller
> > > API.
> > >
> > > Also for symmetry with the readClass() method, I suggest the writeClass()
> > > take a Class rather than an object.
> > >
> > > Regards
> > > Andrey
> > >
> > > > From: romain.gil...@gmail.com
> > > > Date: Tue, 3 Nov 2015 21:24:01 +
> > > > Subject: Re: OSGi migration may require a special marshaller
> > > > To: dev@ignite.apache.org
> > > >
> > > > Hi Dmitriy,
> > > > I think your solution is good. Maybe I will change it a little bit...
> > :P
> > > > I think you should delegate the Class resolution to the resolver.
> > Because
> > > > for example with your current solution the marshaller may before (or
> > > after)
> > > > store the fqn of the class (maybe only the first time it encounter it)
> > > but
> > > > in order to save the classloader context resolution the implementation
> > of
> > > > the resolver may have to save the package name of the given object and
> > > some
> > > > extra info therefore the content package name will be serialized two
> > > times.
> > > > Ok, it's 

Re: Hello

[Dmitriy Setrakyan]

Hi Pradeep,

Welcome to the Ignite community!

Please properly subscribe to the dev list (this way I will not have to
manually approve your emails). All you need to do is send an email to “
dev-subscr...@ignite.apache.org” and follow simple instructions in the
reply.

You should get familiar with Ignite development process described here:
https://cwiki.apache.org/confluence/display/IGNITE/Development+Process

Instructions on how to contribute can be found here:
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute

Once you got familiar and were able to run a few examples, you should pick
a Jira ticket you would like to start on. Send an email to the dev list, so
we can add you as a contributor in Jira.

You can find interesting tickets to get started here:
https://ignite.apache.org/community/contribute.html#pick-ticket

Looking forward to your contributions!

D.




On Tue, Nov 3, 2015 at 1:11 PM, Pradeep Sekar  wrote:

> --
> _pradeep
>

Ignite web console UI usability

[Pavel Konstantinov]

Hi, Igniters,

I'm playing with Ignite Web Console (console.gridgain.com) and would like
to ask your opinion about name of 'Reset' button on Caches screen.

By fact this button doing 'undo all changes'. But it's current name - Reset
- a bit confusing me. When I see 'Reset' I'm thinking about 'reset to
default values' or something similar. So I suggest to rename this button to
'Undo All' which will more consistent with the real action.

Anyone else agree with me?

Re: Ignite web console UI usability

[Roman]

To me, "Revert", "Cancel", "Undo" -- any of these is better than "Reset".
-Roman
 


 On Wednesday, November 4, 2015 1:29 PM, Pavel Konstantinov 
 wrote:
   

 Hi, Igniters,

I'm playing with Ignite Web Console (console.gridgain.com) and would like
to ask your opinion about name of 'Reset' button on Caches screen.

By fact this button doing 'undo all changes'. But it's current name - Reset
- a bit confusing me. When I see 'Reset' I'm thinking about 'reset to
default values' or something similar. So I suggest to rename this button to
'Undo All' which will more consistent with the real action.

Anyone else agree with me?


   

[jira] [Created] (IGNITE-1852) Need to align RDBMS dropdown and it's tooltip

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-1852:
--

 Summary: Need to align RDBMS dropdown and it's tooltip
 Key: IGNITE-1852
 URL: https://issues.apache.org/jira/browse/IGNITE-1852
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov
Priority: Minor


1) Add 'Generic JDBC' to dropdown
2) Add 'Postgre SQL' to tooltip



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: OSGi migration may require a special marshaller

[Dmitriy Setrakyan]

Andrey, et al,

Can you provide a way on how to get a required Bundle object based on, say,
bundle symbolic name and version?

I have reached the end of the internet trying to find a way in OSGI to look
up a Bundle based on something other than an actual Class belonging to that
bundle, but no luck.

D.

On Tue, Nov 3, 2015 at 5:15 PM, Andrey Kornev 
wrote:

> Dmitriy,
>
> I think your approach will work, but I let Romain respond.
>
> Also, in terms of the implementation, please keep in mind that the
> resolver must be called for each non-JDK and non-Ignite core class (it
> would probably make sense to eschew storing class loaders for such classes
> in favor of compactness of the serialized representation -- see below).
> Also, it's worth keeping a cache of already resolved class loaders per
> marshaller invocation (this is probably the context that Romain has
> mentioned in his previous posting) to minimize the number of the resolver
> calls.
>
> In terms of the resolver's implementation, the simplest way to serialize
> the class loader would be by capturing two pieces of information (both
> strings): the bundle symbolic name and the bundle version. This approach
> however may result in bloating of the serialized representation: I'd
> roughly estimate the overhead per element to be at least 20-30 bytes (the
> length of the symbolic name string, plus the length of the version string).
> There are way to reduce the overhead (like serializing the hash code of the
> bundle id string rather than the string itself, and then come up with a
> clever way of resolving the hash collisions), but they all come at cost of
> increased complexity...
>
> An alternative approach would be rely on the special bundle id which is an
> integer and is generated by the OSGi container. But in this case, all nodes
> must ensure that all the bundles have consistent ids (bundle A with id 42
> on node N1, has the same id on every other node) which is not easy -- while
> not entirely impossible -- to guarantee. As long as the nodes are
> homogeneous (have the same set of bundles deployed) the OSGi container is
> guaranteed to assign to the bundles the same ids.
>
> Thanks
> Andrey
>
> > From: dsetrak...@apache.org
> > Date: Tue, 3 Nov 2015 16:29:41 -0800
> > Subject: Re: OSGi migration may require a special marshaller
> > To: dev@ignite.apache.org
> >
> > Romain,
> >
> > In the upcoming release we will be deprecating the OptimizedMarshaller
> and
> > will be switching to a default internal marshaller (which is based on the
> > new PortableMarshaller donated by GridGain).
> >
> > Having said that, we may be able to pass BinaryWriter and BinaryReader
> > instead of byte arrays. This will be pretty close to passing the stream,
> as
> > suggested by Andrey.
> >
> > Also, I still think that we should only resolve class loaders and not the
> > class itself. The main reason is that Ignite will encode class names into
> > an integer hash code and will store the integer->class-fqn mapping in
> > internal replicated cache. I doubt users will get more efficient than an
> > integer (4 bytes) for a class name.
> >
> > On the receiving side, once we are able to get the right class loader, we
> > can easily get the proper class by calling
> ClassLoader.findClass(class-fqn).
> >
> > Thoughts?
> >
> > D.
> >
> > On Tue, Nov 3, 2015 at 2:01 PM, Romain Gilles 
> > wrote:
> >
> > > Hi,
> > > Maybe a missing point. I think but I'm not sure that in the
> > > OptimizedMarshaller there is a caching of already serialized classes.
> Due
> > > to the dynamic nature of OSGi this may lead to memory leak. In fact if
> a
> > > bundle is refreshed, it will produce a new BundleRevision and
> therefore a
> > > new classloader. And if you don't release the class from the previous
> > > BundleRevision then you endup with memory leak. So maybe the Marshaller
> > > interface or somewhere should provide a way to free those classes /
> > > classloaders.
> > >
> > > Regards,
> > >
> > > Romain
> > >
> > > Le mar. 3 nov. 2015 à 22:42, Andrey Kornev 
> a
> > > écrit :
> > >
> > > > Romain/Dmitriy,
> > > >
> > > > I prefer Romain's approach, but just curious, in the API you guys are
> > > > proposing why use a byte[] rather than OutputStream/InputStream?
> With a
> > > > byte[], one would inevitably end up wrapping it into a byte stream
> class.
> > > > Also, the stream-based interface would be more in line with the
> > > Marshaller
> > > > API.
> > > >
> > > > Also for symmetry with the readClass() method, I suggest the
> writeClass()
> > > > take a Class rather than an object.
> > > >
> > > > Regards
> > > > Andrey
> > > >
> > > > > From: romain.gil...@gmail.com
> > > > > Date: Tue, 3 Nov 2015 21:24:01 +
> > > > > Subject: Re: OSGi migration may require a special marshaller
> > > > > To: dev@ignite.apache.org
> > > > >
> > > > > Hi Dmitriy,
> > > > > I think your solution is good. Maybe I will 

RE: OSGi migration may require a special marshaller

[Andrey Kornev]

Romain/Dmitriy,

I prefer Romain's approach, but just curious, in the API you guys are proposing 
why use a byte[] rather than OutputStream/InputStream? With a byte[], one would 
inevitably end up wrapping it into a byte stream class. Also, the stream-based 
interface would be more in line with the Marshaller API.

Also for symmetry with the readClass() method, I suggest the writeClass() take 
a Class rather than an object.

Regards
Andrey

> From: romain.gil...@gmail.com
> Date: Tue, 3 Nov 2015 21:24:01 +
> Subject: Re: OSGi migration may require a special marshaller
> To: dev@ignite.apache.org
> 
> Hi Dmitriy,
> I think your solution is good. Maybe I will change it a little bit... :P
> I think you should delegate the Class resolution to the resolver. Because
> for example with your current solution the marshaller may before (or after)
> store the fqn of the class (maybe only the first time it encounter it) but
> in order to save the classloader context resolution the implementation of
> the resolver may have to save the package name of the given object and some
> extra info therefore the content package name will be serialized two times.
> Ok, it's not a big deal.
> But now if the resolver identify that it can reuse the same class loader
> for a couple of classes. It will be interesting for it to have a
> serialization context in order to save, let say, classloader/id mapping in
> order to save the id instead of a more longer representation.
> So I propose something like that:
> *public interface ClassResolver {*
> *// This method is invoked on the sender side to *
> *// marshal the information about the class.*
> *// where the context is a map style object that is reset/new for each
> object graph serialization.*
> *public byte[] writeClass(Object o, Context context) throws
> IgniteException;*
> 
> *// This method is invoked on the receiving side to*
> *// retrieve the class based on provided information.*
> *// where the context is a map style object that is reset/new for each
> object graph serialization.*
> *public Class readClass(byte[], Context context) throws
> IgniteException;*
> *}*
> 
> I think your proposal will solve our issue and maybe also open a door for
> the osgi development.
> Let me know what do you think about me proposal? :)
> 
> Thanks,
> 
> Romain
> 
> Le mar. 3 nov. 2015 à 20:05, Dmitriy Setrakyan  a
> écrit :
> 
> > Romain,
> >
> > Can you comment on the ClassLoaderResolver suggestion that I proposed
> > earlier? Will it solve your problem?
> >
> > D.
> >
> > On Tue, Nov 3, 2015 at 2:38 AM, Romain Gilles 
> > wrote:
> >
> > > Hi Raul,
> > >  - Do you plan to use the TCCL when marshalling in OSGi env? If yes how?
> > >  - I like the point 2. Maybe for a graph of object that come from
> > different
> > > packages / bundles you may have to recursively capture the package
> > version
> > > of the individual element of your graph.
> > >  - For the point 3 I wonder if it will not over-complexify the solution.
> > As
> > > a developer you will have to think about it. And it is not obvious in the
> > > code where things are serialized or not. You may use lambda in your
> > > application code therefore the current package become what you call a DTO
> > > package. The current state of ignite does not enforce you to specify it
> > for
> > > "classical" classloading application. If you introduce this extra step
> > for
> > > OSGi ready application you will maybe discourage people to use OSGi.
> > >
> > > To comeback to our solution. We start we a strong assumption: our cluster
> > > is homogeneous in term of code so, of course, it simplify our life :).
> > >
> > > BTW if you can introduce an extension point in the class resolution
> > > mechanism it can be interesting for end user in order to allow them to
> > > optimize it based on there specific use cases.
> > >
> > > Romain.
> > >
> > > Le mar. 3 nov. 2015 à 00:21, Raul Kripalani  a écrit :
> > >
> > > > Hi Andrey,
> > > >
> > > > Thanks for the participation in this topic.
> > > >
> > > > I don't like the solution to incorporate the bundle symbolic name in
> > the
> > > > serialised form. Nothing guarantees that the classdef will be located
> > > under
> > > > the same bundle in both source and target machines. We also have to
> > take
> > > > into account that OSGi allows for multiple versions of the same
> > > > bundle/packages to co-exist in the same  container. So it becomes more
> > > > complex.
> > > >
> > > > Using the TCCL should work when serialising, but it'll probably be of
> > no
> > > > use when deserialising on the other end.
> > > >
> > > > I need to enhance Ignite to:
> > > >
> > > > 1. Use the TCCL when marshalling on one end.
> > > > 2. Incorporate the package version of the class in the serialised form
> > if
> > > > Ignite is running in an OSGi environment.
> > > > 3. On the receiver end, discover cache entities / 

Re: OSGi migration may require a special marshaller

[Romain Gilles]

Hi Raul,
I had a look to what has been done in camel. I think here the use cases
came be different.
Let say I want to run a closure against the grid like this:

IgniteCompute compute  = ignite.compute();
// Execute closure on all cluster nodes.Collection res = compute.apply(
String::length,
Arrays.asList("How many characters".split(" "))
);
 // Add all the word lengths received from cluster nodes.

int total = res.stream().mapToInt(Integer::intValue).sum();

Then I think, even in more complex and realistic use cases, you may don't
want to export the implementation details of your closure. But this closure
will be serialized by the Ignite marshalling framework.

Romain.

Le mar. 3 nov. 2015 à 20:18, Raul Kripalani  a écrit :

> Hey guys,
>
> About the TCCL, I need to dig deeper into how serialisation is being done
> now. If, at any point, we are resolving a class through the classloader of
> a particular class, e.g. Ignition.getClass().getClassLoader(), etc. we are
> using the class space of the bundle containing that class. If we are using
> a class from Ignite, we obviously wouldn't be able to find a custom DTO
> provided by a user.
>
> In Camel we have found this problem several times and we've solved it by
> changing the TCCL, or using the TCCL [1] [2] to resolve classes.
>
> As I said, I need to look into this deeper and I'll have some time on
> Thursday, so I hope you don't mind waiting a little bit. I have already
> "bundle-fied" most of Ignite modules in the corresponding branch [3], so my
> next step is to test out the Ignite examples inside an OSGi environment
> (Karaf 4).
>
> [1] https://issues.apache.org/jira/browse/CAMEL-5748
> [2] https://issues.apache.org/jira/browse/CAMEL-5722
> [3] https://github.com/apache/ignite/tree/ignite-1527
>
> Regards,
>
> *Raúl Kripalani*
> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> Messaging Engineer
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
>
> On Tue, Nov 3, 2015 at 10:38 AM, Romain Gilles 
> wrote:
>
> > Hi Raul,
> >  - Do you plan to use the TCCL when marshalling in OSGi env? If yes how?
> >  - I like the point 2. Maybe for a graph of object that come from
> different
> > packages / bundles you may have to recursively capture the package
> version
> > of the individual element of your graph.
> >  - For the point 3 I wonder if it will not over-complexify the solution.
> As
> > a developer you will have to think about it. And it is not obvious in the
> > code where things are serialized or not. You may use lambda in your
> > application code therefore the current package become what you call a DTO
> > package. The current state of ignite does not enforce you to specify it
> for
> > "classical" classloading application. If you introduce this extra step
> for
> > OSGi ready application you will maybe discourage people to use OSGi.
> >
> > To comeback to our solution. We start we a strong assumption: our cluster
> > is homogeneous in term of code so, of course, it simplify our life :).
> >
> > BTW if you can introduce an extension point in the class resolution
> > mechanism it can be interesting for end user in order to allow them to
> > optimize it based on there specific use cases.
> >
> > Romain.
> >
> > Le mar. 3 nov. 2015 à 00:21, Raul Kripalani  a écrit :
> >
> > > Hi Andrey,
> > >
> > > Thanks for the participation in this topic.
> > >
> > > I don't like the solution to incorporate the bundle symbolic name in
> the
> > > serialised form. Nothing guarantees that the classdef will be located
> > under
> > > the same bundle in both source and target machines. We also have to
> take
> > > into account that OSGi allows for multiple versions of the same
> > > bundle/packages to co-exist in the same  container. So it becomes more
> > > complex.
> > >
> > > Using the TCCL should work when serialising, but it'll probably be of
> no
> > > use when deserialising on the other end.
> > >
> > > I need to enhance Ignite to:
> > >
> > > 1. Use the TCCL when marshalling on one end.
> > > 2. Incorporate the package version of the class in the serialised form
> if
> > > Ignite is running in an OSGi environment.
> > > 3. On the receiver end, discover cache entities / DTOs in all bundles
> > > through a custom OSGi manifest header or the like, as I explained
> before.
> > > Package version must be taken into account.
> > >
> > > What do you think?
> > >
> > > Raúl.
> > > On 2 Nov 2015 17:25, "Andrey Kornev"  wrote:
> > >
> > > > Raul,
> > > >
> > > > The fundamental hurdle we need to jump over to make Ignite
> OSGi-enabled
> > > is
> > > > the marshalling. More specifically the issue is with deserialization
> of
> > > the
> > > > classes that are provided by the bundles other than the Ignite bundle
> > > > itself.
> > > >
> > > > When the Ignite transport layer receives a 

Re: Ignite web console UI usability

[Dmitriy Setrakyan]

Pavel,

I do not have the same association as you. To me “Reset” means reset to the
previous state. I would prefer to leave it. If we still decide to change
it, then I would pick “Cancel”.

D.

On Tue, Nov 3, 2015 at 10:10 PM, Roman  wrote:

> To me, "Revert", "Cancel", "Undo" -- any of these is better than "Reset".
> -Roman
>
>
>
>  On Wednesday, November 4, 2015 1:29 PM, Pavel Konstantinov <
> pkonstanti...@gridgain.com> wrote:
>
>
>  Hi, Igniters,
>
> I'm playing with Ignite Web Console (console.gridgain.com) and would like
> to ask your opinion about name of 'Reset' button on Caches screen.
>
> By fact this button doing 'undo all changes'. But it's current name - Reset
> - a bit confusing me. When I see 'Reset' I'm thinking about 'reset to
> default values' or something similar. So I suggest to rename this button to
> 'Undo All' which will more consistent with the real action.
>
> Anyone else agree with me?
>
>
>
>

Re: Ignite web console UI usability

[Pavel Konstantinov]

Guys,

Currently each section has undo button without any text name only 'round
arrow' image.
Maybe make the same button on the top level?

On Wed, Nov 4, 2015 at 2:24 PM, Dmitriy Setrakyan 
wrote:

> Pavel,
>
> I do not have the same association as you. To me “Reset” means reset to the
> previous state. I would prefer to leave it. If we still decide to change
> it, then I would pick “Cancel”.
>
> D.
>
> On Tue, Nov 3, 2015 at 10:10 PM, Roman  wrote:
>
> > To me, "Revert", "Cancel", "Undo" -- any of these is better than "Reset".
> > -Roman
> >
> >
> >
> >  On Wednesday, November 4, 2015 1:29 PM, Pavel Konstantinov <
> > pkonstanti...@gridgain.com> wrote:
> >
> >
> >  Hi, Igniters,
> >
> > I'm playing with Ignite Web Console (console.gridgain.com) and would
> like
> > to ask your opinion about name of 'Reset' button on Caches screen.
> >
> > By fact this button doing 'undo all changes'. But it's current name -
> Reset
> > - a bit confusing me. When I see 'Reset' I'm thinking about 'reset to
> > default values' or something similar. So I suggest to rename this button
> to
> > 'Undo All' which will more consistent with the real action.
> >
> > Anyone else agree with me?
> >
> >
> >
> >
>

[jira] [Created] (IGNITE-1853) Implement plugins support

[Dmitriyff (JIRA)]

Dmitriyff created IGNITE-1853:
-

 Summary: Implement plugins support
 Key: IGNITE-1853
 URL: https://issues.apache.org/jira/browse/IGNITE-1853
 Project: Ignite
  Issue Type: Sub-task
  Components: wizards
Affects Versions: 1.5
Reporter: Dmitriyff
Assignee: Dmitriyff
 Fix For: 1.5


add task ruuner support to project, implement task to include plugins for app



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Ignite-1.5 Release

[Denis Magda]

On 11/2/2015 8:40 PM, Dmitriy Setrakyan wrote:

On Mon, Nov 2, 2015 at 6:58 AM, M G  wrote:


Can/will this include https://issues.apache.org/jira/browse/IGNITE-1681 ?


I don’t see why not. Would be nice if one of the committers could pick up
the review for this patch.

Dmitriy and other committers, who keep an eye on public API changes, are 
you OK with the changes in CacheConfiguration API done in IGNITE-1681?


--
Denis

On Mon, Nov 2, 2015 at 1:51 PM, Anton Vinogradov 

wrote:

Guys,

I think we can start preparation to Ignite-1.5 release which will

include

many interesting features:

1. Portable object API
https://issues.apache.org/jira/browse/IGNITE-1486

2. Ignite.NET and Ignite C++
https://issues.apache.org/jira/browse/IGNITE-1282

3. Optimistic serializable transactions
https://issues.apache.org/jira/browse/IGNITE-1607

4. Distributed SQL joins - we will be able to query non-collocated

data

as

well
https://issues.apache.org/jira/browse/IGNITE-1232

5. Enhanced Oracle and IBM JDK interoperability
https://issues.apache.org/jira/browse/IGNITE-1526

6. MQTT streamer
https://issues.apache.org/jira/browse/IGNITE-535

7. Continuous query failover
https://issues.apache.org/jira/browse/IGNITE-426

8. Significant transactional cache performance optimizations - I will
merge
these changes from 'ignite-1.4-slow-server-debug' today or tomorrow.

9. Many stability and fault-tolerance fixes.

10. I would also like to include distributed Semaphore. Vladislav, any
chance you can finish with it this week?
https://issues.apache.org/jira/browse/IGNITE-
638

Thanks to everyone involved! Guys, esp. assignees of mentioned issues,
please respond to this email and let us know when can we expect your
changes being merged to master and release branch?

Can someone create ignite-1.5 release branch?

--Yakov

Re: IgniteMultiMap design

[Vladisav Jelisavcic]

Dear Dmitriy,

it sounds excellent, I would like to do it,
but I would like to implement ReentrantLock first:
https://issues.apache.org/jira/browse/IGNITE-642

What do you think?


On Tue, Nov 3, 2015 at 3:37 AM, Dmitriy Setrakyan 
wrote:

> Igniters,
>
> MultiMap should be really great addition to the Ignite fabric, as it
> provides an easy-to-use API to work with time-series data.
>
> I have added a detailed design description to the IgniteMultiMap ticket:
> https://issues.apache.org/jira/browse/IGNITE-640
>
> Vladislav Jelisavcic, the ticket is currently assigned to you. If you still
> intend to work on it,  please review it and let us know if the design makes
> sense.
>
> Also, would be nice if others could review it and provide comments as well.
>
> D.
>

[jira] [Created] (IGNITE-1850) IGFS: implicitly created directoried should always have default properties

[Ivan Veselovsky (JIRA)]

Ivan Veselovsky created IGNITE-1850:
---

 Summary: IGFS: implicitly created directoried should always have 
default properties
 Key: IGNITE-1850
 URL: https://issues.apache.org/jira/browse/IGNITE-1850
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Veselovsky
Assignee: Ivan Veselovsky


Currently we have #create, #append , #mkdirs operations that implicitly create 
parent directories if they are absent.
Now #mkdirs uses the properties passed in for the implicitly created 
directories if they are not null, and uses default properties (with 0777 
permission flag) if the properties are not given.
#create & #append use for the implicitly created directories properties passed 
in for newly created file, if the passed in properties are not null, and use 
default properties (with 0777 permission flag) if they are not given.
It would be more logical to always use defaults for the implicitly created 
directories. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)