Hi Val,
Possibly, but the core difficulty there is knowing when the fan-out to
listeners has been completed. Before you know it you have
re-implemented Kafka! :)
I think we can leverage our use case knowledge to convert the messaging
style of notifications to a compute style broadcast against a compute
projection using an attribute based selection for nodes that want to be
listeners for the events. The messaging rate is relatively low (a few
messages a second) so this should be pretty workable.
Raymond.
On Thu, Sep 17, 2020 at 3:27 AM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
Hi Raymond,
Do you think you could use services for your use case?
https://apacheignite.readme.io/docs/service-grid
-Val
On Tue, Sep 15, 2020 at 4:32 PM Raymond Wilson <
raymond_wil...@trimble.com
wrote:
For what it is worth, we use messaging in Ignite to provide grid
notifications for various purposes. These might stimulate compute
operations in the message recipients, but they don't represent compute.
If messaging is removed, how would Ignite provide the ability for a
node
to
listen to events without the event sender being explicitly aware that
the
listener does, or should, exist, to produce a compute projection to
send
messages-as-compute-requests to?
On Wed, Sep 16, 2020 at 9:28 AM Kseniya Romanova <
romanova.ks....@gmail.com>
wrote:
Just wanted to submit a link to the video about some offered changes.
@valentin.kuliche...@gmail.com <valentin.kuliche...@gmail.com>
please
add
it to the wiki page. I created timestamps in the description, so one
can
browse the presentation fast or link the particular section:
https://youtu.be/zPuLJgUfLaM
Thanks a lot for the presentation!
вт, 18 авг. 2020 г. в 14:13, Ilya Kasnacheev <
ilya.kasnach...@gmail.com
:
Hello!
Maybe we can implement messaging via compute? Share underlying code
but
have a different API for convenience (maybe in extras).
Regards,
--
Ilya Kasnacheev
вт, 18 авг. 2020 г. в 11:59, Pavel Tupitsyn <ptupit...@apache.org
:
Val,
Is see the ".NET Modernization for Ignite 3.0" item in the
roadmap,
but
it
doesn't provide much detail. What are the actual changes in
.NET
that
you
propose for 3.0?
I've updated the roadmap with a brief description.
We want to move away from an old, long unsupported .NET version,
and remove integrations with legacy technologies (old ASP.NET
and
EF).
As for the messaging, so far I haven't seen use cases that
would
require
this API. Sometimes users attempt to use it for remote code
invocation,
but
compute is usually a better option for this. Do you have any
examples
where
messaging is a better fit then compute?
I guess you are right, Compute can replace Messaging in most
scenarios.
Messaging can be more convenient, since it is pub-sub -
subscriber
controls
whether it receives messages on the given topic. But this can be
achieved
with a little more work with Compute as well.
Thanks,
Pavel
On Tue, Aug 18, 2020 at 3:16 AM Saikat Maitra <
saikat.mai...@gmail.com
wrote:
Hi Pavel,
Awesome, thank you.
Yes, I remember having .Net modernization as part of Apache
Ignite
3.0
roadmap.
Regards,
Saikat
On Sun, Aug 16, 2020 at 11:04 AM Pavel Tupitsyn <
ptupit...@apache.org>
wrote:
Saikat, yes, most definitely.
This is mentioned in the wishlist under ".NET: Target .NET
Standard
2.0,
discontinue .NET 4.0 support".
I'm already working towards this goal by making more code and
tests
work
properly under .NET Core,
so when the time for breaking changes comes, it will be
simpler.
On Sat, Aug 15, 2020 at 10:06 PM Saikat Maitra <
saikat.mai...@gmail.com>
wrote:
Hi Val,
Thank you for adding the Cleanup section and Removals list.
Pavel, As part of Apache Ignite Roadmap we had mentioned we
will
add
modernization of .NET. Are we still targeting it in Apache
Ignite
3.0
release?
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Roadmap
Regards,
Saikat
On Fri, Aug 14, 2020 at 10:04 AM Carbone, Adam <
adam.carb...@bottomline.com>
wrote:
If you want to make is simpler to have the components
that
you
want,
but
have that be immutable at install time you could take an
approach
similar
to the way spring does it with their initializer (
https://start.spring.io/ ) as an example... Basically
the
concept
being
something that produces a set of configurations that are
used
to
define
what the environment looks like ( these could be k8s
objects
)
they
could
be spring-configuration objects? They could be something
that
you
develop
all upon ignite ( probably wouldn’t recommend this
approach )
there
seems
to be plenty of these types of things already
Example
* https://spring.io/guides/gs/centralized-configuration
*
https://cocoon.apache.org/subprojects/configuration/spring-configurator/index.html
And I'm by no means saying to use spring these are just
examples
that I
came across
I'm thinking the outcome needs to be a platform config of
source
(
that
can be checked in for those doing gitops ) and maybe ends
up
as a
config
map for those doing k8s, and some other fashion for those
doing
something
else.
Honestly I am not deep enough into the internals of
ignite
to
know
how
this might work for the platform, was more describing
what
I'm
seeing
from
a bigger picture trend
Regards
Adam Carbone | Director of Innovation – Intelligent
Platform
Team |
Bottomline Technologies
Office: 603-501-6446 | Mobile: 603-570-8418
www.bottomline.com
On 8/13/20, 7:55 PM, "Valentin Kulichenko" <
valentin.kuliche...@gmail.com>
wrote:
Hi Ilya,
Can you please describe your vision of how it should
work?
Let's say, I want to set up a cluster of several
standalone
server
nodes
with a couple of optional modules enabled. What are
my
steps?
-Val
On Thu, Aug 13, 2020 at 6:03 AM Carbone, Adam <
adam.carb...@bottomline.com>
wrote:
> Good Morning from the EastCoast
>
> I have to agree that the larger industry is tending
towards
immutability,
> and that you build once and test, then you
promote/migrate
that
immutable
> binary object, be is a library or a docker image
etc...
however
there are
> still patterns that allow you to determine at
install/or
deployment
time (
> helm as an example, you choose based on your values
what
the
package
> installs/provides ) It just isn't decided at
runtime
but
install
and
often
> in a gitops type world that is determined by
configuration
as
code.
I think
> run time is difficult to manage especially in our
increasingly
> containerized world.
>
> Regards.
>
> Adam Carbone | Director of Innovation – Intelligent
Platform
Team |
> Bottomline Technologies
> Office: 603-501-6446 | Mobile: 603-570-8418
> www.bottomline.com
>
>
>
> On 8/13/20, 8:01 AM, "Ilya Kasnacheev" <
ilya.kasnach...@gmail.com>
wrote:
>
> Hello!
>
> On the contrary, I would suggest that apache2
way
was
outdated
even at
> times when apache was all rage.
>
> Now the nginx approach is prevalent: on devops
phase,
assemble
a
custom
> bundle with all plugins included, store it
somewhere,
and
ship
it to
> production as a whole to remove any on-the-fly
uncertainty
from
> production.
>
> This is what docker does, but also maven, which
downloads
dependencies
> during build. You do not need to download
anything
in
runtime,
except
> for
> experimental deployments. You need to be all
set
before
runtime
starts.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 12 авг. 2020 г. в 09:48, Petr Ivanov <
mr.wei...@gmail.com
:
>
> > Hi, Val.
> >
> > > On 12 Aug 2020, at 01:31, Valentin
Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> > >
> > > Hi Petr,
> > >
> > > I agree -- we should better modularize the
platform.
The
current
> way if
> > very error-prone, especially during upgrades
--
any
changes
made
> within
> > IGNITE_HOME (configs, scripts, modules, etc.)
must
be
merged
with a
> new
> > version of the package. There is no standard
way
of
doing
this.
> > >
> > > However, I'm a bit concerned with your
suggestion
regarding
custom
> > dependency management. Can you please
elaborate
on
how
you
think it
> should
> > work? Are there tools we can reuse for this
purpose?
I
would
try to
> avoid
> > reinventing the wheel.
> >
> > I see it as a a2enmod | 2dismod analog of
Apache2.
> >
> > We build and store Apache Ignite and its
modules
as
separate
binaries
> > (binary per module) then use custom script
that
will
know
where to
> download
> > necessary module. Or possibly use modified
ignite.sh
to
specify
> required
> > optional libs in run command while ignite.sh
will
download
everything
> > missing from known storage.
> >
> > The whole idea is in storing everything
remotely
and
download
on
> demand,
> > not have all libs locally from the start.
> >
> >
> > >
> > > -Val
> > >
> > > On Sun, Aug 9, 2020 at 11:25 PM Petr
Ivanov <
mr.wei...@gmail.com
> > <mailto:mr.wei...@gmail.com>> wrote:
> > > Hi, Val!
> > > Thanks for your efforts on this endeavour!
> > >
> > >
> > > I would like to suggest deliveries changes
in
Apache
Ignite
3.0:
> > > — modularised binary delivery — single
minimal
binary
for
> starting
> > Ignite and all other modules and parts of the
project
(benchmarks,
> > examples, etc.) packed in their own binary
which
can
be
added
via
> custom
> > dependency management tool (i.e. modules.sh)
> > > — same distribution for RPM and DEB
packages
but
with
modules
> packed as
> > separate ones (PHP for example)
> > > — separate thin client release cycle with
custom
versioning
> > > Possibly, we can we add additional section
to
the
document
you
> > introduced for this part.
> > >
> > > Also, it seems that full JDK11 support
(including
building)
would
> be a
> > huge milestone and a sign of healthy modern
project
that
tends
to be
> on the
> > verge of mainstream technologies and not the
stockpile
of
legacy
> leftovers
> > (fully support Iliya in removing all that was
deprecated
and/or
> marked as
> > unused anymore).
> > >
> > >
> > > > On 8 Aug 2020, at 02:00, Valentin
Kulichenko
<
> > valentin.kuliche...@gmail.com <mailto:
valentin.kuliche...@gmail.com
> >>
> > wrote:
> > > >
> > > > Igniters,
> > > >
> > > > I've created the page:
> > > >
>
https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> <
> >
>
https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> >
> > > >
> > > > That's not everything I have in mind,
but I
believe
there
is
> already a
> > lot
> > > > to talk about :)
> > > >
> > > > Please take a look let me know if you
have
any
concerns,
> objections, or
> > > > questions. Once we reach the consensus on
the
proposed
changes,
> I will
> > > > start creating tickets in Jira and a more
detailed
plan.
> > > >
> > > > -Val
> > > >
> > > > On Thu, Aug 6, 2020 at 6:28 PM Saikat
Maitra
<
> saikat.mai...@gmail.com
> > <mailto:saikat.mai...@gmail.com>>
> > > > wrote:
> > > >
> > > >> Hi Denis, Val
> > > >>
> > > >> Thank you for your reply and really
appreciate
it.
It
will be
> very
> > cool to
> > > >> be able to connect and plan release
together
and
learn
more
> about
> > Ignite in
> > > >> the process :)
> > > >>
> > > >> Regards
> > > >> Saikat
> > > >>
> > > >>
> > > >>
> > > >> On Thu, Aug 6, 2020 at 7:12 PM Valentin
Kulichenko <
> > > >> valentin.kuliche...@gmail.com <mailto:
> valentin.kuliche...@gmail.com>>
> > wrote:
> > > >>
> > > >>> Hi Saikat,
> > > >>>
> > > >>> That surely is a great idea. We will
work
together
with
Denis
> on
> > setting
> > > >>> this up in the nearest future.
> > > >>>
> > > >>> -Val
> > > >>>
> > > >>> On Thu, Aug 6, 2020 at 10:21 AM Denis
Magda <
dma...@apache.org
> > <mailto:dma...@apache.org>> wrote:
> > > >>>
> > > >>>> Saikat,
> > > >>>>
> > > >>>> Fully support your idea on a virtual
meetup!
Once
Val
> collects and
> > > >>> outlines
> > > >>>> the main changes with directions on
wiki,
we’ll
go
ahead and
> > schedule
> > > >> the
> > > >>>> meetup to talk things out in a bit
more
detail.
We’ll
use our
> new
> > > >> Virtual
> > > >>>> Ignite Meetup group for that inviting
both
Ignite
> contributors and
> > > >>>> application developers.
> > > >>>>
> > > >>>> Denis
> > > >>>>
> > > >>>> On Thursday, August 6, 2020, Saikat
Maitra <
> saikat.mai...@gmail.com
> > <mailto:saikat.mai...@gmail.com>>
> > > >>>> wrote:
> > > >>>>
> > > >>>>> Hi Valentin
> > > >>>>>
> > > >>>>> Thank you for sharing and starting
the
thread.
I
am
thinking
> if it
> > > >> will
> > > >>>> be
> > > >>>>> a good idea to have a virtual meet
setup
to
discuss
on
the
> release
> > > >>>>> planning.
> > > >>>>>
> > > >>>>> It will help to learn more individual
features
to
be
added
> and also
> > > >> to
> > > >>>>> understand about features that have
been
deprecated
and
> scheduled
> > for
> > > >>>>> removal in Ignite 3.0 release. Also
it
will
help
community
> member
> > to
> > > >>>>> connect in real time and ask
questions
and
share
feedback.
> > > >>>>>
> > > >>>>> Regards,
> > > >>>>> Saikat
> > > >>>>>
> > > >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya
Kasnacheev
<
> > > >>>> ilya.kasnach...@gmail.com <mailto:
ilya.kasnach...@gmail.com>>
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>>> Hello!
> > > >>>>>>
> > > >>>>>> I hope to see Apache Ignite release
3.0
as
API
trimming
> release.
> > > >> Let
> > > >>> us
> > > >>>>>> correct external and internal APIs
for
which
we
have
better
> ideas
> > > >>> now,
> > > >>>> as
> > > >>>>>> well as remove old and deprecated
code.
> > > >>>>>>
> > > >>>>>> We may also introduce new
configuration
mechanisms
and
> user-facing
> > > >>> API
> > > >>>>>> (such as cache-less native SQL
queries),
but
this
we
could
> > > >> prototype
> > > >>>>> before
> > > >>>>>> starting the 3.0 task.
> > > >>>>>>
> > > >>>>>> I will advise against targeting
large
new
features
at
3.0.
> They
> > can
> > > >>> be
> > > >>>>>> added in subsequent point releases,
whereas
we
can't
really
> remove
> > > >> or
> > > >>>>>> remodel stuff in point releases.
> > > >>>>>>
> > > >>>>>> Regards,
> > > >>>>>> --
> > > >>>>>> Ilya Kasnacheev
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin
Kulichenko
<
> > > >>>>>> valentin.kuliche...@gmail.com
<mailto:
> > valentin.kuliche...@gmail.com>>:
> > > >>>>>>
> > > >>>>>>> Igniters,
> > > >>>>>>>
> > > >>>>>>> I would like to kick off a
discussion
regarding
Ignite 3.0.
> > > >> Ignite
> > > >>>> 2.0
> > > >>>>>>> exists for more than 3 years now
and
we've
already
> collected a
> > > >>>>>> significant
> > > >>>>>>> list [1] of changes that we would
like
to
have,
but
cannot
> > > >>> implement
> > > >>>>>>> without breaking compatibility.
> > > >>>>>>>
> > > >>>>>>> I think it's time to start planning
for
the
next
major
> release
> > > >> and
> > > >>>>>>> discussing what should be included.
I've
already
gathered
> some
> > > >>>>>> information
> > > >>>>>>> and feedback, and have some
thoughts
on
how
to
approach
> this. In
> > > >>> the
> > > >>>>> next
> > > >>>>>>> few days, I will put everything
into
a
Wiki
page
and
will
> share
> > > >> it
> > > >>>> once
> > > >>>>>>> this is done. Stay tuned!
> > > >>>>>>>
> > > >>>>>>> I'm willing to drive the 3.0
activities
going
forward as
> well.
> > > >>>>>>>
> > > >>>>>>> In the meantime, if there are any
immediate
thoughts
or
> ideas,
> > > >>> please
> > > >>>>>> feel
> > > >>>>>>> free to join the thread and share
them.
> > > >>>>>>>
> > > >>>>>>> [1]
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>
>
https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> <
> >
>
https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> >
> > > >>>>> Apache+Ignite+3.0+Wishlist
> > > >>>>>>>
> > > >>>>>>> Regards,
> > > >>>>>>> Val
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> -
> > > >>>> Denis
> > > >>>>
> > > >>>
> > > >>
> > >
> >
> >
>
>
>
--
<http://www.trimble.com/>
Raymond Wilson
Solution Architect, Civil Construction Software Systems (CCSS)
11 Birmingham Drive | Christchurch, New Zealand
+64-21-2013317 Mobile
raymond_wil...@trimble.com
<
https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch
--
<http://www.trimble.com/>
Raymond Wilson
Solution Architect, Civil Construction Software Systems (CCSS)
11 Birmingham Drive | Christchurch, New Zealand
+64-21-2013317 Mobile
raymond_wil...@trimble.com
<
https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch
