Hi
I have raised a tiny PR to upgrade flink version to latest stable release.
Jira : https://issues.apache.org/jira/browse/IGNITE-12517
PR https://github.com/apache/ignite-extensions/pull/3
Please review and provide approval.
Regards,
Saikat
Saikat Maitra created IGNITE-12517:
--
Summary: Upgrade flink module version to 1.9.1 in ignite-extensions
Key: IGNITE-12517
URL: https://issues.apache.org/jira/browse/IGNITE-12517
Project: Ignite
Kseniya, Nacho
Thank you for sharing the wallpapers. They are very cool.
IMO, we can add it in project website.
Also, I have a query regarding Apache lgnite logo that can be used for
external presentation.
Can we add this also in Apache Ignite project website?
http://apache.org/logos/#ignite
Hi,
I have raised a PR for removal of flink module from ignite main repo. I
have already moved flink module in ignite-extensions repo (
https://github.com/apache/ignite-extensions).
PR https://github.com/apache/ignite/pull/7222
jira : IGNITE-12356 Migrate Flink module to ignite-extensions
Hi Ivan,
Yes, we will need to remove flink module from main ignite repo.
I can do it as part of this issue.
IGNITE-12356 Migrate Flink module to ignite-extensions
Regards,
Saikat
On Mon, Dec 30, 2019 at 12:54 AM Ivan Pavlukhin wrote:
> Folks,
>
> Do not we need to remove flink integration
Hi Igniters!
Here [1] you can find wallpapers and add some blaze to your desktop or
mobile!
As they can be used in any month, probably I shall upload them to ignite
wiki or to the project website? Please suggest what will be appropriate.
Me and GG designer Nacho wish you happy holidays and a
Anton,
> Since this fix made to speedup pme-free switch which prohibits the merges...
Sounds as a bit of knowledge that I missed. Good to understand it now.
> The "magic numbers" are always the "magic numbers" :)
> We must get rid of them to see problems covered by them.
Let's try =)
чт, 26
Denis Chudov created IGNITE-12516:
-
Summary: Dump active transaction from near node does not work if
transaction not follow first
Key: IGNITE-12516
URL: https://issues.apache.org/jira/browse/IGNITE-12516
My humble opinion here is that we should strive for one and only
dialect. I understand concerns about supporting a backward compatible
dialect. But I personally do not know whether it is practical with
Calcite. Regarding multiples dialects my forecast is that supporting
multiple dialects close by
Hello!
I think we may eventually need at least two dialects.
One is "H2 compatible" for users migrating from older versions of AI. We
may need to add a few tweaks there to make most of existing SQL code work.
Other is "modern" in which we will remove these tweaks to get the best,
vanilla
Ivan Bessonov created IGNITE-12515:
--
Summary: GridMultinodeRedeploySharedModeSelfTest.testSharedMode
fails sometimes
Key: IGNITE-12515
URL: https://issues.apache.org/jira/browse/IGNITE-12515
Ivan Bessonov created IGNITE-12514:
--
Summary: WAL don't flush several last records in LOG-ONLY/FSYNC
mode if flush ptr=null
Key: IGNITE-12514
URL: https://issues.apache.org/jira/browse/IGNITE-12514
Andrey Mashenkov created IGNITE-12513:
-
Summary: SQL: Improve QueryEntity field conflict message.
Key: IGNITE-12513
URL: https://issues.apache.org/jira/browse/IGNITE-12513
Project: Ignite
Andrey Mashenkov created IGNITE-12512:
-
Summary: SQL: Compact logs for cancelled queries.
Key: IGNITE-12512
URL: https://issues.apache.org/jira/browse/IGNITE-12512
Project: Ignite
Issue
Hello!
I have checked that on master, and fallback to old behavior does not seem
to work for pre-existing clusters:
I am starting a cluster with two nodes with pre-existing PDS, and when I
start client, which would do setBaselineTopology, I get:
Caused by:
Agree, sounds like a plan, thanks for taking over!
пн, 30 дек. 2019 г. в 13:00, Vyacheslav Daradur :
> Alexey,
>
> I would not make it default in the current implementation.
>
> Waiting of proxies on non-deployment-initiator nodes should be
> improved - additional checks are required:
> 1) We
Alexey,
I would not make it default in the current implementation.
Waiting of proxies on non-deployment-initiator nodes should be
improved - additional checks are required:
1) We should not wait if requested service has not been submitted to
deploy (when there is no info about such service)
2)
Andrey Mashenkov created IGNITE-12511:
-
Summary: Fix misleading javadoc.
Key: IGNITE-12511
URL: https://issues.apache.org/jira/browse/IGNITE-12511
Project: Ignite
Issue Type: Task
Vyacheslav, thanks for the explanation, makes sense to me.
I was thinking though, should we make the behavior with the timeout default
for all proxies?
Just my opinion - I think for a user it would be hard to control which node
deploys the service, especially if multiple nodes deploy it
19 matches
Mail list logo
