[jira] [Created] (IGNITE-4801) Add ability to change end month to period

[Dmitriy Shabalin (JIRA)]

Dmitriy Shabalin created IGNITE-4801:


 Summary: Add ability to change end month to period
 Key: IGNITE-4801
 URL: https://issues.apache.org/jira/browse/IGNITE-4801
 Project: Ignite
  Issue Type: Task
  Components: wizards
Reporter: Dmitriy Shabalin
Assignee: Dmitriy Shabalin


Add selector to end month



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Continuations for services

[Dmitriy Setrakyan]

Vladimr, it sounds like what you are suggesting is allowing users specify
named executors in configuration and then use them from code, right? I
think I like this idea very much.

On Wed, Mar 8, 2017 at 1:46 PM, Vladimir Ozerov 
wrote:

> Continuations is not very good idea. It is useful if user has simple logic
> when one job calls another from within the same execute/run/call method.
> But if you have complex logic with OOP abstractions and reusable
> components, nested job call can be located many stack frames down from
> parent job. In this case continuations are unusable.
>
> More convenient approach is to map separate jobs to separate thread pools.
> This technique is successfully employed in Hazelcast. You just define
> additional executors and say that job A is to be executed one thread pool,
> and job B on another.
>
> The same technique is applicable for services:
>
> class MyService implements Service {
> @IgniteInstanceResource
> Ignite ignite;
>
> void myMethod() {
>
> ignite.service().withExecutor("myExecutor").service("
> myService").nestedCall();
> }
> }
>
> All in all I would do the following:
> 1) Create separate built-in pool for services to make sure that in simple
> cases users are able to call compute jobs from service methods.
> 2) Implement custom executors which will be applicable for both compute [1]
> and service components.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-4699
>
> 08 марта 2017 г. 23:01 пользователь "Dmitriy Setrakyan" <
> dsetrak...@apache.org> написал:
>
> > On Wed, Mar 8, 2017 at 11:58 AM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Separate thread pool will not solve the case of calling a service from
> > > another service.
> > >
> >
> > Why not? The caller thread should block.
> >
>

Re: Ignite 2.0 - Update Spring dependency to latest stable version

[Vyacheslav Daradur]

It is ready for review.

Please, take a look at comment in the issue.

2017-03-07 22:26 GMT+03:00 Denis Magda :

> Yes, it’s planned for 2.0 release. You can assign it on yourself helping
> out the community to release as many improvements in 2.0 as possible.
>
> —
> Denis
>
> > On Mar 7, 2017, at 2:59 AM, Vyacheslav Daradur 
> wrote:
> >
> > Hello everyone!
> >
> > There are no changes long ago:
> > https://issues.apache.org/jira/browse/IGNITE-4211
> >
> > Is it actual?
>
>

Re: Continuations for services

[Vladimir Ozerov]

Continuations is not very good idea. It is useful if user has simple logic
when one job calls another from within the same execute/run/call method.
But if you have complex logic with OOP abstractions and reusable
components, nested job call can be located many stack frames down from
parent job. In this case continuations are unusable.

More convenient approach is to map separate jobs to separate thread pools.
This technique is successfully employed in Hazelcast. You just define
additional executors and say that job A is to be executed one thread pool,
and job B on another.

The same technique is applicable for services:

class MyService implements Service {
@IgniteInstanceResource
Ignite ignite;

void myMethod() {

ignite.service().withExecutor("myExecutor").service("myService").nestedCall();
}
}

All in all I would do the following:
1) Create separate built-in pool for services to make sure that in simple
cases users are able to call compute jobs from service methods.
2) Implement custom executors which will be applicable for both compute [1]
and service components.

[1] https://issues.apache.org/jira/browse/IGNITE-4699

08 марта 2017 г. 23:01 пользователь "Dmitriy Setrakyan" <
dsetrak...@apache.org> написал:

> On Wed, Mar 8, 2017 at 11:58 AM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Separate thread pool will not solve the case of calling a service from
> > another service.
> >
>
> Why not? The caller thread should block.
>

Re: Continuations for services

[Dmitriy Setrakyan]

On Wed, Mar 8, 2017 at 11:58 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Separate thread pool will not solve the case of calling a service from
> another service.
>

Why not? The caller thread should block.

Re: Continuations for services

[Valentin Kulichenko]

Separate thread pool will not solve the case of calling a service from
another service.

-Val

On Wed, Mar 8, 2017 at 8:38 PM, Dmitriy Setrakyan 
wrote:

> On Wed, Mar 8, 2017 at 11:36 AM, Vladimir Ozerov 
> wrote:
>
> > Val,
> >
> > Don't panic! :) I created a ticket for custom thread pools for compute
> > tasks recently. Probably it can help us with services as well.
> >
>
> Vlad, can you please share your vision, either here or in the ticket, of
> how this design would apply to services configuration?
>

Re: Continuations for services

[Vladimir Ozerov]

Val,

Don't panic! :) I created a ticket for custom thread pools for compute
tasks recently. Probably it can help us with services as well.


08 марта 2017 г. 22:15 пользователь "Dmitriy Setrakyan" <
dsetrak...@apache.org> написал:

How about deploying services in their own thread pools?

On Wed, Mar 8, 2017 at 2:05 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Igniters,
>
> I recently realized that we have serious architectural flow in Service
> Grid. The problem is services are executed in public thread pool, which
> means that user can't:
>
> - synchronously invoke service from another service
> - synchronously invoke task/closure from service
>
> In Compute Grid we have continuations to address this, but there is
nothing
> similar in Service Grid. Any ideas how we can support this?
>
> -Val
>

Re: Continuations for services

[Dmitriy Setrakyan]

How about deploying services in their own thread pools?

On Wed, Mar 8, 2017 at 2:05 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Igniters,
>
> I recently realized that we have serious architectural flow in Service
> Grid. The problem is services are executed in public thread pool, which
> means that user can't:
>
> - synchronously invoke service from another service
> - synchronously invoke task/closure from service
>
> In Compute Grid we have continuations to address this, but there is nothing
> similar in Service Grid. Any ideas how we can support this?
>
> -Val
>

Re: [ANNOUNCE] Apache Ignite 1.9.0 Released

[Andrey Gura]

Pull request for Apache Zeppelin is already created, approved and
waiting for merging into master branch. I hope that Apache Ignite 1.9
will be included in Apache Zeppelin 0.8.0 release.

On Tue, Mar 7, 2017 at 10:50 PM, Denis Magda  wrote:
> Andrey,
>
> Excellent! Thanks for keeping an eye on this. Please let us know what you do 
> the same for Zeppelin.
>
> *Raul*, *Roman*, could you update Camel and MyBatis integrations respectively?
> https://cwiki.apache.org/confluence/display/IGNITE/External+Integrations 
> 
>
> —
> Denis
>
>> On Mar 7, 2017, at 11:47 AM, Andrey Gura  wrote:
>>
>> JFYI
>>
>> Also today Vert.x 3.4.0 was released with Apache Ignite 1.9 based
>> cluster manager for Vert.x in HA/Clustered mode.
>>
>> On Tue, Mar 7, 2017 at 3:10 AM, Denis Magda  wrote:
>>> The Apache Ignite Community is pleased to announce the release of Apache 
>>> Ignite 1.9.0.
>>>
>>> Apache Ignite In-Memory Data Fabric [1] is a high-performance, integrated 
>>> and distributed in-memory platform for computing and transacting on 
>>> large-scale data sets in real-time, orders of magnitude faster than 
>>> possible with traditional disk-based or flash-based technologies.
>>>
>>> The Fabric is a collection of independent and well integrated components 
>>> some of which are the following:
>>> Data Grid
>>> SQL Grid
>>> Compute Grid
>>> Streaming & CEP
>>> Service Grid
>>>
>>>
>>> In this release the community provided an integration with Kubernetes 
>>> cluster manager, improved performance of core and SQL Grid components, 
>>> expanded Data Modification Language support to the level of .NET and C++ 
>>> API, integrated with .NET TransactionScope API and more.
>>>
>>> Learn more details from our blog post: 
>>> https://blogs.apache.org/ignite/entry/apache-ignite-1-9-released
>>>
>>> The full list of the changes can be found here [2].
>>>
>>> Please visit this page if you’re ready to try the release out:
>>> https://ignite.apache.org/download.cgi
>>>
>>> Please let us know [3] if you encounter any problems.
>>>
>>> Regards,
>>>
>>> The Apache Ignite Community
>>>
>>> [1] https://ignite.apache.org
>>> [2] https://github.com/apache/ignite/blob/master/RELEASE_NOTES.txt
>>> [3] https://ignite.apache.org/community/resources.html#ask
>

[GitHub] ignite pull request #1603: IGNITE-4211

[daradurvs]

GitHub user daradurvs opened a pull request:

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

IGNITE-4211



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

$ git pull https://github.com/daradurvs/ignite ignite-4211

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

https://github.com/apache/ignite/pull/1603.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 #1603


commit 2aa591f1b7269ddabc9afcb99eba99984ec40f2c
Author: daradurvs 
Date:   2017-03-08T15:21:59Z

ignite-4211: duplicate properties were removed

commit 3a4c4d55105e681d0dce9d053a3feb50ff454f65
Author: daradurvs 
Date:   2017-03-08T16:02:13Z

ignite-4211: property of Spring version to 4.3.7.RELEASE  was updated

commit 703ff4a41dad5022d97b42397aed186a5f993d91
Author: daradurvs 
Date:   2017-03-08T16:02:53Z

ignite-4211: new get-method was implemented




---
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.
---

[GitHub] ignite pull request #1602: IGNITE-4761: ServiceProcessor hangs while stoppin...

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

IGNITE-4761: ServiceProcessor hangs while stopping on unstable topology.



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

$ git pull https://github.com/gridgain/apache-ignite ignite-4761-1

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

https://github.com/apache/ignite/pull/1602.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 #1602


commit 1433ed3299cc206b09b78b34d6d20922a0bf4320
Author: AMRepo 
Date:   2017-03-08T15:23:23Z

Fixed.




---
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.
---

[jira] [Created] (IGNITE-4800) Lucene query may fails with NPE.

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-4800:


 Summary: Lucene query may fails with NPE.
 Key: IGNITE-4800
 URL: https://issues.apache.org/jira/browse/IGNITE-4800
 Project: Ignite
  Issue Type: Bug
  Components: SQL
Affects Versions: 1.8
Reporter: Andrew Mashenkov
 Fix For: 2.0
 Attachments: application_lucene.log

GridLuceneFile 'buffers' field is set to null regardless file can be used in 
GridLuceneInputStream by some query.

We should add a guard, that will prevent 'buffers' to be cleared until all 
GridLuceneInputStream-s is closed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Ensure that builder approach is used for all setters in public API

[Andrey Mashenkov]

IGNITE-4564 is ready for review.
.

1. JdbcCheckpointSpi implements MBean interface, but never registered as
MBean. Should it be fixed somehow?
2. Should we move MBeans interface metods from SPI implementation to MBean
implementation or just make calls from MBean to SPI as it done for now,
some of these methods can be used in unittests?



On Mon, Feb 13, 2017 at 5:50 PM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> Andrey, Yakov,
>
> An MBean for eviction policy is registered in GridCacheProcessor#prepare().
>
> --AG
>
> 2017-02-09 18:53 GMT+03:00 Yakov Zhdanov :
>
> > Wow! This is the regression (from long ago version) if true.
> >
> > As far as having mbean to manage eviction policy on the fly - why not?
> This
> > is handy.
> >
> > --
> > Yakov Zhdanov
> >
> > On Feb 9, 2017 9:09 PM, "Andrey Mashenkov" 
> > wrote:
> >
> > > Folks,
> > >
> > > I've found no mention in ignite code where EvictionPolicy used as MBean
> > and
> > > it seems it is never registered as MBean.
> > > Is it really need to have MBean interfaces for EvictionPolicy
> > > implementations?
> > >
> > >
> > >
> > > On Wed, Feb 8, 2017 at 7:23 AM, Yakov Zhdanov 
> > wrote:
> > >
> > > > +1 to Vladimir suggestion
> > > >
> > > > --Yakov
> > > >
> > > > 2017-02-07 20:50 GMT+07:00 Vladimir Ozerov :
> > > >
> > > > > Andrey, Valya,
> > > > >
> > > > > There is another problem here. What is we decide to add some
> existing
> > > > > setter method to MBean? If it has signature "T setSomething(...)",
> we
> > > > will
> > > > > not be able to do so. We need to understand how to deal with it, so
> > > that
> > > > > possible further improvements to MBean-s are not compromised. Any
> > > ideas?
> > > > > May be we should fully decouple MBeans into separate classes?
> > > > >
> > > > > E.g. instead of:
> > > > > FifoEvictionPolicy implements FifoEvictionPolicyMBean
> > > > >
> > > > > we will have
> > > > > FifoEvictionPolicy
> > > > > FifoEvictionPolicyMBeanImpl implements FifoEvictionPolicyMBean
> > > > >
> > > > > This way public API will be fully decoupled form JMX what seems
> > > > reasonable
> > > > > to me. Thoughts?
> > > > >
> > > > > On Tue, Feb 7, 2017 at 4:31 PM, Andrey Mashenkov <
> > > > > andrey.mashen...@gmail.com
> > > > > > wrote:
> > > > >
> > > > > > Val,
> > > > > >
> > > > > > void setBatchSize(int batchSize)
> > > > > > void setMaxMemorySize(long maxMemSize)
> > > > > > void setMaxSize(int max)
> > > > > > void setExcludePaths(Collection excludePaths)
> > > > > > void setMaxBlocks(int maxBlocks)
> > > > > > void setParallelJobsNumber(int num)
> > > > > > void setWaitingJobsNumber(int num)
> > > > > >
> > > > > > https://ignite.apache.org/releases/1.8.0/javadoc/org/
> > > > > > apache/ignite/cache/eviction/fifo/FifoEvictionPolicyMBean.html
> > > > > > https://ignite.apache.org/releases/1.8.0/javadoc/org/
> > > > > > apache/ignite/cache/eviction/igfs/IgfsPerBlockLruEvictionPolicyM
> > > > > XBean.html
> > > > > > https://ignite.apache.org/releases/1.8.0/javadoc/org/
> > > > > > apache/ignite/cache/eviction/lru/LruEvictionPolicyMBean.html
> > > > > > https://ignite.apache.org/releases/1.8.0/javadoc/org/
> > > > > > apache/ignite/cache/eviction/sorted/
> SortedEvictionPolicyMBean.html
> > > > > > https://ignite.apache.org/releases/1.8.0/javadoc/org/
> > > > > > apache/ignite/spi/collision/fifoqueue/
> FifoQueueCollisionSpiMBean.
> > > html
> > > > > >
> > > > > > On Tue, Feb 7, 2017 at 2:18 AM, Valentin Kulichenko <
> > > > > > valentin.kuliche...@gmail.com> wrote:
> > > > > >
> > > > > > > Andrey,
> > > > > > >
> > > > > > > Can you list all setters that we have on MBeans?
> > > > > > >
> > > > > > > -Val
> > > > > > >
> > > > > > > On Mon, Feb 6, 2017 at 2:21 PM, Andrey Mashenkov <
> > > > > > > andrey.mashen...@gmail.com
> > > > > > > > wrote:
> > > > > > >
> > > > > > > > Folks,
> > > > > > > >
> > > > > > > > Changing MBeans setters signature is bad idea. AOP tests
> failed
> > > on
> > > > TC
> > > > > > > with
> > > > > > > > this change.
> > > > > > > >
> > > > > > > > On Mon, Feb 6, 2017 at 11:21 AM, Vladimir Ozerov <
> > > > > voze...@gridgain.com
> > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Val,
> > > > > > > > >
> > > > > > > > > Good catch! Can we try leaving SPIs and base methods
> > untouched?
> > > > > Will
> > > > > > it
> > > > > > > > API
> > > > > > > > > be consistent in this case?
> > > > > > > > >
> > > > > > > > > On Fri, Feb 3, 2017 at 10:22 PM, Valentin Kulichenko <
> > > > > > > > > valentin.kuliche...@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > > Folks,
> > > > > > > > > >
> > > > > > > > > > I tend to think that the problem is that we try to apply
> > > > 'builder
> > > > > > > > > approach'
> > > > > > > > > > to *ALL* setters. Let's approach this smarter.
> > > > > > > > > >
> > > > > > > > > > This approach is actually applicable only for
> configuration
> > 

Continuations for services

[Valentin Kulichenko]

Igniters,

I recently realized that we have serious architectural flow in Service
Grid. The problem is services are executed in public thread pool, which
means that user can't:

- synchronously invoke service from another service
- synchronously invoke task/closure from service

In Compute Grid we have continuations to address this, but there is nothing
similar in Service Grid. Any ideas how we can support this?

-Val