Re: Ignite 2.8 Release: Time & Scope & Release manager

[Denis Magda]

2.7.3 sounds reasonable to me, like the idea. Who'll kick off the release
procedures and lead it?

-
Denis


On Mon, Mar 18, 2019 at 5:05 AM Anton Vinogradov  wrote:

> As far as I remember that's not the first time we choose X.Y instead of
> X.Y.Z, because of ...
> So, seems we have to choose it now.
>
> >> Anton or Nikolay, would you like to be a release manager for 2.7.1?
> I can assist or perform the technical part of the release.
>
> >> Also, I can suggest 2.7.3 release as first Ignite maintenance release
> Agree
>
> On Mon, Mar 18, 2019 at 1:53 PM Dmitriy Pavlov  wrote:
>
> > Anton, thanks for checking compatibility.
> >
> > Anton or Nikolay, would you like to be a release manager for 2.7.1 ?
> >
> > 1) Ticket version update happens from time to time, it is a mass update
> in
> > JIRA - 1 operation. Actually, we have tradition noticed by Alex G:
> >
> > even-numbered minor release all were emergency-styled: 2.2, 2.4, 2.6, and
> > why not 2.8?
> >
> > 2) If we select 2.7.1: one major problem can occur - it is artifacts
> > versions clash for another company (and probably a lot of users
> involved),
> > because there is ignite-core 2.7.1. issued from Ignite fork. This issue
> is
> > now solved, so 2.8.1/2.9.1. can be created later without any risk
> >
> > 3) Also, I can suggest 2.7.3 release as first Ignite maintenance release
> -
> > cause there is no risk of clash here, as well. Otherwise, we need to
> select
> > between one company's internal links update vs another company's artifact
> > clash.
> >
> > Here I feel 2.7.1 is more natural, but it is safer to keep the process as
> > is, for at least, this release.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > пн, 18 мар. 2019 г. в 11:53, Nikolay Izhikov :
> >
> > > +1 to 2.7.1 version.
> > >
> > > I think it's time to learn to do minor releases.
> > >
> > > пн, 18 мар. 2019 г. в 11:51, Anton Vinogradov :
> > >
> > > > The major objection is to release 2.7.1 as 2.8.
> > > >
> > > > 1) A lot of people fixed issues at master with version 2.8.
> > > > So, they and their companies/customers (who used Ignite) waits for
> 2.8
> > > > because of fixes.
> > > > At least my company waits for fixes at 2.8.
> > > > It will be a real problem to update all private links for 2.9 to wait
> > for
> > > > another release.
> > > > "You told me you fixed this at 2.8, ... lair", that what I expect.
> > > >
> > > > 2) You'll have to update 1000+ issues to have 2.9 as the fixed
> version.
> > > > This will look odd to contributors.
> > > >
> > > > 3) I do not see any problems to release AI as 2.7.1.
> > > > I checked that assembly and release procedure have no issues with
> this
> > > > version.
> > > >
> > > > P.s. I'm ready to assist or to release AI as 2.7.1 in case someone
> > > doubts.
> > > >
> > > > On Fri, Mar 15, 2019 at 11:52 PM Denis Magda 
> > wrote:
> > > >
> > > > > Dmitriy,
> > > > >
> > > > > Thanks for putting this together and sharing the results of our
> > > > > conversation in a smaller group. Igniters, if there are no major
> > > > objections
> > > > > I would suggest us kicking off release related procedures early
> next
> > > > week.
> > > > >
> > > > > -
> > > > > Denis
> > > > >
> > > > >
> > > > > On Fri, Mar 15, 2019 at 6:05 AM Dmitriy Pavlov  >
> > > > wrote:
> > > > >
> > > > > > Hi everybody,
> > > > > >
> > > > > > I had a private talk with Denis, Vladimir, and Alex G. As far I
> > > > > understood
> > > > > > the problem with the master based release is not only 2 or more
> > > faulty
> > > > > > commits, but 1040 commits we have since 2.7. All of these commits
> > > need
> > > > to
> > > > > > be tested (unfortunately not all QA steps are visible to the
> > > > community),
> > > > > > and this will require the most amount of time. Reverting and
> > > disabling
> > > > a
> > > > > > couple of features is possible, but other commits may impact
> users.
> > > > > >
> > > > > > You can find a complete list here
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://docs.google.com/spreadsheets/d/1XJAsPEhYLcudVK4kdd6ZDoFZ6dnbAokgdJUDjWVZsKM/edit#gid=1445866798
> > > > > >
> > > > > > And estimation of commits related to Java 11 (plus commits fixing
> > > > native
> > > > > > persistence critical problems) is less than 50.
> > > > > >
> > > > > > So to get faster release we may use branch ignite-2.7 + fixes. I
> > > > suggest
> > > > > > naming release as 2.8 and next 2.9 (cause 2.8 now and 2.8.1 as
> > master
> > > > > based
> > > > > > is counter-intuitive).
> > > > > >
> > > > > > 2.7.1, for now, is not an option because
> > > > > >  A. we never did it before, and Java 11 fixes are urgent. A new
> > > > > > experimental release may delay us, as well.
> > > > > >  B. in this case we don't need 2.7.2 because there is almost no
> > risk
> > > > that
> > > > > > additional changes will be necessary.
> > > > > > we can schedule 2.9.1 with fixes may be necessary after new cool
> > > > release
> > > > > > after 1.5 months.
> > > > > >
> > > > > 

[jira] [Created] (IGNITE-11576) Web console: Documentation for webconsole upgraging from version to vertion should be created (including mongoDB specific)

[Andrey Aleksandrov (JIRA)]

Andrey Aleksandrov created IGNITE-11576:
---

 Summary: Web console: Documentation for webconsole upgraging from 
version to vertion should be created (including mongoDB specific)
 Key: IGNITE-11576
 URL: https://issues.apache.org/jira/browse/IGNITE-11576
 Project: Ignite
  Issue Type: Task
  Components: UI
Affects Versions: 2.7
Reporter: Andrey Aleksandrov
 Fix For: 2.8


It's important to get the documentation about all steps and limitation related 
to upgrading of the web console.

Also in case if upgrading requires changing of the mongoDB version then the 
instructions for backuping and restoring of the data should be added to our 
documentation too.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11575) Make UriDeploymentSpi ignore archives with untrusted signature

[Denis Mekhanikov (JIRA)]

Denis Mekhanikov created IGNITE-11575:
-

 Summary: Make UriDeploymentSpi ignore archives with untrusted 
signature
 Key: IGNITE-11575
 URL: https://issues.apache.org/jira/browse/IGNITE-11575
 Project: Ignite
  Issue Type: Improvement
Reporter: Denis Mekhanikov


{{UriDeploymentSpi}} checks whether a loaded JAR/GAR file has a correct 
signature. But there is no way to specify the expected public key. So, it's 
possible to perform a "man-in-the-middle" attack by amending an archive being 
transferred from a remote storage to an Ignite node.
It's even possible just to remove the signature, and a completely unsigned file 
will be processed without errors.

There should be a way to specify an expected public key, that should be used 
while signing archives.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11574) Exchange on NodeLeft event hangs when cluster is in transition state

[Ivan Bessonov (JIRA)]

Ivan Bessonov created IGNITE-11574:
--

 Summary: Exchange on NodeLeft event hangs when cluster is in 
transition state
 Key: IGNITE-11574
 URL: https://issues.apache.org/jira/browse/IGNITE-11574
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Bessonov
Assignee: Ivan Bessonov
 Attachments: ExchangeDeadlockTest.java

The problem is in this code (GridCachePartitionExchangeManager#start0) :
{code:java}
if (cache.state().transition()) {
if (log.isDebugEnabled())
log.debug("Adding pending event: " + evt);

pendingEvts.add(new PendingDiscoveryEvent(evt, cache));
}{code}
Problem occurs when "setBaseline" and "nodeLeft" events happen simultaneously 
(+ some undetermined conditions).

"nodeLeft" provokes exchange, and while that exchange isn't finished 
"setBaseline" is invoked. This moves cluster into a transition state and 
"CacheAffinityChangeMessage" from the exchange cannot be processed properly. At 
the same time "setBaseline" cannot be completed before the exchange, so we have 
a deadlock.

Reproducer attached.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11573) Incompatible baseline topology triggers failure handler

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-11573:
-

 Summary: Incompatible baseline topology triggers failure handler
 Key: IGNITE-11573
 URL: https://issues.apache.org/jira/browse/IGNITE-11573
 Project: Ignite
  Issue Type: Bug
Reporter: Alexey Goncharuk


See logs in {{testNodeFailsToJoinWithIncompatiblePreviousBaselineTopology}}: 
the SPI throws a valid exception, but together with throwing the exception to 
user we trigger failure handler.

Given that the exception is valid, failure handler should not be triggered.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11572) Node restart in ignite.sh was broken by IGNITE-11216

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-11572:
-

 Summary: Node restart in ignite.sh was broken by IGNITE-11216
 Key: IGNITE-11572
 URL: https://issues.apache.org/jira/browse/IGNITE-11572
 Project: Ignite
  Issue Type: Bug
Reporter: Alexey Goncharuk






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11571) Ignored critical failure

[Ryabov Dmitrii (JIRA)]

Ryabov Dmitrii created IGNITE-11571:
---

 Summary: Ignored critical failure
 Key: IGNITE-11571
 URL: https://issues.apache.org/jira/browse/IGNITE-11571
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Ryabov Dmitrii


Critical failure in 
{{TcpCommunicationSpiFaultyClientTest#testNotAcceptedConnection()}} is ignored 
because of no-op failure handler.


{code:java}
[2019-03-19 15:09:18,970][WARN 
][disco-event-worker-#237%tcp.TcpCommunicationSpiFaultyClientTest0%][GridDiscoveryManager]
 Node FAILED: TcpDiscoveryNode [id=2d7a1e30-585f-44af-88af-60065ca2, 
consistentId=2d7a1e30-585f-44af-88af-60065ca2, addrs=ArrayList [127.0.0.1], 
sockAddrs=HashSet [/127.0.0.1:0], discPort=0, order=3, intOrder=3, 
lastExchangeTime=1552997347220, loc=false, ver=2.7.0#20190319-sha1:, 
isClient=true]
[2019-03-19 15:09:18,972][WARN ][tcp-disco-msg-worker-[9f201bd5 
127.0.0.1:47500]-#36%tcp.TcpCommunicationSpiFaultyClientTest1%][TestTcpDiscoverySpi]
 Received EVT_NODE_FAILED event with warning [nodeInitiatedEvt=TcpDiscoveryNode 
[id=9f201bd5-f120-4365-8477-d9ff50e0, consistentId=127.0.0.1:47500, 
addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500], 
discPort=47500, order=1, intOrder=1, lastExchangeTime=1552997347060, loc=false, 
ver=2.7.0#20190319-sha1:, isClient=false], msg=TcpCommunicationSpi 
failed to establish connection to node [rmtNode=TcpDiscoveryNode 
[id=2d7a1e30-585f-44af-88af-60065ca2, 
consistentId=2d7a1e30-585f-44af-88af-60065ca2, addrs=ArrayList [127.0.0.1], 
sockAddrs=HashSet [/127.0.0.1:0], discPort=0, order=3, intOrder=3, 
lastExchangeTime=1552997347220, loc=false, ver=2.7.0#20190319-sha1:, 
isClient=true], errs=class o.a.i.IgniteCheckedException: Failed to connect to 
node (is node still alive?). Make sure that each ComputeTask and cache 
Transaction has a timeout set in order to prevent parties from waiting forever 
in case of network issues [nodeId=2d7a1e30-585f-44af-88af-60065ca2, 
addrs=[/127.0.0.1:47200]], connectErrs=[]]]
[2019-03-19 15:09:18,973][WARN 
][tcp-client-disco-msg-worker-#54%tcp.TcpCommunicationSpiFaultyClientTest3%][TestTcpDiscoverySpi]
 Received EVT_NODE_FAILED event with warning [nodeInitiatedEvt=TcpDiscoveryNode 
[id=9f201bd5-f120-4365-8477-d9ff50e0, consistentId=127.0.0.1:47500, 
addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500], 
discPort=47500, order=1, intOrder=1, lastExchangeTime=1552997347390, loc=false, 
ver=2.7.0#20190319-sha1:, isClient=false], msg=TcpCommunicationSpi 
failed to establish connection to node [rmtNode=TcpDiscoveryNode 
[id=2d7a1e30-585f-44af-88af-60065ca2, 
consistentId=2d7a1e30-585f-44af-88af-60065ca2, addrs=ArrayList [127.0.0.1], 
sockAddrs=HashSet [/127.0.0.1:0], discPort=0, order=3, intOrder=3, 
lastExchangeTime=1552997347220, loc=false, ver=2.7.0#20190319-sha1:, 
isClient=true], errs=class o.a.i.IgniteCheckedException: Failed to connect to 
node (is node still alive?). Make sure that each ComputeTask and cache 
Transaction has a timeout set in order to prevent parties from waiting forever 
in case of network issues [nodeId=2d7a1e30-585f-44af-88af-60065ca2, 
addrs=[/127.0.0.1:47200]], connectErrs=[]]]
[2019-03-19 15:09:18,975][WARN 
][disco-event-worker-#380%tcp.TcpCommunicationSpiFaultyClientTest3%][GridDiscoveryManager]
 Node FAILED: TcpDiscoveryNode [id=2d7a1e30-585f-44af-88af-60065ca2, 
consistentId=2d7a1e30-585f-44af-88af-60065ca2, addrs=ArrayList [127.0.0.1], 
sockAddrs=HashSet [/127.0.0.1:0], discPort=0, order=3, intOrder=3, 
lastExchangeTime=1552997347390, loc=false, ver=2.7.0#20190319-sha1:, 
isClient=true]
[2019-03-19 15:09:18,975][INFO 
][disco-event-worker-#380%tcp.TcpCommunicationSpiFaultyClientTest3%][GridDiscoveryManager]
 Topology snapshot [ver=5, locNode=0f4451ab, servers=2, clients=1, 
state=ACTIVE, CPUs=8, offheap=0.1GB, heap=3.5GB]
[2019-03-19 
15:09:18,969][ERROR][sys-#240%tcp.TcpCommunicationSpiFaultyClientTest0%][TcpCommunicationSpiFaultyClientTest$TestCommunicationSpi]
 Failed to send message to remote node [node=TcpDiscoveryNode 
[id=2d7a1e30-585f-44af-88af-60065ca2, 
consistentId=2d7a1e30-585f-44af-88af-60065ca2, addrs=ArrayList [127.0.0.1], 
sockAddrs=HashSet [/127.0.0.1:0], discPort=0, order=3, intOrder=3, 
lastExchangeTime=1552997347220, loc=false, ver=2.7.0#20190319-sha1:, 
isClient=true], msg=GridIoMessage [plc=2, topic=TOPIC_CACHE, topicOrd=8, 
ordered=false, timeout=0, skipOnTimeout=false, msg=GridDhtPartitionsFullMessage 
[parts=HashMap {-2100569601=GridDhtPartitionFullMap 
{9f201bd5-f120-4365-8477-d9ff50e0=GridDhtPartitionMap [moving=0, 
top=AffinityTopologyVersion [topVer=4, minorTopVer=1], updateSeq=12, size=100], 
7f025ffe-76b4-420e-b476-f6db8ff1=GridDhtPartitionMap [moving=0, 
top=AffinityTopologyVersion [topVer=4, minorTopVer=1], updateSeq

[jira] [Created] (IGNITE-11570) Change git URL in release scripts to gitbox

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-11570:
---

 Summary: Change git URL in release scripts to gitbox
 Key: IGNITE-11570
 URL: https://issues.apache.org/jira/browse/IGNITE-11570
 Project: Ignite
  Issue Type: Task
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11569) Enable baseline auto-adjust by default only for empty cluster

[Anton Kalashnikov (JIRA)]

Anton Kalashnikov created IGNITE-11569:
--

 Summary: Enable baseline auto-adjust by default only for empty 
cluster
 Key: IGNITE-11569
 URL: https://issues.apache.org/jira/browse/IGNITE-11569
 Project: Ignite
  Issue Type: Bug
Reporter: Anton Kalashnikov
Assignee: Anton Kalashnikov


It is required to enable baseline auto-adjust by default only for empty cluster



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11568) Change afterTest() annotation in TcpDiscoveryFailedJoinTest

[Ivan Fedotov (JIRA)]

Ivan Fedotov created IGNITE-11568:
-

 Summary: Change afterTest() annotation in 
TcpDiscoveryFailedJoinTest
 Key: IGNITE-11568
 URL: https://issues.apache.org/jira/browse/IGNITE-11568
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Fedotov
Assignee: Ivan Fedotov


afterTest() method in TcpDiscoveryFailedJoinTest is overridden and annotated by 
after. Meanwhile, it is under prohibition because afterTest will be executed 
before test  afterTest (see 

JUnit3TestLegacySupport and beforeTest/afterTest usage in GridAbstractTest).

 

So, it is necessary to change after annotation on override.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11567) runFailureDetectionOnReceiptError fail with SocketTimeoutException would be thrown.

[Stanilovsky Evgeny (JIRA)]

Stanilovsky Evgeny created IGNITE-11567:
---

 Summary: runFailureDetectionOnReceiptError fail with 
SocketTimeoutException would be thrown.
 Key: IGNITE-11567
 URL: https://issues.apache.org/jira/browse/IGNITE-11567
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.7
Reporter: Stanilovsky Evgeny
 Fix For: 2.8


after working under  [1] i found that if 
{code:java}SocketTimeoutException{code} would be thrown from readReceipt, test 
{code}org.apache.ignite.spi.discovery.tcp.TcpDiscoverySelfTest#runFailureDetectionOnReceiptError{code}
 will fail, i suppose it`s due to {code} 
org.apache.ignite.spi.discovery.tcp.ServerImpl#sendMessageDirectly
org.apache.ignite.spi.IgniteSpiOperationTimeoutHelper#checkFailureTimeoutReached
 {code} 
and 
{code}
if (X.hasCause(e, IgniteSpiOperationTimeoutException.class, 
SocketTimeoutException.class, SocketException.class))
return true;
{code} logic, need further alalysis.

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



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11566) JDBC Thin: add support for custom partitions count within the client side best effort affinity

[Alexander Lapin (JIRA)]

Alexander Lapin created IGNITE-11566:


 Summary: JDBC Thin: add support for custom partitions count within 
the client side best effort affinity
 Key: IGNITE-11566
 URL: https://issues.apache.org/jira/browse/IGNITE-11566
 Project: Ignite
  Issue Type: Task
  Components: jdbc
Reporter: Alexander Lapin






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11565) JDBC Thin: add connection resolution in case of multiple partitons

[Alexander Lapin (JIRA)]

Alexander Lapin created IGNITE-11565:


 Summary: JDBC Thin: add connection resolution in case of multiple 
partitons
 Key: IGNITE-11565
 URL: https://issues.apache.org/jira/browse/IGNITE-11565
 Project: Ignite
  Issue Type: Task
  Components: jdbc
Reporter: Alexander Lapin


At this moment, we only calculate target node id if there is none or single 
partitions. Implement node resolution logic for multiple partitions case. The 
basic idea is that we should use random node from one of presented in 
connections if it's derived from calculated partitions or totally random if 
there are no matches.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Review of IGNITE-11521

[Lukas Polacek]

Hi,
I've suggested an edit of the documentation at readme.io
 and updated the issue
 with a different
description. If you can think of other use-cases for this event, please let
me know.

On Wed, Mar 13, 2019 at 10:47 AM Yakov Zhdanov  wrote:

> I think there should be a link on the page - Suggest edits
>
> --Yakov
>

Re: Review IGNITE-11411 'Remove tearDown, setUp from JUnit3TestLegacySupport'

[Ivan Fedotov]

Hi Eduard.

Thank you for your participation in the review. In case of any questions
feel free to ask me.

вт, 19 мар. 2019 г. в 11:04, Eduard Shangareev :

> Hi.
>
> I am interested in. If nobody did it I would do it next week.
>
> On Tue, Mar 19, 2019 at 10:20 AM Ivan Fedotov  wrote:
>
> > Hi Igniters!
> >
> > Now I am working on iep-30[1] which is about fully 4->5 migration and
> > includes some moments according to JUnit 3->4 migration.
> > I am on the first stage and finishing ticket about removing tearDown,
> setUp
> > from JUnit3TestLegacySupport [2].
> >
> > In nutshell: I removed setUp, tearDown from JUnit3TestLegacySupport and
> > replaced them by beforeTest, afterTest in tests where they are used. That
> > brings us to the JUnit5 test scenario because setUp and tearDown are used
> > under Rule annotation in GridAbstractTest.
> >
> > Could somebody review this ticket, please?
> >
> > [1]
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5
> > [2] https://issues.apache.org/jira/browse/IGNITE-11411
> >
> > --
> > Ivan Fedotov.
> >
> > ivanan...@gmail.com
> >
>


-- 
Ivan Fedotov.

ivanan...@gmail.com

Re: Review IGNITE-11411 'Remove tearDown, setUp from JUnit3TestLegacySupport'

[Eduard Shangareev]

Hi.

I am interested in. If nobody did it I would do it next week.

On Tue, Mar 19, 2019 at 10:20 AM Ivan Fedotov  wrote:

> Hi Igniters!
>
> Now I am working on iep-30[1] which is about fully 4->5 migration and
> includes some moments according to JUnit 3->4 migration.
> I am on the first stage and finishing ticket about removing tearDown, setUp
> from JUnit3TestLegacySupport [2].
>
> In nutshell: I removed setUp, tearDown from JUnit3TestLegacySupport and
> replaced them by beforeTest, afterTest in tests where they are used. That
> brings us to the JUnit5 test scenario because setUp and tearDown are used
> under Rule annotation in GridAbstractTest.
>
> Could somebody review this ticket, please?
>
> [1]
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5
> [2] https://issues.apache.org/jira/browse/IGNITE-11411
>
> --
> Ivan Fedotov.
>
> ivanan...@gmail.com
>

Review IGNITE-11411 'Remove tearDown, setUp from JUnit3TestLegacySupport'

[Ivan Fedotov]

Hi Igniters!

Now I am working on iep-30[1] which is about fully 4->5 migration and
includes some moments according to JUnit 3->4 migration.
I am on the first stage and finishing ticket about removing tearDown, setUp
from JUnit3TestLegacySupport [2].

In nutshell: I removed setUp, tearDown from JUnit3TestLegacySupport and
replaced them by beforeTest, afterTest in tests where they are used. That
brings us to the JUnit5 test scenario because setUp and tearDown are used
under Rule annotation in GridAbstractTest.

Could somebody review this ticket, please?

[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5
[2] https://issues.apache.org/jira/browse/IGNITE-11411

-- 
Ivan Fedotov.

ivanan...@gmail.com

[jira] [Created] (IGNITE-11564) SQL: Implement KILL QUERY command

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-11564:


 Summary: SQL: Implement KILL QUERY command
 Key: IGNITE-11564
 URL: https://issues.apache.org/jira/browse/IGNITE-11564
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
 Fix For: 2.8


This is an umbrella ticket for {{KILL QUERY}} command implementation. Original 
description could be found in IGNITE-10161.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11563) DELETE WHERE does not work in prepared statements

[Stefan (JIRA)]

Stefan created IGNITE-11563:
---

 Summary: DELETE WHERE does not work in prepared statements
 Key: IGNITE-11563
 URL: https://issues.apache.org/jira/browse/IGNITE-11563
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.7
Reporter: Stefan


With SQL I cannot delete a row using a prepared statement. The following 
statement is simply ignored:
{{DELETE}} {{FROM}} {{AnyTable }}{{WHERE}} {{id = ?}}
This happens with JDBC-Thin and with ODBC so I suspect that the cluster gets 
the correct data but handles it wrong. By adding an always-true-condition it 
works as expected:
{{DELETE}} {{FROM}} {{AnyTable }}{{WHERE}} {{id = id }}{{AND}} {{id = ?}}
I tested with a very simple table that was created with:

{{CREATE TABLE testtable (}}
{{    "ID" NUMBER(19,0),}}
{{    "VALUE" VARCHAR2(255 CHAR),}}
{{    PRIMARY KEY (ID)}}
{{) WITH "template=replicated,cache_name=testtable"}} {{}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)