Re: Problem with reading incomplete payload - IGNITE-7153
I have not checked the exact routine, but you need to reexecute read until it
returns -1 or if known that all bytes that are expected have been read (if
sockCh is based on some kind of input stream)
> Am 26.10.2018 um 04:24 schrieb Michael Fong :
>
> Bump!
>
> Anyone who could help me solve this random issue? Thanks!
>
> Regards,
>
>
> Michael
>
>> On Wed, Oct 24, 2018 at 10:32 PM Michael Fong wrote:
>>
>> Hi, all,
>>
>>
>> I was trying to fix IGNITE-7153 which relates to parsing incomplete REDIS
>> packet larger than 8192 bytes. However, I found a random problem which is
>> reproducible on TC as well.
>> That said, GridNioServerRead.processRead() :
>> - int cnt = sockCh.read(readBuf);
>>
>> sometimes does not read the payload fully as the length field in the
>> header is larger than the ByteBuffer.limit(). As the result, the
>> BufferUnderFlowException will be thrown.
>>
>> For example, in a erroneous round run with my IDE, a REDIS payload (sent
>> by jedis client) looks like the following:
>>
>> 2a 33 d a 24 33 d a 53 45 54 d a 24 32 d a 62 31 d a 24 {38 31 39 32} d a |
>> 65
>> d a ...etc
>>
>> GridRedisProtocolParser.readBulkStr(buf) invokes elCnt(buf) which gets
>> {8192}. However, the limit of buf is 28 which ends at | position. Obviously,
>> 8192 < limit(), therefore, the logic throws BufferUnderFlow soon after.
>>
>> I traced back and found sockCh.read(readBuf) only read 28 bytes for unknown
>> reason
>>
>> The problem seems totally random. I wonder if this has anything to do with
>> other NioWorker
>> or Selector setting.
>>
>>
>> Any help would be appreciated!
>>
>>
>> Regards,
>>
>>
>> Michael
>>
>>
Re: Problem with reading incomplete payload - IGNITE-7153
Bump!
Anyone who could help me solve this random issue? Thanks!
Regards,
Michael
On Wed, Oct 24, 2018 at 10:32 PM Michael Fong wrote:
> Hi, all,
>
>
> I was trying to fix IGNITE-7153 which relates to parsing incomplete REDIS
> packet larger than 8192 bytes. However, I found a random problem which is
> reproducible on TC as well.
> That said, GridNioServerRead.processRead() :
> - int cnt = sockCh.read(readBuf);
>
> sometimes does not read the payload fully as the length field in the
> header is larger than the ByteBuffer.limit(). As the result, the
> BufferUnderFlowException will be thrown.
>
> For example, in a erroneous round run with my IDE, a REDIS payload (sent
> by jedis client) looks like the following:
>
> 2a 33 d a 24 33 d a 53 45 54 d a 24 32 d a 62 31 d a 24 {38 31 39 32} d a | 65
> d a ...etc
>
> GridRedisProtocolParser.readBulkStr(buf) invokes elCnt(buf) which gets
> {8192}. However, the limit of buf is 28 which ends at | position. Obviously,
> 8192 < limit(), therefore, the logic throws BufferUnderFlow soon after.
>
> I traced back and found sockCh.read(readBuf) only read 28 bytes for unknown
> reason
>
> The problem seems totally random. I wonder if this has anything to do with
> other NioWorker
> or Selector setting.
>
>
> Any help would be appreciated!
>
>
> Regards,
>
>
> Michael
>
>
Re: Code inspection
Igniters, The new `Inspections: Core` suite [2] configured on TeamCity (pass successfully with - Inspections total: 0, errors: 0 ). The next rules are enabled for this suite: - `Missorted modifiers`; - `'size() == 0' replaceable with 'isEmpty()'`; - `Add missing @Override annotation`; - `Fix unused imports`; Let's incule it to the `Run::All` group on TC, so we will check these rules automatically for each PR. Any objections? Talking about the details, - the issue [1] with adding an inspections configuration for TC have PA status; - the new configuration ignite_inspections_teamcity.xml added to PR; - four rules which are already fixed in the master branch enabled in config; - the `Inspections:Core` suite configured to use the inspections configuration from the local branch; - the example `how to use inspections from the command line` added. Petr, Nikolay, Thank you for your support! [1] https://issues.apache.org/jira/browse/IGNITE-9983 [2] https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore_IgniteTests24Java8=pull%2F5059%2Fhead=buildTypeStatusDiv [3] https://issues.apache.org/jira/browse/IGNITE-9983?focusedCommentId=16662323=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16662323 On Tue, 23 Oct 2018 at 19:16 Nikolay Izhikov wrote: > Hello, Maxim. > > +1 from me. > > I vote to enable static inspections for the Ignite codebase. > Thank you for that contributions! > > В Вт, 23/10/2018 в 19:09 +0300, Maxim Muzafarov пишет: > > Igniters, > > > > I've fixed some issues according to the inspections.xml configuration: > > - `Missorted modifiers`; > > - `'size() == 0' replaceable with 'isEmpty()'`; > > - `Add missing @Override annotation`; > > These one have `In progress` state: > > - `Fix unused imports`; > > - `Remove unnecessary @SuppressWarnings annotation`; > > > > The list of issues related to the current Code Inspections changes can be > > found [1] > > with using label `inspections`. So, to move forward and not lose current > > changes I > > propose to: > > - Create the new configuration idea\ignite_inspections_teamcity.xml (I > > will file a new issue for it); > > - Tune `Inspections: Core` Suite to use this configuration profile (It > > will run with each PR); > > - In the case with fixing a new inspection rule enable it this > inspection > > configuration. > > > > This will allow us to move forward in small steps and at some point of > time > > in future we will switch > > this ignite_inspections_teamcity.xml with the > > default ignite_inspections.xml. > > > > Thoughts? > > Pert Ivanov, will you help to tune `Inspections: Core` suite? > > > > [1] > > > https://issues.apache.org/jira/browse/IGNITE-9923?jql=project%20%3D%20Ignite%20AND%20labels%20%3D%20inspections > > > > On Sat, 25 Aug 2018 at 00:54 Dmitriy Pavlov > wrote: > > > > > IntelliJ Idea shows missing @Override annotation on my installation. > Not > > > sure it comes from our inspection or not. > > > > > > Anyway, count on me. > > > > > > пт, 24 авг. 2018 г. в 9:25, Maxim Muzafarov : > > > > > > > Folks, > > > > > > > > I think we can make a small step further with Ignite Inspections. > > > > > > > > I've created these tickets [1], [2] for myself according to > previously > > > > added > > > > `idea/ignite_inspections.xml` and I plan to complete them. > > > > > > > > Who will help me with review and merge? > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9311 - Add missing > > > > @Override annotation > > > > [2] https://issues.apache.org/jira/browse/IGNITE-9312 - Remove > > > > > > unnecessary > > > > @SuppressWarnings annotation > > > > > > > > On Thu, 16 Aug 2018 at 19:53 Dmitriy Pavlov > > > > > > wrote: > > > > > > > > > Hi Pavel, > > > > > > > > > > Thank you for noticing and bringing it here. I've fixed TC failure. > > > > > > > > > > Sincerely, > > > > > Dmitriy Pavlov > > > > > > > > > > чт, 16 авг. 2018 г. в 0:10, Pavel Pereslegin : > > > > > > > > > > > Hello Igniters. > > > > > > > > > > > > It seems that "idea/ignite_inspections.xml" should be excluded > from > > > > > > "check-licenses" maven profile, because "_Licenses Headers_" > > > > > > configuration always fails now [1] on TeamCity. > > > > > > > > > > > > [1] > > > > > > > > > > > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_LicensesHeaders=buildTypeHistoryList_IgniteTests24Java8=%3Cdefault%3E > > > > > > ср, 15 авг. 2018 г. в 20:49, Dmitriy Pavlov < > dpavlov@gmail.com>: > > > > > > > > > > > > > > I've updated wiki page > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-C.CodeInspection > > > > > > > with > > > > > > > reference to settings.xml placement in the project. > > > > > > > > > > > > > > It is only advice, so I hope you don't mind having this > reference. > > > > > > > > > > > > > > ср, 15 авг. 2018 г. в 16:45, Dmitriy Pavlov < > dpavlov@gmail.com > > > >
[jira] [Created] (IGNITE-10013) Node restart may lead to NPE in GridDhtPartitionsExchangeFuture
Sergey Kozlov created IGNITE-10013:
--
Summary: Node restart may lead to NPE in
GridDhtPartitionsExchangeFuture
Key: IGNITE-10013
URL: https://issues.apache.org/jira/browse/IGNITE-10013
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 2.7
Reporter: Sergey Kozlov
Fix For: 2.7
1. Start 4 nodes with ~100 caches, create a few dynamic caches
2. Load data (~500 entries per cache)
3. Restart every node starting from first
The first node may throw NPE:
{noformat}
[20:00:18,355][INFO][exchange-worker-#63][time] Started exchange init
[topVer=AffinityTopologyVersion [topVer=5, minorTopVer=0],
mvccCrd=MvccCoordinator [nodeId=c7a332ee-ee85-4604-aa93-919f15e34e36,
crdVer=1540497597005, topVer=AffinityTopologyVersion [topVer=1,
minorTopVer=0]], mvccCrdChange=false, crd=true, evt=NODE_JOINED,
evtNode=cc8ed618-2f14-46cf-be03-645291c397aa, customEvt=null, allowMerge=true]
[20:00:18,358][INFO][exchange-worker-#63][GridDhtPartitionsExchangeFuture]
Finish exchange future [startVer=AffinityTopologyVersion [topVer=5,
minorTopVer=0], resVer=AffinityTopologyVersion [topVer=5, minorTopVer=0],
err=null]
[20:00:18,364][SEVERE][sys-#77][GridCacheIoManager] Failed processing message
[senderId=c50165fb-1afd-4b3e-8fba-ac825aa532fa,
msg=GridDhtPartitionsSingleMessage [parts=HashMap
{-553318226=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=5, size=490],
-553318133=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=5, size=512],
-553318412=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=5, size=490],
-553315529=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=5, size=490],
-553315497=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=5, size=490],
-553315498=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=5, size=490],
-2100569601=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=5, size=100],
-553318319=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=5, size=512],
374280891=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion [topVer=4,
minorTopVer=1], updateSeq=5, size=32], 374280890=GridDhtPartitionMap [moving=0,
top=AffinityTopologyVersion [topVer=4, minorTopVer=1], updateSeq=5, size=64],
374280889=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion [topVer=4,
minorTopVer=1], updateSeq=5, size=128], 374280888=GridDhtPartitionMap
[moving=0, top=AffinityTopologyVersion [topVer=4, minorTopVer=1], updateSeq=5,
size=512], 374280887=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=5, size=23], 374280886=GridDhtPartitionMap
[moving=0, top=AffinityTopologyVersion [topVer=4, minorTopVer=1], updateSeq=5,
size=31], 374280885=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=5, size=61], 374280884=GridDhtPartitionMap
[moving=0, top=AffinityTopologyVersion [topVer=4, minorTopVer=1], updateSeq=5,
size=490], -553315527=GridDhtPartitionMap [moving=0,
top=AffinityTopologyVersion [topVer=4, minorTopVer=1], updateSeq=5, size=512],
-553315495=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=5, size=512],
-553315528=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=4, size=490],
-553315496=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=4, size=512],
-553315526=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=4, size=512]}, partCntrs=null,
partsSizes=HashMap {-553318226=HashMap {1=1, 2=1, 3=1, 4=1, 5=1, 6=1, 7=1, 9=1,
11=1, 13=1, 20=1, 21=1, 22=1, 24=1, 27=1, 28=1, 31=1, 32=1, 33=1, 34=1, 35=1,
36=1, 39=1, 42=1, 43=1, 47=1, 55=1, 57=1, 58=1, 63=1, 64=1, 65=1, 66=1, 67=1,
70=1, 71=1, 72=1, 73=1, 74=1, 75=1, 79=1, 80=1, 82=1, 84=1, 86=1, 88=1, 90=1,
95=1, 96=1, 99=1}, -553318133=HashMap {1=1, 2=1, 3=1, 4=1, 5=1, 6=1, 7=1, 8=1,
9=1, 10=1, 11=1, 12=1, 13=1, 14=1, 15=1, 16=1, 17=1, 18=1, 19=1, 20=1, 21=1,
22=1, 23=1, 24=1, 25=1, 26=1, 27=1, 28=1, 29=1, 30=1, 31=1, 32=1, 33=1, 34=1,
35=1, 36=1, 37=1, 38=1, 39=1, 40=1, 41=1, 42=1, 43=1, 44=1, 45=1, 46=1, 47=1,
48=1, 49=1, 50=1, 51=1, 52=1, 53=1, 54=1, 55=1, 56=1, 57=1, 58=1, 59=1, 60=1,
61=1, 62=1, 63=1, 64=1, 65=1, 66=1, 67=1, 68=1, 69=1, 70=1, 71=1, 72=1, 73=1,
74=1, 75=1, 76=1, 77=1, 78=1, 79=1, 80=1, 81=1, 82=1, 83=1, 84=1, 85=1, 86=1,
87=1, 88=1, 89=1, 90=1, 91=1, 92=1, 93=1, 94=1, 95=1, 96=1, 97=1, 98=1, 99=1,
100=1},
[jira] [Created] (IGNITE-10012) Add Transactional SQL feature description to Ignite website
Prachi Garg created IGNITE-10012: Summary: Add Transactional SQL feature description to Ignite website Key: IGNITE-10012 URL: https://issues.apache.org/jira/browse/IGNITE-10012 Project: Ignite Issue Type: Task Reporter: Prachi Garg Assignee: Prachi Garg Fix For: 2.7 [~Artem Budnikov], Please provide some information/ link to the documentation about this feature so that some description can be added to the website. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Legal advise on including Visual C++ Redistributable package into ODBC installer
Dmitry, Thanks for the pointers! Would you be interested in sorting this out for the community by talking to our ASF-mates who should know? -- Denis On Thu, Oct 25, 2018 at 3:21 AM Dmitriy Pavlov wrote: > Hi Igor, > > I'm not sure if someone in the community can know an answer to this > question. > > I can share a page with resolved legal questions here: > https://www.apache.org/legal/resolved.html#category-b > > But I think it may require confirmation from Apache Legal > http://www.apache.org/legal/ > https://issues.apache.org/jira/projects/LEGAL/summary > http://www.apache.org/foundation/mailinglists.html#foundation-legal > > Sincerely, > Dmitriy Pavlov > > ср, 24 окт. 2018 г. в 18:40, Igor Sapego : > > > Hi guys, > > > > I need your advice here. As some of you probably know we have > > Windows installers for ODBC in our binary releases, so users won't need > > to build Ignite C++ if all they want is to install and use our ODBC > driver. > > However, as we build driver with MSVC 10 when we are preparing our > > binary release, user should have Visual C++ 2010 Redistributable package > > for it to work properly. If they do not, it just do not work, not giving > > any > > human-readable errors, which is very confusing to a user. > > > > So my idea was to check for required package during installation and > > give user a download link to a proper package. However, on the WiX > > website there are articles on how to include the package into installer > > [1]. > > So I've thought that maybe this is even the better way to solve a > problem. > > > > So thus is my question, is it OK from the legal standpoint, if we will > > distribute > > installer, that includes Visual C++ 2010 Redistributable package? We are > > not > > going to put any binaries under the source control, of course. > > > > Can anyone help? > > > > [1] - > > > > > http://wixtoolset.org/documentation/manual/v3/howtos/redistributables_and_install_checks/install_vcredist.html > > > > Best Regards, > > Igor > > >
Re: Pre-touch for Ignite off-heap memory
In my understanding, that's an easy operation to support - we just need to allocate requested space and pre-touch it (iterate and fill out with 0). Yes, it will increase the launch time but it's a valid use case. Some companies do memory pre-touching on purpose. -- Denis On Thu, Oct 25, 2018 at 7:41 AM Gerus wrote: > Hi, Ivan > Let me try to explain. I think that there are 2 goals that are mostly > applicable for prod systems: > 1. I can agree with Dave that swap is not a good case for performance and > disk resource. It is possible that other applications can consume memory > that is free after Ignite was started. In this case if Ignite will be > creating new pages in runtime, it can face with OOM. > > 2. Ignite user can create wrong configuration. For example, data region can > exceed available memory by mistake or Ignite can be started on another > server with less RAM. It can lead to catch OOM in runtime > > To summarize: Pre-allocation can detect listed issues on Ignite start by > allocating OS RAM > > Im sure that this option have to be disabled by default, but user should > have a choice for startup > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >
Re: hello
Hi Scott, Thanks, the contributions looks valuable to me. As I see a community member is already working with you. Hope the code will be merged soon! -- Denis On Thu, Oct 25, 2018 at 10:59 AM Scott Feldstein wrote: > Hi Denis, > Thanks! > > This is what I'm trying to contribute > jira: https://issues.apache.org/jira/browse/IGNITE-9893 > pullRequest: https://github.com/apache/ignite/pull/5008 > > WRT the blog, we actually discussed this at the in-memory conference. At > the beginning of the year we'll start to make our usage more public > internally and externally if all goes well :) > > Scott > > On Wed, Oct 24, 2018 at 7:44 PM Denis Magda wrote: > > > Hey Scott, > > > > Great to know, welcome to the community! > > > > What exactly do you like to contribute back? Please start a separate > > discussion with the most meaningful topic. > > > > Also, if you can post a blog post about your architecture at VMWare will > be > > glad to mention it on the "Ignite in Production" page: > > https://ignite.apache.org/provenusecases.html > > > > -- > > Denis > > > > On Wed, Oct 24, 2018 at 7:39 PM Scott Feldstein > > wrote: > > > > > Hi Everyone, > > > I'm following the instructions from > > > https://ignite.apache.org/community/contribute.html. I'd like to > > > contribute > > > some of the code I've been working on in order to continue evolving > > Ignite. > > > > > > I've been evangelizing Ignite at VMware and am in the process of > locking > > > down our next-gen service architecture. The plan is to use Ignite as a > > > multi-faceted caching server on steriods! > > > > > > Please feel free to reach out to me and say hi as well :) > > > > > > Scott > > > > > >
Re: Unreliable checks in tests for string presence in GridStringLogger contents
Nikita,
I like your suggestion. It looks more expressive for me than existing
throwing version.
чт, 25 окт. 2018 г. в 21:07, Nikita Amelchev :
> Hi, Igniters.
>
> I suggest improving new listening test logger.
>
> I found usage case when needs wait for conditions for test duration
> optimization.
> For example, that messages A and B will be logged.
>
> For now, LogListener.check() doesn't return checking result as boolean.
> It throws the exception if conditions fail. Code for this case:
>
> waitForCondition(() -> {
> try {
>lsnr.check();
>
>return true;
> }
> catch (AssertionError ignored) {
>return false;
> }
> }, timeout);
>
> For code readability, I suggest make LogListener.check() with boolean type:
>
> waitForCondition(lsnr::check, timeout);
>
> Also, it's more understandable when we write explicit assert in tests:
> assertTrue("Fail reason.", lsnr.check());
> ср, 23 мая 2018 г. в 14:36, Andrey Kuznetsov :
> >
> > Thanks, Vyacheslav.
> >
> > Created the issue [1] based on your idea.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-8570
> >
> >
> > 2018-05-23 12:41 GMT+03:00 Vyacheslav Daradur :
> >
> > > Hi, Andrey, I have faced this problem too.
> > >
> > > I'd suggest introducing new logger for tests instead of extending API
> > > of *GridStringLogger*.
> > >
> > > The new logger should be some kind of *listened*, for example with the
> > > folowing API:
> > >
> > > void addListener(String pattern, CountDownLatch latch);
> > > void addListener(IgniteInClosure lsnr);
> > >
> > > This approach reduces memory load in comparison with
> *GridStringLogger*.
> > >
> > > Just for example these should demonstrate my idea, *listened logger* -
> > > [1], *listener* - [2]:
> > >
> > > [1] https://github.com/apache/ignite/blob/master/modules/
> > >
> compatibility/src/test/java/org/apache/ignite/compatibility/testframework/
> > > junits/logger/ListenedGridTestLog4jLogger.java
> > > [2] https://github.com/apache/ignite/blob/master/modules/
> > >
> compatibility/src/test/java/org/apache/ignite/compatibility/testframework/
> > > junits/IgniteCompatibilityAbstractTest.java#L304
> > >
> > >
> > >
> > --
> > Best regards,
> > Andrey Kuznetsov.
>
>
>
> --
> Best wishes,
> Amelchev Nikita
>
--
Best regards,
Andrey Kuznetsov.
Re: Unreliable checks in tests for string presence in GridStringLogger contents
Hi, Igniters.
I suggest improving new listening test logger.
I found usage case when needs wait for conditions for test duration
optimization.
For example, that messages A and B will be logged.
For now, LogListener.check() doesn't return checking result as boolean.
It throws the exception if conditions fail. Code for this case:
waitForCondition(() -> {
try {
lsnr.check();
return true;
}
catch (AssertionError ignored) {
return false;
}
}, timeout);
For code readability, I suggest make LogListener.check() with boolean type:
waitForCondition(lsnr::check, timeout);
Also, it's more understandable when we write explicit assert in tests:
assertTrue("Fail reason.", lsnr.check());
ср, 23 мая 2018 г. в 14:36, Andrey Kuznetsov :
>
> Thanks, Vyacheslav.
>
> Created the issue [1] based on your idea.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-8570
>
>
> 2018-05-23 12:41 GMT+03:00 Vyacheslav Daradur :
>
> > Hi, Andrey, I have faced this problem too.
> >
> > I'd suggest introducing new logger for tests instead of extending API
> > of *GridStringLogger*.
> >
> > The new logger should be some kind of *listened*, for example with the
> > folowing API:
> >
> > void addListener(String pattern, CountDownLatch latch);
> > void addListener(IgniteInClosure lsnr);
> >
> > This approach reduces memory load in comparison with *GridStringLogger*.
> >
> > Just for example these should demonstrate my idea, *listened logger* -
> > [1], *listener* - [2]:
> >
> > [1] https://github.com/apache/ignite/blob/master/modules/
> > compatibility/src/test/java/org/apache/ignite/compatibility/testframework/
> > junits/logger/ListenedGridTestLog4jLogger.java
> > [2] https://github.com/apache/ignite/blob/master/modules/
> > compatibility/src/test/java/org/apache/ignite/compatibility/testframework/
> > junits/IgniteCompatibilityAbstractTest.java#L304
> >
> >
> >
> --
> Best regards,
> Andrey Kuznetsov.
--
Best wishes,
Amelchev Nikita
Re: hello
Hi Denis, Thanks! This is what I'm trying to contribute jira: https://issues.apache.org/jira/browse/IGNITE-9893 pullRequest: https://github.com/apache/ignite/pull/5008 WRT the blog, we actually discussed this at the in-memory conference. At the beginning of the year we'll start to make our usage more public internally and externally if all goes well :) Scott On Wed, Oct 24, 2018 at 7:44 PM Denis Magda wrote: > Hey Scott, > > Great to know, welcome to the community! > > What exactly do you like to contribute back? Please start a separate > discussion with the most meaningful topic. > > Also, if you can post a blog post about your architecture at VMWare will be > glad to mention it on the "Ignite in Production" page: > https://ignite.apache.org/provenusecases.html > > -- > Denis > > On Wed, Oct 24, 2018 at 7:39 PM Scott Feldstein > wrote: > > > Hi Everyone, > > I'm following the instructions from > > https://ignite.apache.org/community/contribute.html. I'd like to > > contribute > > some of the code I've been working on in order to continue evolving > Ignite. > > > > I've been evangelizing Ignite at VMware and am in the process of locking > > down our next-gen service architecture. The plan is to use Ignite as a > > multi-faceted caching server on steriods! > > > > Please feel free to reach out to me and say hi as well :) > > > > Scott > > >
[jira] [Created] (IGNITE-10011) Pages leak suspicion in PDS
Ilya Kasnacheev created IGNITE-10011: Summary: Pages leak suspicion in PDS Key: IGNITE-10011 URL: https://issues.apache.org/jira/browse/IGNITE-10011 Project: Ignite Issue Type: Bug Components: persistence Reporter: Ilya Kasnacheev Attachments: Main.java See the attached Main which adds 500k records to 3 caches, then clears them, rinse, repeat. When ran with default settings, totalAllocatedSize will slowly double over the course of a few hours and then continue to grow. When ran with 2 FreeList buckets, it will double every time, 600M -> 1200M -> 1800M -> etc. See the userlist discussion -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] ignite pull request #5084: IGNITE-10003 Changed checkpointReadLock timeout f...
GitHub user andrey-kuznetsov opened a pull request: https://github.com/apache/ignite/pull/5084 IGNITE-10003 Changed checkpointReadLock timeout failure type. You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrey-kuznetsov/ignite ignite-10003 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5084.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5084 commit 61b26e4004bf70d40e8aae55422c8e60e11761ac Author: Andrey Kuznetsov Date: 2018-10-25T15:34:02Z IGNITE-10003 Changed checkpointReadLock timeout failure type. ---
Re: Documentation: dead links
Hi Pavel, 1) I fixed the broken link. Thanks for pointing out. 2) Yes, that is a common problem, and as far as I know, we don't have such a check, but we will when we adopt the new docs publishing process (markdown-to-html-pulled-from-github-based process). Cheers, Artem On 25.10.2018 16:36, Pavel Kuznetsov wrote: Hi, dear community, 1) I see dead link on the page https://apacheignite-sql.readme.io/docs/jdbc-client-driver Link "Cross-Cache Query" https://apacheignite-sql.readme.io/docs/cache-queries#cross-cache-queries points to 404 stub page. Could someone fix that? 2) I see it's a common problem. Do we have CI job that recursively checks our doc pages for dead links? Thanks, -Pavel
[GitHub] ignite pull request #5083: 9986 flakiness
GitHub user SomeFire opened a pull request: https://github.com/apache/ignite/pull/5083 9986 flakiness You can merge this pull request into a Git repository by running: $ git pull https://github.com/SomeFire/ignite 9986-flakiness Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5083.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5083 commit ee440d25e252fc36cae7b13de89d27a0febbc6c0 Author: Dmitrii Ryabov Date: 2018-10-25T15:14:22Z IGNITE-9986 TcpDiscoverySelfTest.testNodeShutdownOnRingMessageWorkerStartNotFinished is flaky commit d12d9d35a5b3b29ea96bf5617dd0643662c252a6 Author: Dmitrii Ryabov Date: 2018-10-25T15:19:54Z 9986 flakiness ---
[GitHub] ignite pull request #5082: IGNITE-9986 TcpDiscoverySelfTest.testNodeShutdown...
GitHub user SomeFire opened a pull request: https://github.com/apache/ignite/pull/5082 IGNITE-9986 TcpDiscoverySelfTest.testNodeShutdownOnRingMessageWorkerStartNotFinished is flaky You can merge this pull request into a Git repository by running: $ git pull https://github.com/SomeFire/ignite IGNITE-9986 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5082.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5082 commit ee440d25e252fc36cae7b13de89d27a0febbc6c0 Author: Dmitrii Ryabov Date: 2018-10-25T15:14:22Z IGNITE-9986 TcpDiscoverySelfTest.testNodeShutdownOnRingMessageWorkerStartNotFinished is flaky ---
[GitHub] ignite pull request #5081: IGNITE-9997
GitHub user NSAmelchev opened a pull request: https://github.com/apache/ignite/pull/5081 IGNITE-9997 Fix IgniteDiagnosticMessagesTest.testLongRunningTx test. You can merge this pull request into a Git repository by running: $ git pull https://github.com/NSAmelchev/ignite ignite-9997 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5081.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5081 commit 4d742f1004f915b4f3a255823db7d307ac3df66d Author: NSAmelchev Date: 2018-10-25T15:12:00Z Fix the test. ---
[GitHub] ignite pull request #5080: IGNITE-10009: ODBC fix for escaped table names
GitHub user isapego opened a pull request: https://github.com/apache/ignite/pull/5080 IGNITE-10009: ODBC fix for escaped table names You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10009 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5080.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5080 commit 7b7dccc26aa0ab308c873df4a28e533ecb3357fe Author: Igor Sapego Date: 2018-10-25T15:10:57Z IGNITE-10009: ODBC fix for escaped table names ---
[jira] [Created] (IGNITE-10010) Node halted if table was dropped
Sergey Kozlov created IGNITE-10010:
--
Summary: Node halted if table was dropped
Key: IGNITE-10010
URL: https://issues.apache.org/jira/browse/IGNITE-10010
Project: Ignite
Issue Type: Bug
Components: mvcc
Affects Versions: 2.7
Reporter: Sergey Kozlov
Fix For: 2.7
1. Start 2 nodes with PDS
2. Activate cluster
3. Connect sqlline.
4. Create table {{create table t1(a int, b varchar, primary key(a)) with
"ATOMICITY=TRANSACTIONAL_SNAPSHOT,backups=1";}}
5. Stop node 1
6. Drop table {{drop table t1;}}
7. Start node 1
8. Node 2 stopped by handler:
{noformat}
c:\Work\apache-ignite-2.7.0-SNAPSHOT-bin>bin\ignite.bat server.xml -v -J-DID=1
Ignite Command Line Startup, ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV
2018 Copyright(C) Apache Software Foundation
[18:04:22,745][INFO][main][IgniteKernal]
>>>__
>>> / _/ ___/ |/ / _/_ __/ __/
>>> _/ // (7 7// / / / / _/
>>> /___/\___/_/|_/___/ /_/ /___/
>>>
>>> ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV
>>> 2018 Copyright(C) Apache Software Foundation
>>>
>>> Ignite documentation: http://ignite.apache.org
[18:04:22,745][INFO][main][IgniteKernal] Config URL:
file:/c:/Work/apache-ignite-2.7.0-SNAPSHOT-bin/server.xml
[18:04:22,760][INFO][main][IgniteKernal] IgniteConfiguration
[igniteInstanceName=null, pubPoolSize=8, svcPoolSize=8, cal
lbackPoolSize=8, stripedPoolSize=8, sysPoolSize=8, mgmtPoolSize=4,
igfsPoolSize=8, dataStreamerPoolSize=8, utilityCacheP
oolSize=8, utilityCacheKeepAliveTime=6, p2pPoolSize=2, qryPoolSize=8,
igniteHome=c:\Work\apache-ignite-2.7.0-SNAPSHO
T-bin, igniteWorkDir=c:\Work\apache-ignite-2.7.0-SNAPSHOT-bin\work,
mbeanSrv=com.sun.jmx.mbeanserver.JmxMBeanServer@6f94
fa3e, nodeId=d02069db-6d0b-4a40-b185-1d95fa330853, marsh=BinaryMarshaller [],
marshLocJobs=false, daemon=false, p2pEnabl
ed=false, netTimeout=5000, sndRetryDelay=1000, sndRetryCnt=3,
metricsHistSize=1, metricsUpdateFreq=2000, metricsExpT
ime=9223372036854775807, discoSpi=TcpDiscoverySpi [addrRslvr=null,
sockTimeout=0, ackTimeout=0, marsh=null, reconCnt=10,
reconDelay=2000, maxAckTimeout=60, forceSrvMode=false,
clientReconnectDisabled=false, internalLsnr=null], segPlc=ST
OP, segResolveAttempts=2, waitForSegOnStart=true, allResolversPassReq=true,
segChkFreq=1, commSpi=TcpCommunicationSp
i [connectGate=null,
connPlc=org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$FirstConnectionPolicy@22ff4249,
enableForcibleNodeKill=false, enableTroubleshootingLog=false, locAddr=null,
locHost=null, locPort=47100, locPortRange=1
00, shmemPort=-1, directBuf=true, directSndBuf=false, idleConnTimeout=60,
connTimeout=5000, maxConnTimeout=60, r
econCnt=10, sockSndBuf=32768, sockRcvBuf=32768, msgQueueLimit=0,
slowClientQueueLimit=0, nioSrvr=null, shmemSrv=null, us
ePairedConnections=false, connectionsPerNode=1, tcpNoDelay=true,
filterReachableAddresses=false, ackSndThreshold=32, una
ckedMsgsBufSize=0, sockWriteTimeout=2000, boundTcpPort=-1,
boundTcpShmemPort=-1, selectorsCnt=4, selectorSpins=0, addrRs
lvr=null, ctxInitLatch=java.util.concurrent.CountDownLatch@2d1ef81a[Count = 1],
stopping=false], evtSpi=org.apache.ignit
e.spi.eventstorage.NoopEventStorageSpi@4c402120, colSpi=NoopCollisionSpi [],
deploySpi=LocalDeploymentSpi [], indexingSp
i=org.apache.ignite.spi.indexing.noop.NoopIndexingSpi@815b41f, addrRslvr=null,
encryptionSpi=org.apache.ignite.spi.encry
ption.noop.NoopEncryptionSpi@5542c4ed, clientMode=false,
rebalanceThreadPoolSize=1, txCfg=TransactionConfiguration [txSe
rEnabled=false, dfltIsolation=REPEATABLE_READ, dfltConcurrency=PESSIMISTIC,
dfltTxTimeout=0, txTimeoutOnPartitionMapExch
ange=0, pessimisticTxLogSize=0, pessimisticTxLogLinger=1,
tmLookupClsName=null, txManagerFactory=null, useJtaSync=fa
lse], cacheSanityCheckEnabled=true, discoStartupDelay=6, deployMode=SHARED,
p2pMissedCacheSize=100, locHost=127.0.0.
1, timeSrvPortBase=31100, timeSrvPortRange=100, failureDetectionTimeout=1,
sysWorkerBlockedTimeout=null, clientFailu
reDetectionTimeout=3, metricsLogFreq=6, hadoopCfg=null,
connectorCfg=ConnectorConfiguration [jettyPath=null, hos
t=null, port=11211, noDelay=true, directBuf=false, sndBufSize=32768,
rcvBufSize=32768, idleQryCurTimeout=60, idleQry
CurCheckFreq=6, sndQueueLimit=0, selectorCnt=4, idleTimeout=7000,
sslEnabled=false, sslClientAuth=false, sslCtxFacto
ry=null, sslFactory=null, portRange=100, threadPoolSize=8,
msgInterceptor=null], odbcCfg=null, warmupClos=null, atomicCf
g=AtomicConfiguration [seqReserveSize=1000, cacheMode=PARTITIONED, backups=1,
aff=null, grpName=null], classLdr=null, ss
lCtxFactory=null, platformCfg=null, binaryCfg=BinaryConfiguration
[idMapper=null, nameMapper=null, serializer=null, comp
actFooter=true], memCfg=null, pstCfg=null, dsCfg=DataStorageConfiguration
[sysRegionInitSize=52428800,
[jira] [Created] (IGNITE-10009) ODBC: SQLColumns does not work for tables with escape sequences in name
Igor Sapego created IGNITE-10009:
Summary: ODBC: SQLColumns does not work for tables with escape
sequences in name
Key: IGNITE-10009
URL: https://issues.apache.org/jira/browse/IGNITE-10009
Project: Ignite
Issue Type: Bug
Components: odbc
Affects Versions: 2.6
Reporter: Igor Sapego
Assignee: Igor Sapego
Fix For: 2.8
Table names with escaped underscore '\_' or percent '\%' characters is not
recognized by the ODBC driver. I.e. the following table pattern:
{noformat}
TEST\_TABLE
{noformat}
Should match the following table:
{noformat}
TEST_TABLE
{noformat}
But currently it does not. Needs to be fixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10008) Need to investigate why these tests is failed after consistentID set
Alexey Platonov created IGNITE-10008: Summary: Need to investigate why these tests is failed after consistentID set Key: IGNITE-10008 URL: https://issues.apache.org/jira/browse/IGNITE-10008 Project: Ignite Issue Type: Bug Reporter: Alexey Platonov In these test method setConsistentID is overridden because setting of consistentID to nodes will let fail them: JdbcDistributedJoinsQueryTest GridCacheAbstractMetricsSelfTest IgniteCacheContinuousQueryNoUnsubscribeTest IgniteBinaryObjectFieldsQuerySelfTest IgniteSqlSkipReducerOnUpdateDmlSelfTest -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10007) Deactivation hangs if an open transaction exists
Sergey Kozlov created IGNITE-10007:
--
Summary: Deactivation hangs if an open transaction exists
Key: IGNITE-10007
URL: https://issues.apache.org/jira/browse/IGNITE-10007
Project: Ignite
Issue Type: Bug
Components: mvcc
Affects Versions: 2.7
Reporter: Sergey Kozlov
Fix For: 2.7
1. Start 2 node with PDS
2. Activate cluster
3. Connect sqlline
4. Create table {{create table t1(a int, b varchar, primary key(a)) with
"ATOMICITY=TRANSACTIONAL_SNAPSHOT,backups=1";}}
3.Start TX and execute a DML commnd:
{noformat}
begin;
insert into t1 values (1, '1');
{noformat}
4. Try deactivate cluster {{bin/control.bat --deactivate}}. The scripts doesn't
return control.
5. Show LRT:
{noformat}
c:\Work\apache-ignite-2.7.0-SNAPSHOT-bin>bin\control.bat --tx
Control utility [ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV]
2018 Copyright(C) Apache Software Foundation
User:
Matching transactions:
TcpDiscoveryNode [id=5d3e8936-174d-42e2-a47f-c70ec02bccab, addrs=[127.0.0.1],
order=1, ver=2.7.0#19700101-sha1:,
isClient=false, consistentId=1]
Tx: [xid=74bc1aba661--090e-b121--0001, label=null,
state=ACTIVE, startTime=2018-10-25 17:34:35.5
22, duration=352, isolation=REPEATABLE_READ, concurrency=PESSIMISTIC,
topVer=AffinityTopologyVersion [topVer=2, minorTop
Ver=6], timeout=0, size=0, dhtNodes=[41ff88d2],
nearXid=74bc1aba661--090e-b121--0001, parentNodeIds=
[5d3e8936]]
{noformat}
6. Complete TX:
{noformat}
0: jdbc:ignite:thin://127.0.0.1/> commit;
Error: class org.apache.ignite.IgniteException: Can not perform the operation
because the cluster is inactive. Note, tha
t the cluster is considered inactive by default if Ignite Persistent Store is
used to let all the nodes join the cluster
. To activate the cluster call Ignite.active(true). (state=5,code=1)
java.sql.SQLException: class org.apache.ignite.IgniteException: Can not perform
the operation because the cluster is ina
ctive. Note, that the cluster is considered inactive by default if Ignite
Persistent Store is used to let all the nodes
join the cluster. To activate the cluster call Ignite.active(true).
at
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
at sqlline.Commands.execute(Commands.java:823)
at sqlline.Commands.sql(Commands.java:733)
at sqlline.SqlLine.dispatch(SqlLine.java:795)
at sqlline.SqlLine.begin(SqlLine.java:668)
at sqlline.SqlLine.start(SqlLine.java:373)
at sqlline.SqlLine.main(SqlLine.java:265)
0: jdbc:ignite:thin://127.0.0.1/>
{noformat}
It.s ok but LRT is still presented and deactivation script doesn't return
control back to user:
{noformat}
c:\Work\apache-ignite-2.7.0-SNAPSHOT-bin>bin\control.bat --tx
Control utility [ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV]
2018 Copyright(C) Apache Software Foundation
User:
Matching transactions:
TcpDiscoveryNode [id=5d3e8936-174d-42e2-a47f-c70ec02bccab, addrs=[127.0.0.1],
order=1, ver=2.7.0#19700101-sha1:,
isClient=false, consistentId=1]
Tx: [xid=74bc1aba661--090e-b121--0001, label=null,
state=ACTIVE, startTime=2018-10-25 17:34:35.5
22, duration=510, isolation=REPEATABLE_READ, concurrency=PESSIMISTIC,
topVer=AffinityTopologyVersion [topVer=2, minorTop
Ver=6], timeout=0, size=0, dhtNodes=[41ff88d2],
nearXid=74bc1aba661--090e-b121--0001, parentNodeIds=
[5d3e8936]]
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: Pre-touch for Ignite off-heap memory
Hi, Ivan Let me try to explain. I think that there are 2 goals that are mostly applicable for prod systems: 1. I can agree with Dave that swap is not a good case for performance and disk resource. It is possible that other applications can consume memory that is free after Ignite was started. In this case if Ignite will be creating new pages in runtime, it can face with OOM. 2. Ignite user can create wrong configuration. For example, data region can exceed available memory by mistake or Ignite can be started on another server with less RAM. It can lead to catch OOM in runtime To summarize: Pre-allocation can detect listed issues on Ignite start by allocating OS RAM Im sure that this option have to be disabled by default, but user should have a choice for startup -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
[jira] [Created] (IGNITE-10006) Checking for each operation within a transaction to calculate how long it took
Sergey created IGNITE-10006: --- Summary: Checking for each operation within a transaction to calculate how long it took Key: IGNITE-10006 URL: https://issues.apache.org/jira/browse/IGNITE-10006 Project: Ignite Issue Type: Improvement Reporter: Sergey In some cases there is necessity to control a time of transaction. For example, extending the transaction API and added TxStat with information about completed transaction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10005) SQL table catalog documentation
Pavel Kuznetsov created IGNITE-10005:
Summary: SQL table catalog documentation
Key: IGNITE-10005
URL: https://issues.apache.org/jira/browse/IGNITE-10005
Project: Ignite
Issue Type: Task
Components: documentation
Reporter: Pavel Kuznetsov
When IGNITE-3467 is done, we need to add few words about possible catalog
tables catalog name.
What we need to document:
1) Thre are no tables without catalog (tables which catalog is equal to empty
string {{""}}, not null!).
2) The only possible catalog for tables is "IGNITE".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10004) Parse error leads to leave the transaction
Sergey Kozlov created IGNITE-10004:
--
Summary: Parse error leads to leave the transaction
Key: IGNITE-10004
URL: https://issues.apache.org/jira/browse/IGNITE-10004
Project: Ignite
Issue Type: Bug
Components: mvcc
Affects Versions: 2.7
Reporter: Sergey Kozlov
1. Start 2 nodes + connect sqlline
2. Execute following queries:
{noformat}
create table t10 (a int, b varchar, primary key(a)) with
"ATOMICITY=TRANSACTIONAL_SNAPSHOT,backups=1";
begin;
insert into t10 values(1); <- worng set
insert into t10 values(2, '2'); <- coorect set
commit;
{noformat}
The output:
{noformat}
0: jdbc:ignite:thin://127.0.0.1/> create table t10 (a int, b varchar, primary
key(a)) with "ATOMICITY=TRANSACTIONAL_SNAP
SHOT,backups=1";
No rows affected (0,032 seconds)
0: jdbc:ignite:thin://127.0.0.1/> begin;
No rows affected (0 seconds)
0: jdbc:ignite:thin://127.0.0.1/> insert into t10 values(1);
Error: Failed to parse query. ═хтхЁэюх ъюышўхёЄтю ёЄюысЎют
Column count does not match; SQL statement:
insert into t10 values(1) [21002-197] (state=42000,code=1001)
java.sql.SQLException: Failed to parse query. Неверное количество столбцов
Column count does not match; SQL statement:
insert into t10 values(1) [21002-197]
at
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
at sqlline.Commands.execute(Commands.java:823)
at sqlline.Commands.sql(Commands.java:733)
at sqlline.SqlLine.dispatch(SqlLine.java:795)
at sqlline.SqlLine.begin(SqlLine.java:668)
at sqlline.SqlLine.start(SqlLine.java:373)
at sqlline.SqlLine.main(SqlLine.java:265)
0: jdbc:ignite:thin://127.0.0.1/> insert into t10 values(2, '2');
Error: Transaction is already completed. (state=25000,code=5004)
java.sql.SQLException: Transaction is already completed.
at
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
at sqlline.Commands.execute(Commands.java:823)
at sqlline.Commands.sql(Commands.java:733)
at sqlline.SqlLine.dispatch(SqlLine.java:795)
at sqlline.SqlLine.begin(SqlLine.java:668)
at sqlline.SqlLine.start(SqlLine.java:373)
at sqlline.SqlLine.main(SqlLine.java:265)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10003) Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read lock timeout detected
Andrey Kuznetsov created IGNITE-10003:
-
Summary: Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR
when checkpoint read lock timeout detected
Key: IGNITE-10003
URL: https://issues.apache.org/jira/browse/IGNITE-10003
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: Andrey Kuznetsov
Fix For: 2.8
{{GridCacheDatabaseSharedManager#failCheckpointReadLock}} should report
{{SYSTEM_WORKER_BLOCKED}} to failure handler: it is closer to the truth and
default consequenses are not so severe as opposed to {{CRITICAL_ERROR}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10002) MVCC: Create "Cache 2" test suite for MVCC mode.
Andrew Mashenkov created IGNITE-10002: - Summary: MVCC: Create "Cache 2" test suite for MVCC mode. Key: IGNITE-10002 URL: https://issues.apache.org/jira/browse/IGNITE-10002 Project: Ignite Issue Type: Sub-task Components: mvcc Reporter: Andrew Mashenkov Create MVCC version of IgniteCacheTestSuite2 and add it to TC. All non-relevant tests should be marked as ignored. Failed tests should be muted and tickets should be created for unknown failure reasons. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10001) MVCC: Make existed tests run in MVCC mode as well.
Andrew Mashenkov created IGNITE-10001: - Summary: MVCC: Make existed tests run in MVCC mode as well. Key: IGNITE-10001 URL: https://issues.apache.org/jira/browse/IGNITE-10001 Project: Ignite Issue Type: Task Components: mvcc Reporter: Andrew Mashenkov Fix For: 2.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] ignite pull request #4985: IGNITE-9780 SQL system view for cache groups
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4985 ---
[jira] [Created] (IGNITE-10000) Document IGNITE.CACHE_GROUPS view
Vladimir Ozerov created IGNITE-1: Summary: Document IGNITE.CACHE_GROUPS view Key: IGNITE-1 URL: https://issues.apache.org/jira/browse/IGNITE-1 Project: Ignite Issue Type: Task Components: documentation Reporter: Vladimir Ozerov Assignee: Artem Budnikov Fix For: 2.8 New SQL view was introduced in IGNITE-9780. It lists cluster cache groups. Most fields are self-descriptive, their names and data types could be found in the code [1]. [1] https://github.com/apache/ignite/blob/master/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/sys/view/SqlSystemViewCacheGroups.java -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9999) Add verbose logging for node recovery
Alexey Goncharuk created IGNITE-: Summary: Add verbose logging for node recovery Key: IGNITE- URL: https://issues.apache.org/jira/browse/IGNITE- Project: Ignite Issue Type: Task Reporter: Alexey Goncharuk -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] ignite pull request #5079: IGNITE-9990 Control.sh utility should request a p...
GitHub user a-polyakov opened a pull request: https://github.com/apache/ignite/pull/5079 IGNITE-9990 Control.sh utility should request a password if necessary. Signed-off-by: a-polyakov You can merge this pull request into a Git repository by running: $ git pull https://github.com/a-polyakov/ignite IGNITE-9990 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5079.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5079 commit 538d3d2ef924a5ad8f653c3d0c37397eec405da7 Author: a-polyakov Date: 2018-10-25T13:46:44Z IGNITE-9990 Control.sh utility should request a password if necessary. Signed-off-by: a-polyakov ---
Documentation: dead links
Hi, dear community, 1) I see dead link on the page https://apacheignite-sql.readme.io/docs/jdbc-client-driver Link "Cross-Cache Query" https://apacheignite-sql.readme.io/docs/cache-queries#cross-cache-queries points to 404 stub page. Could someone fix that? 2) I see it's a common problem. Do we have CI job that recursively checks our doc pages for dead links? Thanks, -Pavel
Re: Critical worker threads liveness checking drawbacks
Andrey,
I still see that checkpoint read lock acquisition raises a CRITICAL_ERROR,
which by default will shut down local node. As far as I remember, we
decided that by default thread timeout should not trigger node failure.
Now, however, it does, because we ignore SYSTEM_WORKER_BLOCKED events in
default configuration.
Should we introduce another critical failure type
CHECKPOINT_READ_LOCK_BLOCKED or use SYSTEM_WORKER_BLOCKED for checkpoint
read lock acquire failure?
--AG
пт, 12 окт. 2018 г. в 8:29, Andrey Kuznetsov :
> Igniters,
>
> Now I spot blocking / long-running code arising from
> {{GridDhtPartitionsExchangeFuture#init}} calls in partition-exchanger
> thread, see [1]. Ideally, all blocking operations along all possible code
> paths should be guarded implicitly from critical failure detector to avoid
> the thread from being considered blocked. There is a pull request [2] that
> provides shallow solution. I didn't change code outside
> {{GridDhtPartitionsExchangeFuture}}, otherwise it could be broken by any
> upcoming change. Also, I didn't touch the code runnable by threads other
> than partition-exchanger. So I have a number of guarded sections that are
> wider than they could be, and this potentially hides issues from failure
> detector. Does this PR make sense? Or maybe it's better to exclude
> partition-exchanger from critical threads registry at all?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-9710
> [2] https://github.com/apache/ignite/pull/4962
>
>
> пт, 28 сент. 2018 г. в 18:56, Maxim Muzafarov :
>
> > Andrey, Andrey
> >
> > > Thanks for being attentive! It's definitely a typo. Could you please
> > create
> > > an issue?
> >
> > I've created an issue [1] and prepared PR [2].
> > Please, review this change.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-9723
> > [2] https://github.com/apache/ignite/pull/4862
> >
> > On Fri, 28 Sep 2018 at 16:58 Yakov Zhdanov wrote:
> >
> > > Config option + mbean access. Does that make sense?
> > >
> > > Yakov
> > >
> > > On Fri, Sep 28, 2018, 17:17 Vladimir Ozerov
> > wrote:
> > >
> > > > Then it should be config option.
> > > >
> > > > пт, 28 сент. 2018 г. в 13:15, Andrey Gura :
> > > >
> > > > > Guys,
> > > > >
> > > > > why we need both config option and system property? I believe one
> way
> > > is
> > > > > enough.
> > > > > On Fri, Sep 28, 2018 at 12:38 PM Nikolay Izhikov <
> > nizhi...@apache.org>
> > > > > wrote:
> > > > > >
> > > > > > Ticket created -
> https://issues.apache.org/jira/browse/IGNITE-9737
> > > > > >
> > > > > > Fixed version is 2.7.
> > > > > >
> > > > > > В Пт, 28/09/2018 в 11:41 +0300, Alexey Goncharuk пишет:
> > > > > > > Nikolay, I agree, a user should be able to disable both thread
> > > > liveness
> > > > > > > check and checkpoint read lock timeout check from config and a
> > > system
> > > > > > > property.
> > > > > > >
> > > > > > > пт, 28 сент. 2018 г. в 11:30, Nikolay Izhikov <
> > nizhi...@apache.org
> > > >:
> > > > > > >
> > > > > > > > Hello, Igniters.
> > > > > > > >
> > > > > > > > I found that this feature can't be disabled from config.
> > > > > > > > The only way to disable it is from JMX bean.
> > > > > > > >
> > > > > > > > I think it very dangerous: If we have some corner case or a
> bug
> > > in
> > > > > this
> > > > > > > > Watch Dog it can make Ignite unusable.
> > > > > > > > I propose to implement possibility to disable this feature
> > both -
> > > > > from
> > > > > > > > config and from JVM options.
> > > > > > > >
> > > > > > > > What do you think?
> > > > > > > >
> > > > > > > > В Чт, 27/09/2018 в 16:14 +0300, Andrey Kuznetsov пишет:
> > > > > > > > > Maxim,
> > > > > > > > >
> > > > > > > > > Thanks for being attentive! It's definitely a typo. Could
> you
> > > > > please
> > > > > > > >
> > > > > > > > create
> > > > > > > > > an issue?
> > > > > > > > >
> > > > > > > > > чт, 27 сент. 2018 г. в 16:00, Maxim Muzafarov <
> > > > maxmu...@gmail.com
> > > > > >:
> > > > > > > > >
> > > > > > > > > > Folks,
> > > > > > > > > >
> > > > > > > > > > I've found in `GridCachePartitionExchangeManager:2684`
> [1]
> > > > > (master
> > > > > > > >
> > > > > > > > branch)
> > > > > > > > > > exchange future wrapped
> > > > > > > > > > with double `blockingSectionEnd` method. Is it correct? I
> > > just
> > > > > want to
> > > > > > > > > > understand this change and
> > > > > > > > > > how should I use this in the future.
> > > > > > > > > >
> > > > > > > > > > Should I file a new issue to fix this? I think here
> > > > > > > >
> > > > > > > > `blockingSectionBegin`
> > > > > > > > > > method should be used.
> > > > > > > > > >
> > > > > > > > > > -
> > > > > > > > > > blockingSectionEnd();
> > > > > > > > > >
> > > > > > > > > > try {
> > > > > > > > > > resVer = exchFut.get(exchTimeout,
> > TimeUnit.MILLISECONDS);
> > > > > > > > > > } finally {
> > > > > > > > > > blockingSectionEnd();
> > > > > > > > > > }
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
[GitHub] ignite pull request #5078: IGNITE-9937 Primary response error can be lost du...
GitHub user gromtech opened a pull request: https://github.com/apache/ignite/pull/5078 IGNITE-9937 Primary response error can be lost due to unwrapping a key You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9937 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5078.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5078 commit e9d3827026bbd3f3c30c0a88f31a41528ecc200d Author: Roman Guseinov Date: 2018-10-25T12:52:52Z IGNITE-9937 Primary response error can be lost due to unwrapping a key ---
[GitHub] ignite pull request #5077: IGNITE-7164: SQL TX: Remap protocol
GitHub user AMashenkov opened a pull request: https://github.com/apache/ignite/pull/5077 IGNITE-7164: SQL TX: Remap protocol You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-7164 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5077.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5077 commit 576fbccece8862770d117ff3c3ca516004636fc0 Author: Andrey V. Mashenkov Date: 2018-10-24T14:16:02Z IGNITE-7164: Fix tx remap. commit 21b140a67018399fdef222fbb2d5437961c2c070 Author: Andrey V. Mashenkov Date: 2018-10-24T16:37:40Z IGNITE-7164: Fix tx remap. commit bcf621e3f0aba2b1ca6bda12d6a805a1fce2605a Author: Andrey V. Mashenkov Date: 2018-10-25T09:33:52Z IGNITE-7164: Minors. commit 07286cfe5f8080fdc8381508761ef29c0a9f4c5b Author: Andrey V. Mashenkov Date: 2018-10-25T09:33:52Z IGNITE-7164: Minors. commit d8b7fc48180810d513f8d284b53ec9664eacbcab Author: Andrey V. Mashenkov Date: 2018-10-25T12:23:05Z IGNITE-7164: Minors. Test added. commit 69b507e6239503bf6a8492927ffbd7d98aeb1180 Author: Andrey V. Mashenkov Date: 2018-10-25T12:36:37Z IGNITE-7164: Minors. Test added. commit 7a9a224fd5783a7708d6cc8793783e16bc523c7d Author: Andrey V. Mashenkov Date: 2018-10-25T12:48:18Z IGNITE-7164: Minors. ---
[GitHub] ignite pull request #4821: IGNITE-9655 DML benchmark suite (except selects)
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4821 ---
[GitHub] ignite pull request #5076: IGNITE-9171 Use lazy mode with results pre-fetch
GitHub user tledkov-gridgain opened a pull request: https://github.com/apache/ignite/pull/5076 IGNITE-9171 Use lazy mode with results pre-fetch You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9171 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5076.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5076 commit 044e1e51e6609e92ff46b0650ec8d69afb2b424d Author: tledkov-gridgain Date: 2018-10-23T09:10:02Z IGNITE-9171: save the progress commit 05ee7dba340395208ab040c7e13710433e44fe1e Author: tledkov-gridgain Date: 2018-10-24T13:22:02Z IGNITE-9171: lazy mode performance optimization for one-page results commit e2ffb4a9cc83242e3e6c4283319582c1933eb6b2 Author: tledkov-gridgain Date: 2018-10-24T14:25:58Z Merge branch '_master' into ignite-9171 commit 7ddcacbfcf484ed359fd1f9e2cbcc6aff414249d Author: tledkov-gridgain Date: 2018-10-25T12:01:25Z IGNITE-9171: lazy mode performance optimization commit 70be3700b47a1e367f365b049e7872f4ab84efa8 Author: tledkov-gridgain Date: 2018-10-25T12:06:49Z Merge master into ignite-9171 ---
[GitHub] ignite pull request #5051: IGNITE-6811: Allowed empty batch in JDBC thin dri...
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5051 ---
[GitHub] ignite pull request #4879: IGNITE-9447: Fixed benchmarks setup freeze.
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4879 ---
[GitHub] ignite pull request #4796: IGNITE-9637: Suite for data load benchmarks
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4796 ---
[GitHub] ignite pull request #5071: Ignite 9976 mass run (fs test)
Github user xtern closed the pull request at: https://github.com/apache/ignite/pull/5071 ---
Re: Legal advise on including Visual C++ Redistributable package into ODBC installer
Hi Igor, I'm not sure if someone in the community can know an answer to this question. I can share a page with resolved legal questions here: https://www.apache.org/legal/resolved.html#category-b But I think it may require confirmation from Apache Legal http://www.apache.org/legal/ https://issues.apache.org/jira/projects/LEGAL/summary http://www.apache.org/foundation/mailinglists.html#foundation-legal Sincerely, Dmitriy Pavlov ср, 24 окт. 2018 г. в 18:40, Igor Sapego : > Hi guys, > > I need your advice here. As some of you probably know we have > Windows installers for ODBC in our binary releases, so users won't need > to build Ignite C++ if all they want is to install and use our ODBC driver. > However, as we build driver with MSVC 10 when we are preparing our > binary release, user should have Visual C++ 2010 Redistributable package > for it to work properly. If they do not, it just do not work, not giving > any > human-readable errors, which is very confusing to a user. > > So my idea was to check for required package during installation and > give user a download link to a proper package. However, on the WiX > website there are articles on how to include the package into installer > [1]. > So I've thought that maybe this is even the better way to solve a problem. > > So thus is my question, is it OK from the legal standpoint, if we will > distribute > installer, that includes Visual C++ 2010 Redistributable package? We are > not > going to put any binaries under the source control, of course. > > Can anyone help? > > [1] - > > http://wixtoolset.org/documentation/manual/v3/howtos/redistributables_and_install_checks/install_vcredist.html > > Best Regards, > Igor >
[GitHub] ignite pull request #5075: IGNITE-9988
GitHub user devozerov opened a pull request: https://github.com/apache/ignite/pull/5075 IGNITE-9988 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9988 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5075.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5075 commit 8626ad46d7f5ecb4ff8a783e5efd59fbdc0553fc Author: devozerov Date: 2018-10-04T12:22:53Z Done. But reproducer hangs for some reason (looks like we do not stop JDBC handler threads properly). commit 5bf4b4f285f41c56f674b9051f884f9760f72f3e Author: devozerov Date: 2018-10-04T12:26:22Z No more hang. Need to make sure that proper JDBC state is propagated back. commit c5ce917b2461bacfc781330be234b5496f2ece85 Author: devozerov Date: 2018-10-25T08:25:47Z WIP. commit 911e89ecac9b3062099defa9ed5c4fcceb750eaa Author: devozerov Date: 2018-10-25T08:34:08Z WIP. commit 1c94a860117e26e2e3b48949cf307678555acc22 Author: devozerov Date: 2018-10-25T09:46:24Z WIP on tests. ---
[jira] [Created] (IGNITE-9998) .NET: Implement partition preload API
Alexei Scherbakov created IGNITE-9998: - Summary: .NET: Implement partition preload API Key: IGNITE-9998 URL: https://issues.apache.org/jira/browse/IGNITE-9998 Project: Ignite Issue Type: Improvement Reporter: Alexei Scherbakov Fix For: 2.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] ignite pull request #5074: IGNITE-9622: MVCC Cache API: prohibit non PESSIMI...
GitHub user pavlukhin opened a pull request: https://github.com/apache/ignite/pull/5074 IGNITE-9622: MVCC Cache API: prohibit non PESSIMISTIC REPEATABLE_READ transactions You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9622 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5074.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5074 commit f35d8dcc7ce7237c9a0e9ce5d23979c13bfd99ac Author: ipavlukhin Date: 2018-10-25T08:47:31Z unify unsupported tx modes check for cache API ---
[jira] [Created] (IGNITE-9997) IgniteDiagnosticMessagesTest.testLongRunningTx fails on TC
Amelchev Nikita created IGNITE-9997:
---
Summary: IgniteDiagnosticMessagesTest.testLongRunningTx fails on TC
Key: IGNITE-9997
URL: https://issues.apache.org/jira/browse/IGNITE-9997
Project: Ignite
Issue Type: Bug
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita
Fix For: 2.8
It fails with the assertion error. [Example of
fail.|https://ci.ignite.apache.org/viewLog.html?buildId=2157923=buildResultsDiv=IgniteTests24Java8_BinaryObjectsSimpleMapperBasic#testNameId808105671819833392]
Log:
{noformat}
junit.framework.AssertionFailedError
at
org.apache.ignite.internal.managers.IgniteDiagnosticMessagesTest.testLongRunningTx(IgniteDiagnosticMessagesTest.java:378){noformat}
{code:java}
assertTrue(log.contains("Cache entries [cacheId=" +
CU.cacheId(DEFAULT_CACHE_NAME) + ", cacheName=" + DEFAULT_CACHE_NAME + "]:"));
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9996) Investigate possible performance drop in FSYNC mode for ignite-2.7 compared to ignite-2.6
Alexey Goncharuk created IGNITE-9996: Summary: Investigate possible performance drop in FSYNC mode for ignite-2.7 compared to ignite-2.6 Key: IGNITE-9996 URL: https://issues.apache.org/jira/browse/IGNITE-9996 Project: Ignite Issue Type: Task Reporter: Alexey Goncharuk -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] ignite pull request #5073: IGNITE-9995: Fix bugs in windows launch bat scrip...
GitHub user xuchuanyin opened a pull request: https://github.com/apache/ignite/pull/5073 IGNITE-9995: Fix bugs in windows launch bat script Problems: If user is under ignite source dir, launching ignite will cause "Input line is too long" error. While if user switch to another dir and lanunch ignite, this error will disappear. Analyze: This is because in the first scenario, the current working dir is just he IGNITE_HOME, this will cause ignite adding same pathes to classpath twice, thus causing a line in cmd too long. Solution: Avoiding adding the same path to classpath twice if current working dir is the same as IGNITE_HOME. Besides, we use the full path name instead of relative path name if current working dir is not the same as IGNITE_HOME. You can merge this pull request into a Git repository by running: $ git pull https://github.com/xuchuanyin/ignite 181025_bug_windows_bat Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5073.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5073 commit df2186128fd585e479be2b61c66ef75a187caa7f Author: xuchuanyin Date: 2018-10-25T08:05:37Z Fix bugs in windows launch bat script Problems: If user is under ignite source dir, launching ignite will cause "Input line is too long" error. While if user switch to another dir and lanunch ignite, this error will disappear. Analyze: This is because in the first scenario, the current working dir is just he IGNITE_HOME, this will cause ignite adding same pathes to classpath twice, thus causing a line in cmd too long. Solution: Avoiding adding the same path to classpath twice if current working dir is the same as IGNITE_HOME. Besides, we use the full path name instead of relative path name if current working dir is not the same as IGNITE_HOME. ---
[jira] [Created] (IGNITE-9995) fix bugs
xuchuanyin created IGNITE-9995: -- Summary: fix bugs Key: IGNITE-9995 URL: https://issues.apache.org/jira/browse/IGNITE-9995 Project: Ignite Issue Type: Improvement Reporter: xuchuanyin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9994) idle_verify -analyze -partId= -grpId=(minus)number not working
ARomantsov created IGNITE-9994: -- Summary: idle_verify -analyze -partId= -grpId=(minus)number not working Key: IGNITE-9994 URL: https://issues.apache.org/jira/browse/IGNITE-9994 Project: Ignite Issue Type: Bug Affects Versions: 2.6 Reporter: ARomantsov If enter command with plus -grpId - it working -- This message was sent by Atlassian JIRA (v7.6.3#76005)
