ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@apache.org>
Subject Re: I am sorry for causing confusion. IGNITE-6531
Date Tue, 29 May 2018 17:10:13 GMT
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 <ilantukh@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 <joungdal.nam@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message