I am sorry for causing confusion. IGNITE-6531

[JD Nam <jo...@gmail.com>]

Hello Igniter!

First of all, I'm sorry. I was not aware of the ignite community process
well, so I did not follow the guideline and caused the confusion to the
community.
My name is joungdal.nam and I made the issue as following link.
https://issues.apache.org/jira/browse/IGNITE-6531

Pleases allow me to introduce myself.
I am a java developer working in e-Commerce in a small country in Asia.
Currently, I am developing a Spring based framework (for our company domain
only).

We had a little problems in developing our program, especially Batch.
Most java developers in the company for which I work are domain experts,
they are not getting away from jar-hell
There are a lot of problems associated with CPU and memory, etc., because
many java batches that are starting and shutdown by the scheduler work like
many beans of spring.
It is not possible to separate a module (lib) because it takes too much
time and resources.

When I saw ignite I shouted Eureka.
By applying Spring-boot & Ignite's ComputeTask, I thought I'd have to a
Distribute Batch Platform with Daemon.
The main concept of this platform is to assign a job to a node with the
lowest load through the matrix information of the ignite cluster.
Since all CRUD work is handled by Oracle, ignite's distributed computing
seemed to be of great help (source can not be hdfs.)
I do not want to shutdown manually, so, the client node is managed by
initiating shutdown if the count of running nodes reaches the threshold
value by using userAttribute. The version is named to jar file name and
build time as postfix.

Sorry. I'll get to the point. The reason why I created IGNITE-6531 is that
the batch of my company has too many beans.
Unfortunately, I am not able to tell which lib contains a particular bean.
Moreover, I am not able to remove the lib even if I find the lib (the
product may not be delivered to the customer)
Certain beans only work in stg, prod in dev, qa, stg, prod (external
communication issue or firewall problem)
Due to the nature of our Traditional Business, instances of beans are
created only under certain circumstances and cannot be injected in other
environments.

After all, the best way to do this is to treat it the same as the method of
the spring framework.
When injecting another spring bean in ComputeTask,  we could write it just
like @AutoWired (required = false).
I did not want to see the non-operation of the daemon because of a runtime
exception due to a firewall problem.
So, I thought “required = false” is required @SpringResource.
Hope to hear your opinion on this.
Once, again, I would like to apologize that I did not aware of the ignite
process.



I also have another question. I heard that there is an issue with
configuration on the mailing list.
How deploy node with different env, do you use it as below?

In the java code,
try (Ignite ignite = Ignition.start("/config/ignite.xml")) { // deault zone
try (Ignite ignite = Ignition.start("/config/ignite-dev.xml")) { // dev?
try (Ignite ignite = Ignition.start("/config/ignite-qa.xml")) { // qa?
try (Ignite ignite = Ignition.start("/config/ignite-stg.xml")) { // stg??

It will be a more user friendly settling by using yaml. Our project has
over 300 properties
If yaml is supported by ignite, it would be much more convenience. (If you
do not have a plan to support spring-boot)
I used ignite-default.yml, ignite-dev.yml, etc in my project. By
distinguishing java -D options, codes are not revised and I only read
configuration.



I think there's a mistype in the document of the link below.
It is the example of SqlFieldsQuery.
https://apacheignite-sql.readme.io/docs/java-sql-api
try (QueryCursor <List <? >> cursor = cache.query (sql) {

I think there should be one more ')' as below.
= cache.query (sql))  {

I'll try to read the contribute documentation to fix this issue.
It's better if you fix it.
Ignite is really cool, you guys are really great.

Re: I am sorry for causing confusion. IGNITE-6531

[JD Nam <jo...@gmail.com>]

Thank you for helping us solve our business problems.

Thanks,
Denis

2018-05-30 2:10 GMT+09:00 Denis Magda <dm...@apache.org>:

> Hello,
>
> Thanks for outlining your problem and sending a patch for it. In general,
> if such minor improvements help to solve business cases, then I would add
> them to the project.
>
> Guess, we might need to rename the interface method. Dmitriy P., as one of
> the reviewers, could you please chime in and share your vision?
>
> --
> Denis
>
> On Mon, May 28, 2018 at 6:57 AM, Ilya Lantukh <il...@gridgain.com>
> wrote:
>
> > Welcome to Apache Ignite community!
> >
> > The problem with your ticket is that it's not clear what value it adds to
> > the project and how it will improve user experience in general. The
> problem
> > you described is rather narrow and I am sure it's possible to find a
> > workaround without modifying Ignite code.
> > If you think that such option can be helpful in more general cases,
> please
> > explain why and how.
> >
> > Thanks!
> >
> > On Mon, May 28, 2018 at 4:27 PM, JD Nam <jo...@gmail.com> wrote:
> >
> > > Hello Igniter!
> > >
> > > First of all, I'm sorry. I was not aware of the ignite community
> process
> > > well, so I did not follow the guideline and caused the confusion to the
> > > community.
> > > My name is joungdal.nam and I made the issue as following link.
> > > https://issues.apache.org/jira/browse/IGNITE-6531
> > >
> > > Pleases allow me to introduce myself.
> > > I am a java developer working in e-Commerce in a small country in Asia.
> > > Currently, I am developing a Spring based framework (for our company
> > domain
> > > only).
> > >
> > > We had a little problems in developing our program, especially Batch.
> > > Most java developers in the company for which I work are domain
> experts,
> > > they are not getting away from jar-hell
> > > There are a lot of problems associated with CPU and memory, etc.,
> because
> > > many java batches that are starting and shutdown by the scheduler work
> > like
> > > many beans of spring.
> > > It is not possible to separate a module (lib) because it takes too much
> > > time and resources.
> > >
> > > When I saw ignite I shouted Eureka.
> > > By applying Spring-boot & Ignite's ComputeTask, I thought I'd have to a
> > > Distribute Batch Platform with Daemon.
> > > The main concept of this platform is to assign a job to a node with the
> > > lowest load through the matrix information of the ignite cluster.
> > > Since all CRUD work is handled by Oracle, ignite's distributed
> computing
> > > seemed to be of great help (source can not be hdfs.)
> > > I do not want to shutdown manually, so, the client node is managed by
> > > initiating shutdown if the count of running nodes reaches the threshold
> > > value by using userAttribute. The version is named to jar file name and
> > > build time as postfix.
> > >
> > > Sorry. I'll get to the point. The reason why I created IGNITE-6531 is
> > that
> > > the batch of my company has too many beans.
> > > Unfortunately, I am not able to tell which lib contains a particular
> > bean.
> > > Moreover, I am not able to remove the lib even if I find the lib (the
> > > product may not be delivered to the customer)
> > > Certain beans only work in stg, prod in dev, qa, stg, prod (external
> > > communication issue or firewall problem)
> > > Due to the nature of our Traditional Business, instances of beans are
> > > created only under certain circumstances and cannot be injected in
> other
> > > environments.
> > >
> > > After all, the best way to do this is to treat it the same as the
> method
> > of
> > > the spring framework.
> > > When injecting another spring bean in ComputeTask,  we could write it
> > just
> > > like @AutoWired (required = false).
> > > I did not want to see the non-operation of the daemon because of a
> > runtime
> > > exception due to a firewall problem.
> > > So, I thought “required = false” is required @SpringResource.
> > > Hope to hear your opinion on this.
> > > Once, again, I would like to apologize that I did not aware of the
> ignite
> > > process.
> > >
> > >
> > >
> > > I also have another question. I heard that there is an issue with
> > > configuration on the mailing list.
> > > How deploy node with different env, do you use it as below?
> > >
> > > In the java code,
> > > try (Ignite ignite = Ignition.start("/config/ignite.xml")) { // deault
> > > zone
> > > try (Ignite ignite = Ignition.start("/config/ignite-dev.xml")) { //
> dev?
> > > try (Ignite ignite = Ignition.start("/config/ignite-qa.xml")) { // qa?
> > > try (Ignite ignite = Ignition.start("/config/ignite-stg.xml")) { //
> > stg??
> > >
> > > It will be a more user friendly settling by using yaml. Our project has
> > > over 300 properties
> > > If yaml is supported by ignite, it would be much more convenience. (If
> > you
> > > do not have a plan to support spring-boot)
> > > I used ignite-default.yml, ignite-dev.yml, etc in my project. By
> > > distinguishing java -D options, codes are not revised and I only read
> > > configuration.
> > >
> > >
> > >
> > > I think there's a mistype in the document of the link below.
> > > It is the example of SqlFieldsQuery.
> > > https://apacheignite-sql.readme.io/docs/java-sql-api
> > > try (QueryCursor <List <? >> cursor = cache.query (sql) {
> > >
> > > I think there should be one more ')' as below.
> > > = cache.query (sql))  {
> > >
> > > I'll try to read the contribute documentation to fix this issue.
> > > It's better if you fix it.
> > > Ignite is really cool, you guys are really great.
> > >
> >
> >
> >
> > --
> > Best regards,
> > Ilya
> >
>

Re: I am sorry for causing confusion. IGNITE-6531

[Denis Magda <dm...@apache.org>]

Hello,

Thanks for outlining your problem and sending a patch for it. In general,
if such minor improvements help to solve business cases, then I would add
them to the project.

Guess, we might need to rename the interface method. Dmitriy P., as one of
the reviewers, could you please chime in and share your vision?

--
Denis

On Mon, May 28, 2018 at 6:57 AM, Ilya Lantukh <il...@gridgain.com> wrote:

> Welcome to Apache Ignite community!
>
> The problem with your ticket is that it's not clear what value it adds to
> the project and how it will improve user experience in general. The problem
> you described is rather narrow and I am sure it's possible to find a
> workaround without modifying Ignite code.
> If you think that such option can be helpful in more general cases, please
> explain why and how.
>
> Thanks!
>
> On Mon, May 28, 2018 at 4:27 PM, JD Nam <jo...@gmail.com> wrote:
>
> > Hello Igniter!
> >
> > First of all, I'm sorry. I was not aware of the ignite community process
> > well, so I did not follow the guideline and caused the confusion to the
> > community.
> > My name is joungdal.nam and I made the issue as following link.
> > https://issues.apache.org/jira/browse/IGNITE-6531
> >
> > Pleases allow me to introduce myself.
> > I am a java developer working in e-Commerce in a small country in Asia.
> > Currently, I am developing a Spring based framework (for our company
> domain
> > only).
> >
> > We had a little problems in developing our program, especially Batch.
> > Most java developers in the company for which I work are domain experts,
> > they are not getting away from jar-hell
> > There are a lot of problems associated with CPU and memory, etc., because
> > many java batches that are starting and shutdown by the scheduler work
> like
> > many beans of spring.
> > It is not possible to separate a module (lib) because it takes too much
> > time and resources.
> >
> > When I saw ignite I shouted Eureka.
> > By applying Spring-boot & Ignite's ComputeTask, I thought I'd have to a
> > Distribute Batch Platform with Daemon.
> > The main concept of this platform is to assign a job to a node with the
> > lowest load through the matrix information of the ignite cluster.
> > Since all CRUD work is handled by Oracle, ignite's distributed computing
> > seemed to be of great help (source can not be hdfs.)
> > I do not want to shutdown manually, so, the client node is managed by
> > initiating shutdown if the count of running nodes reaches the threshold
> > value by using userAttribute. The version is named to jar file name and
> > build time as postfix.
> >
> > Sorry. I'll get to the point. The reason why I created IGNITE-6531 is
> that
> > the batch of my company has too many beans.
> > Unfortunately, I am not able to tell which lib contains a particular
> bean.
> > Moreover, I am not able to remove the lib even if I find the lib (the
> > product may not be delivered to the customer)
> > Certain beans only work in stg, prod in dev, qa, stg, prod (external
> > communication issue or firewall problem)
> > Due to the nature of our Traditional Business, instances of beans are
> > created only under certain circumstances and cannot be injected in other
> > environments.
> >
> > After all, the best way to do this is to treat it the same as the method
> of
> > the spring framework.
> > When injecting another spring bean in ComputeTask,  we could write it
> just
> > like @AutoWired (required = false).
> > I did not want to see the non-operation of the daemon because of a
> runtime
> > exception due to a firewall problem.
> > So, I thought “required = false” is required @SpringResource.
> > Hope to hear your opinion on this.
> > Once, again, I would like to apologize that I did not aware of the ignite
> > process.
> >
> >
> >
> > I also have another question. I heard that there is an issue with
> > configuration on the mailing list.
> > How deploy node with different env, do you use it as below?
> >
> > In the java code,
> > try (Ignite ignite = Ignition.start("/config/ignite.xml")) { // deault
> > zone
> > try (Ignite ignite = Ignition.start("/config/ignite-dev.xml")) { // dev?
> > try (Ignite ignite = Ignition.start("/config/ignite-qa.xml")) { // qa?
> > try (Ignite ignite = Ignition.start("/config/ignite-stg.xml")) { //
> stg??
> >
> > It will be a more user friendly settling by using yaml. Our project has
> > over 300 properties
> > If yaml is supported by ignite, it would be much more convenience. (If
> you
> > do not have a plan to support spring-boot)
> > I used ignite-default.yml, ignite-dev.yml, etc in my project. By
> > distinguishing java -D options, codes are not revised and I only read
> > configuration.
> >
> >
> >
> > I think there's a mistype in the document of the link below.
> > It is the example of SqlFieldsQuery.
> > https://apacheignite-sql.readme.io/docs/java-sql-api
> > try (QueryCursor <List <? >> cursor = cache.query (sql) {
> >
> > I think there should be one more ')' as below.
> > = cache.query (sql))  {
> >
> > I'll try to read the contribute documentation to fix this issue.
> > It's better if you fix it.
> > Ignite is really cool, you guys are really great.
> >
>
>
>
> --
> Best regards,
> Ilya
>

Re: I am sorry for causing confusion. IGNITE-6531

[Ilya Lantukh <il...@gridgain.com>]

Welcome to Apache Ignite community!

The problem with your ticket is that it's not clear what value it adds to
the project and how it will improve user experience in general. The problem
you described is rather narrow and I am sure it's possible to find a
workaround without modifying Ignite code.
If you think that such option can be helpful in more general cases, please
explain why and how.

Thanks!

On Mon, May 28, 2018 at 4:27 PM, JD Nam <jo...@gmail.com> wrote:

> Hello Igniter!
>
> First of all, I'm sorry. I was not aware of the ignite community process
> well, so I did not follow the guideline and caused the confusion to the
> community.
> My name is joungdal.nam and I made the issue as following link.
> https://issues.apache.org/jira/browse/IGNITE-6531
>
> Pleases allow me to introduce myself.
> I am a java developer working in e-Commerce in a small country in Asia.
> Currently, I am developing a Spring based framework (for our company domain
> only).
>
> We had a little problems in developing our program, especially Batch.
> Most java developers in the company for which I work are domain experts,
> they are not getting away from jar-hell
> There are a lot of problems associated with CPU and memory, etc., because
> many java batches that are starting and shutdown by the scheduler work like
> many beans of spring.
> It is not possible to separate a module (lib) because it takes too much
> time and resources.
>
> When I saw ignite I shouted Eureka.
> By applying Spring-boot & Ignite's ComputeTask, I thought I'd have to a
> Distribute Batch Platform with Daemon.
> The main concept of this platform is to assign a job to a node with the
> lowest load through the matrix information of the ignite cluster.
> Since all CRUD work is handled by Oracle, ignite's distributed computing
> seemed to be of great help (source can not be hdfs.)
> I do not want to shutdown manually, so, the client node is managed by
> initiating shutdown if the count of running nodes reaches the threshold
> value by using userAttribute. The version is named to jar file name and
> build time as postfix.
>
> Sorry. I'll get to the point. The reason why I created IGNITE-6531 is that
> the batch of my company has too many beans.
> Unfortunately, I am not able to tell which lib contains a particular bean.
> Moreover, I am not able to remove the lib even if I find the lib (the
> product may not be delivered to the customer)
> Certain beans only work in stg, prod in dev, qa, stg, prod (external
> communication issue or firewall problem)
> Due to the nature of our Traditional Business, instances of beans are
> created only under certain circumstances and cannot be injected in other
> environments.
>
> After all, the best way to do this is to treat it the same as the method of
> the spring framework.
> When injecting another spring bean in ComputeTask,  we could write it just
> like @AutoWired (required = false).
> I did not want to see the non-operation of the daemon because of a runtime
> exception due to a firewall problem.
> So, I thought “required = false” is required @SpringResource.
> Hope to hear your opinion on this.
> Once, again, I would like to apologize that I did not aware of the ignite
> process.
>
>
>
> I also have another question. I heard that there is an issue with
> configuration on the mailing list.
> How deploy node with different env, do you use it as below?
>
> In the java code,
> try (Ignite ignite = Ignition.start("/config/ignite.xml")) { // deault
> zone
> try (Ignite ignite = Ignition.start("/config/ignite-dev.xml")) { // dev?
> try (Ignite ignite = Ignition.start("/config/ignite-qa.xml")) { // qa?
> try (Ignite ignite = Ignition.start("/config/ignite-stg.xml")) { // stg??
>
> It will be a more user friendly settling by using yaml. Our project has
> over 300 properties
> If yaml is supported by ignite, it would be much more convenience. (If you
> do not have a plan to support spring-boot)
> I used ignite-default.yml, ignite-dev.yml, etc in my project. By
> distinguishing java -D options, codes are not revised and I only read
> configuration.
>
>
>
> I think there's a mistype in the document of the link below.
> It is the example of SqlFieldsQuery.
> https://apacheignite-sql.readme.io/docs/java-sql-api
> try (QueryCursor <List <? >> cursor = cache.query (sql) {
>
> I think there should be one more ')' as below.
> = cache.query (sql))  {
>
> I'll try to read the contribute documentation to fix this issue.
> It's better if you fix it.
> Ignite is really cool, you guys are really great.
>



-- 
Best regards,
Ilya