Re: [DISCUSS] PMC Chair rotation time
Igniters, It’s been almost 3 years since my election as the PMC Chair and I’d like the community to give other PMC members an opportunity to serve in this role. It’s healthy to rotate the role more frequently and we’re already due. Though the chair doesn’t have formal power, he/she can bring a fresh perspective and help to navigate the community via trails not considered before. Please propose candidates selecting among active PMC members: https://ignite.apache.org/community/resources.html#people Denis On Monday, December 5, 2016, Dmitriy Setrakyan wrote: > I haven't forgotten. Just got back from a business trip. Will start a vote > this week. > > On Wed, Nov 23, 2016 at 5:18 PM, Dmitriy Setrakyan > wrote: > > > Cos, I will start the vote soon. A bit over occupied with travel and > > holidays at this moment. > > > > On Mon, Nov 21, 2016 at 12:33 PM, Konstantin Boudnik > > wrote: > > > >> Ok, > >> > >> This was a great discussion, thanks for the deep insight, Roman! > >> > >> looks like this thread has stewed for a while and it is time to [VOTE]. > >> The > >> following candidates were put forward during the [DISCUSS] (in the order > >> of > >> their appearance on the thread): > >> > >> Dmitriy Setrakyan > >> Vladimir Ozerov > >> Konstantin Boudnik > >> Valentin Kulichenko > >> Denis Magda > >> Branko Čibej > >> > >> Considering the number of the candidates I propose to use > >> First-past-the-post > >> voting, with a single-round/single winner rules, where the candidate > >> collecting the most votes (not the majority) wins. [1] > >> > >> Dmitriy, would you do the honors and start the formal [VOTE]? > >> > >> > >> [1] https://en.wikipedia.org/wiki/First-past-the-post_voting > >> > >> Thanks, > >> Cos > >> > >> On Thu, Nov 10, 2016 at 08:19PM, Roman Shaposhnik wrote: > >> > On Wed, Nov 2, 2016 at 11:32 AM, Dmitriy Setrakyan > >> > wrote: > >> > > While all the candidates suggested so far look good, I would propose > >> Denis > >> > > Magda as the next PMC chair. His participation in the project does > >> not only > >> > > have to do with the code, but also with Ignite project overall, > >> including > >> > > website, documentation, new tickets, design, etc. > >> > > >> > Sorry to come to this thread rather late, but I wanted to offer a > >> somewhat > >> > different perspective that hopefully can help reframe this discussion > >> > a little bit. > >> > Note, that what I'm about to say is coming from a non-coding (on > >> Ignite) member > >> > of the PMC. In fact, I stayed on the PMC after graduation more with my > >> ASF > >> > member hat on, rather than as somebody who wanted to directly > contribute > >> > to where the technology was going. My concern during your incubation > >> days > >> > was (and still is!) how well are you guys doing on the community > >> development > >> > front. > >> > > >> > If you recall, the diversity requirement (the fact that more than 80% > >> of project > >> > members work for the same company) came up during our graduation. > While > >> > it wasn't a blocking requirement it still was a very valid concern. > >> Monocultures > >> > are really nasty for open source communities. > >> > > >> > I think it would be fair to say that Ignite community hasn't really > >> > improved much > >> > diversity-wise since its graduation. And I honestly feel that this is, > >> > to a larger > >> > extent, because the focus is now missing. It was well understood that > >> in order > >> > to graduate the community had to do all it can to demonstrate a > >> > positive trajectory > >> > in that direction. And we did. But we kind of dropped the ball on it > >> since. > >> > > >> > With that in mind, I offer my view on what a change in the Chair could > >> > offer: a renewed > >> > focus on community growth and development. If you agree with this > >> premise than > >> > somebody like Branko or Cos who could act as a forcing function to > >> constantly > >> > remind us about what else can we do to grow and develop this community > >> would > >> > be an ideal choice for the Chair (after all Branko's "tough love" was > >> > probably the > >> > most useful part of Ignite's experience in the Incubator). > >> > > >> > Now, of course, strictly speaking you don't have to be a Chair to do > >> > that. But lets > >> > face it -- that helps. And besides, a project's Chair doesn't really > >> > have any special > >> > powers when it comes to technological consensus, but anything that has > >> to do > >> > with external community the VP title that the chair gets can help > quite > >> a bit. > >> > > >> > Long story short: if Branko or Cos (as former mentors) would like to > >> > commit to 6 more > >> > months of the same hands-on mentorship focused on community > development > >> -- they > >> > would have my wholehearted support. > >> > > >> > Thanks, > >> > Roman (with my PMC member hat on). > >> > > > > > -- - Denis
Re: [DISCUSS] Pub/Sub Streamer Implementation
Hello, As discussed I have created following discussion threads on our migration proposals for Apache Ignite extensions: http://apache-ignite-users.70518.x6.nabble.com/DISCUSS-Proposal-for-Ignite-Extensions-as-a-separate-Bahir-module-or-Incubator-project-td29829.html https://www.mail-archive.com/dev@bahir.apache.org/msg02703.html I will share update as I hear more information. Regards, Saikat On Fri, Oct 18, 2019 at 9:03 PM Saikat Maitra wrote: > Hello Denis, > > Sure, sounds good. I will create a separate discussion thread to get > community feedback on whether we > should join the Bahir or kick-off "Ignite Extensions" project. > > Regards, > Saikat > > On Thu, Oct 17, 2019 at 2:21 PM Denis Magda wrote: > >> Folks, >> >> The concept of Apache Bahir is precisely what we need! Saikat, thanks for >> doing the research. Why I believe the * idea* fits us well: >> >>- All integrations can be stored in separate Github repositories and >>have their dev lifecycles. We've not obliged to couple all the >> integrations >>in a single repo. For instance, Spark can be located in a dedicated >> repo >>while streaming integrations might be in a single one. It's up to us. >>- All the repositories and integrations belong to ASF. We're not >> dumping >>them on Github but rather keep supporting and developing in accordance >> with >>ASF vision and practices. >>- There is a way to reward contributors via committership and PMC >>membership. You won't get this if a project is just one of the >> millions of >>Github projects. >> >> Saikat, as Ignite PMC member, could you please kick-off a separate >> dev-list >> discussion to involve more community members and referring to this thread? >> I think the primary question the community needs to answer whether we >> should join the Bahir or kick-off "Ignite Extensions" project? >> >> - >> Denis >> >> >> On Thu, Oct 17, 2019 at 2:54 AM Alexey Zinoviev >> wrote: >> >> > Maybe we could move all our Streaming Integrations there, but what is >> about >> > maintaining and committer permissions to the new repositories? >> > I see the list of the committers and PMC members there >> > https://bahir.apache.org/community-members/ >> > >> > Could somebody from Ignite community be added to this list as a >> > PMC/committer to maintain Ignite integrations? >> > If yes, I'd happy to join this project and collaborate with these guys >> > together >> > If no, and we should start from the zero level with external PRs - hmmm, >> > it's better to have our own external repository with ApacheBahirr >> ideology. >> > >> > Also, I agree, that all connectors could be moved there (in ApacheBahirr >> > like repository), but not all modules from the page >> > >> > >> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IndependentIntegrations >> > because >> > they use different parts of core modules and could be developed with >> > different velocity. >> > >> > In reality, before creation of new repositories we need wide discussion >> > based on the document mentioned above. >> > >> > P.S. Of course, we could experiment in the next release 2.8 with one or >> two >> > integrations like twitter or ZeroMQ >> > Also, I'd like Denis Magda idea for the separate repositories in Apache >> > Github to maintain them by anybody. >> > >> > >> > чт, 17 окт. 2019 г. в 05:02, Saikat Maitra : >> > >> > > Hi Denis, Emmanouil >> > > >> > > Thank you for your email. I think creating a separate integration >> project >> > > in github and also proposing it as an apache incubator project will >> be a >> > > good move. The other separate integration modules >> > > >> > > >> > >> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IndependentIntegrations >> > > can >> > > be moved to this new apache incubator project. >> > > >> > > There are similar integration available for Flink and Spark in Apache >> > Bahir >> > > https://bahir.apache.org/ >> > > >> > > Do you think we should reach out to Apache Bahir community with a >> > proposal >> > > or we should plan to create a separate Apache Incubator project? >> > > >> > > Regards, >> > > Saikat >> > > >> > > >> > > >> > > On Wed, Oct 16, 2019 at 6:21 AM Emmanouil Gkatziouras < >> > > gkatzio...@gmail.com> >> > > wrote: >> > > >> > > > Hi all! >> > > > >> > > > Based on the discussions most probably this is going to be on >> another >> > > > GitHub repo. Therefore I will prepare a standalone project with the >> > > Pub/Sub >> > > > module and once the repository is created a pull request shall be >> > issued. >> > > > If there is anything else I can do in order to facilitate this >> please >> > let >> > > > me know. >> > > > >> > > > If a ticket is created for this issue, I shall be able to create a >> pull >> > > > request and thus a build will take place on ignite's CI. >> > > > If everyone is aligned with adding a Pub/Sub implementation may I
Re: Write access to Apache Ignite Confluence
I found someone has granted permission to Denis Garus. Could you confirm everything is ok? вт, 15 окт. 2019 г. в 10:12, Denis Garus : > Hi, Igniters! > > I'd like to add a new wiki page with IEP for the Sandbox feature. > > Could someone grant me (Denis Garus) write permission? >
Re: Text queries/indexes (GridLuceneIndex, @QueryTextFiled)
Hi Andrey, I've checked this ticket comments, and there is a TC Bot visa (with no blockers). Do you have any concerns related to this patch? Sincerely, Dmitriy Pavlov чт, 17 окт. 2019 г. в 16:43, Yuriy Shuliga : > Andrey, > > Per you request, I created ticket > https://issues.apache.org/jira/browse/IGNITE-12291 linked to > https://issues.apache.org/jira/projects/IGNITE/issues/IGNITE-12189 > > Could you please proceed with PR merge ? > > BR, > Yuriy Shuliha > > ср, 9 жовт. 2019 о 12:52 Andrey Mashenkov > пише: > > > Hi Yuri, > > > > To get access to TC Bot you should register as TeamCity user [1], if you > > didn't do this already. > > Then you will be able to authorize on Ignite TC Bot page with same > > credentials. > > > > [1] https://ci.ignite.apache.org/registerUser.html > > > > On Fri, Oct 4, 2019 at 3:10 PM Yuriy Shuliga wrote: > > > >> Andrew, > >> > >> I have corrected PR according to your notes. Please review. > >> What will be the next steps in order to merge in? > >> > >> Y. > >> > >> чт, 3 жовт. 2019 о 17:47 Andrey Mashenkov > >> пише: > >> > >> > Yuri, > >> > > >> > I've done with review. > >> > No crime found, but trivial compatibility bug. > >> > > >> > On Thu, Oct 3, 2019 at 3:54 PM Yuriy Shuliga > wrote: > >> > > >> > > Denis, > >> > > > >> > > Thank you for your attention to this. > >> > > as for now, the https://issues.apache.org/jira/browse/IGNITE-12189 > >> > ticket > >> > > is still pending review. > >> > > Do we have a chance to move it forward somehow? > >> > > > >> > > BR, > >> > > Yuriy Shuliha > >> > > > >> > > пн, 30 вер. 2019 о 23:35 Denis Magda пише: > >> > > > >> > > > Yuriy, > >> > > > > >> > > > I've seen you opening a pull-request with the first changes: > >> > > > https://issues.apache.org/jira/browse/IGNITE-12189 > >> > > > > >> > > > Alex Scherbakov and Ivan are you the right guys to do the review? > >> > > > > >> > > > - > >> > > > Denis > >> > > > > >> > > > > >> > > > On Fri, Sep 27, 2019 at 8:48 AM Павлухин Иван < > vololo...@gmail.com> > >> > > wrote: > >> > > > > >> > > > > Yuriy, > >> > > > > > >> > > > > Thank you for providing details! Quite interesting. > >> > > > > > >> > > > > Yes, we already have support of distributed limit and merging > >> sorted > >> > > > > subresults for SQL queries. E.g. ReduceIndexSorted and > >> > > > > MergeStreamIterator are used for merging sorted streams. > >> > > > > > >> > > > > Could you please also clarify about score/relevance? Is it > >> provided > >> > by > >> > > > > Lucene engine for each query result? I am thinking how to do > >> sorted > >> > > > > merge properly in this case. > >> > > > > > >> > > > > ср, 25 сент. 2019 г. в 18:56, Yuriy Shuliga >: > >> > > > > > > >> > > > > > Ivan, > >> > > > > > > >> > > > > > Thank you for interesting question! > >> > > > > > > >> > > > > > Text searches (or full text searches) are mostly > human-oriented. > >> > And > >> > > > the > >> > > > > > point of user's interest is topmost part of response. > >> > > > > > Then user can read it, evaluate and use the given records for > >> > further > >> > > > > > purposes. > >> > > > > > > >> > > > > > Particularly in our case, we use Ignite for operations with > >> > financial > >> > > > > data, > >> > > > > > and there lots of text stuff like assets names, fin. > >> instruments, > >> > > > > companies > >> > > > > > etc. > >> > > > > > In order to operate with this quickly and reliably, users used > >> to > >> > > work > >> > > > > with > >> > > > > > text search, type-ahead completions, suggestions. > >> > > > > > > >> > > > > > For this purposes we are indexing particular string data in > >> > separate > >> > > > > caches. > >> > > > > > > >> > > > > > Sorting capabilities and response size limitations are very > >> > important > >> > > > > > there. As our API have to provide most relevant information in > >> view > >> > > of > >> > > > > > limited size. > >> > > > > > > >> > > > > > Now let me comment some Ignite/Lucene perspective. > >> > > > > > Actually Ignite queries and Lucene returns *TopDocs.scoresDocs > >> > > *already > >> > > > > > sorted by *score *(relevance). So most relevant documents are > on > >> > the > >> > > > top. > >> > > > > > And currently distributed queries responses from different > nodes > >> > are > >> > > > > merged > >> > > > > > into final query cursor queue in arbitrary way. > >> > > > > > So in fact we already have the score order ruined here. Also > >> Ignite > >> > > > > > requests all possible documents from Lucene that is redundant > >> and > >> > not > >> > > > > good > >> > > > > > for performance. > >> > > > > > > >> > > > > > I'm implementing *limit* parameter to be part of *TextQuery > *and > >> > have > >> > > > to > >> > > > > > notice that we still have to add sorting for text queries > >> > processing > >> > > in > >> > > > > > order to have applicable results. > >> > > > > > > >> > > > > > *Limit* parameter itself should improve the part of issues > from > >> > > above, >
Re: Binary object format KB article
Hi Ivan, Thank you for expanding our knowledge base. Sincerely, Dmitriy Pavlov пт, 18 окт. 2019 г. в 12:39, Igor Sapego : > Great job, > > I think we should have details like this in documentation, not only in wiki > > Denis, what do you think? > > Best Regards, > Igor > > > On Wed, Oct 16, 2019 at 7:19 PM Ivan Pavlukhin > wrote: > > > Sergey, > > > > Thank you for a review! > > > > > It seems to me that document tries to focus on details of the format > > itself but other aspects of this functionality leak into the explanation > > and confuses reader. > > > > You are absolutely right, it was an original idea. I will try to > > define a terminology and clarify things about schemas. > > > > ср, 16 окт. 2019 г. в 16:49, Sergey Chugunov >: > > > > > > Then I would suggest to define good terminology at the very beginning > of > > > the article. > > > > > > Right in introduction section I see a lot of terms like "Binary object > > > format", "Binary object container format" (is it the same thing?), > > "Binary > > > serialization format". In the next section "binary type" pops up. What > > are > > > the relations between them? > > > > > > Schemes part needs more examples. What is scheme? How it is related to > > > binary type? Is it a one-to-one relationship? One-to-many? When a new > > > scheme is created? Why type and scheme should be registered on a > receiver > > > side? And if the receiver exists then who is the sender? > > > > > > It seems to me that document tries to focus on details of the format > > itself > > > but other aspects of this functionality leak into the explanation and > > > confuses reader. > > > > > > On Wed, Oct 16, 2019 at 2:52 PM Ivan Pavlukhin > > wrote: > > > > > > > Pavel, Sergey, > > > > > > > > Thank you for your feedback! > > > > > > > > To be exact the document does not describe broad picture (including > > > > metadata exchange) and is not a formal format specification > > > > intentionally. I wanted to create a lightweight article giving an > > > > intuition about binary object structure to a reader. And yes, > > > > intuition about metadata registration is definitely an important, > > > > related but slightly different subject. > > > > > > > > ср, 16 окт. 2019 г. в 14:23, Sergey Chugunov < > > sergey.chugu...@gmail.com>: > > > > > > > > > > Ivan, thank you for documenting this functionality, agree with > Pavel > > > > here. > > > > > > > > > > I think this document is a good starting point and contains a lot > of > > > > > low-level details and great examples but from my perspective it > > doesn't > > > > > show how binary objects fit into a broader picture. > > > > > > > > > > It worth adding higher-level details and restructure the document > > into a > > > > > top-down article starting from where binary format is used > > > > (representation > > > > > of objects in cache, binary protocol for communications with thin > > > > clients) > > > > > and down to lower details like binary metadata exchange and > > serialization > > > > > and container formats. > > > > > > > > > > Another option would be to leave the document focused on a > low-level > > > > > details as it is now but build around it drafts for documents > > describing > > > > > other aspects of Binary Objects. > > > > > This will make our documentation much more solid and useful for > > readers. > > > > > > > > > > On Wed, Oct 16, 2019 at 2:07 PM Pavel Tupitsyn < > ptupit...@apache.org > > > > > > > wrote: > > > > > > > > > > > Ivan, great job, thanks for putting this together. > > > > > > > > > > > > I think we also need a more formal description of the format, > > including > > > > > > binary metadata exchange mechanics. > > > > > > It was done (partially) for IEP-9 Thin Client Protocol, we should > > > > probably > > > > > > copy from there: > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-9+Thin+Client+Protocol#IEP-9ThinClientProtocol-BinaryObjects > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Oct 16, 2019 at 11:49 AM Ivan Pavlukhin < > > vololo...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > I published a document about Binary format in cwiki [1]. Please > > share > > > > > > > your feedback. I feel that there is a lack of pictures on the > > page. > > > > > > > Need to figure out what aspects will be more clear with > pictures. > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Binary+object+format > > > > > > > > > > > > > > -- > > > > > > > Best regards, > > > > > > > Ivan Pavlukhin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Best regards, > > > > Ivan Pavlukhin > > > > > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > >
[jira] [Created] (IGNITE-12315) In case of using ArrayBlockingQueue as key, cache.get() returns null.
Alexander Lapin created IGNITE-12315:
Summary: In case of using ArrayBlockingQueue as key, cache.get()
returns null.
Key: IGNITE-12315
URL: https://issues.apache.org/jira/browse/IGNITE-12315
Project: Ignite
Issue Type: Bug
Reporter: Alexander Lapin
In case of using ArrayBlockingQueue as key, cache.get() returns null. In case
of using ArrayList or LinkedList everything works as expected.
{code:java}
ArrayBlockingQueue queueToCheck = new ArrayBlockingQueue<>(5);
queueToCheck.addAll(Arrays.asList(1, 2, 3));
cache.put(queueToCheck, "aaa");
cache.put(queueToCheck); // returns null
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12314) Unexpected return type in case of retrieving Byte[]{1,2,3} from cache value.
Alexander Lapin created IGNITE-12314:
Summary: Unexpected return type in case of retrieving
Byte[]{1,2,3} from cache value.
Key: IGNITE-12314
URL: https://issues.apache.org/jira/browse/IGNITE-12314
Project: Ignite
Issue Type: Bug
Reporter: Alexander Lapin
Unexpected return type in case of retrieving Byte[]\{1,2,3} from cache value:
{color:#172b4d}{{cache.{color:#172b4d}put{color}({color:#36b37e}"aaa"{color},
{color:#0052cc}new{color} {color:#6554c0}Byte{color}[]
{{color:#0052cc}1{color}, {color:#0052cc}2{color}, {color:#0052cc}3{color}});
cache.{color:#172b4d}get{color}({color:#36b37e}"aaa"{color});}}{color}
Byte[3]@... expected with corresponding content, however Object[3]@... got.
Seems that it's related to primitive wrapers, cause String[] as value works as
expected:
{color:#172b4d}{{cache.{color:#172b4d}put{color}({color:#36b37e}"aaa"{color},
{color:#0052cc}new{color} {color:#6554c0}String{color}[]
{{color:#36b37e}"1"{color}, {color:#36b37e}"2"{color},
{color:#36b37e}"3"{color}});
cache.{color:#172b4d}get{color}({color:#36b37e}"aaa"{color});}}{color}
Arrays of primitives also works as expected:
{color:#172b4d}{{cache.{color:#172b4d}put{color}({color:#36b37e}"aaa"{color},
{color:#0052cc}new{color} {color:#0052cc}byte{color}[]
{{color:#0052cc}1{color}, {color:#0052cc}2{color}, {color:#0052cc}3{color}});
cache.{color:#172b4d}get{color}({color:#36b37e}"aaa"{color});}}{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12313) Unable to update value via sql update query if a key is a byte array within non-mvcc mode.
Alexander Lapin created IGNITE-12313:
Summary: Unable to update value via sql update query if a key is a
byte array within non-mvcc mode.
Key: IGNITE-12313
URL: https://issues.apache.org/jira/browse/IGNITE-12313
Project: Ignite
Issue Type: Bug
Reporter: Alexander Lapin
{code:java}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: [B
cannot be cast to java.lang.Comparable
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2350)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2283)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2210)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2183)
at
org.apache.ignite.sqltests.SqlDataTypesCoverageTests.checkCRUD(SqlDataTypesCoverageTests.java:381)
at
org.apache.ignite.sqltests.SqlDataTypesCoverageTests.checkBasicSqlOperations(SqlDataTypesCoverageTests.java:335)
at
org.apache.ignite.sqltests.SqlDataTypesCoverageTests.testBinaryDataType(SqlDataTypesCoverageTests.java:269)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2075)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.IgniteCheckedException: [B cannot be cast to
java.lang.Comparable
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2828)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$1(GridQueryProcessor.java:2309)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2347)
... 17 more
Caused by: java.lang.ClassCastException: [B cannot be cast to
java.lang.Comparable
at
org.apache.ignite.internal.binary.BinaryObjectImpl.compareForDml(BinaryObjectImpl.java:863)
at
org.apache.ignite.internal.processors.query.h2.dml.DmlBatchSender$BatchEntryComparator.compare(DmlBatchSender.java:423)
at java.util.TreeMap.compare(TreeMap.java:1295)
at java.util.TreeMap.put(TreeMap.java:538)
at
org.apache.ignite.internal.processors.query.h2.dml.DmlBatchSender$Batch.put(DmlBatchSender.java:368)
at
org.apache.ignite.internal.processors.query.h2.dml.DmlBatchSender.add(DmlBatchSender.java:118)
at
org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.doUpdate(DmlUtils.java:252)
at
org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.processSelectResult(DmlUtils.java:168)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdateNonTransactional(IgniteH2Indexing.java:2765)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdate(IgniteH2Indexing.java:2625)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdateDistributed(IgniteH2Indexing.java:2555)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeDml(IgniteH2Indexing.java:1167)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1093)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2293)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2289)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:35)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2805)
... 19 more
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12312) JDBC thin: it's not possible to use LocalDate/LocalTime/LocalDateTime as value in where _key=.
Alexander Lapin created IGNITE-12312:
Summary: JDBC thin: it's not possible to use
LocalDate/LocalTime/LocalDateTime as value in where _key=.
Key: IGNITE-12312
URL: https://issues.apache.org/jira/browse/IGNITE-12312
Project: Ignite
Issue Type: Bug
Reporter: Alexander Lapin
JDBC thin: it's not possible to use LocalDateTime (converted internally to
java.sql.Timestamp) as value in where _key=.
In case of following query
{color:#172b4d}{{stmt.{color:#172b4d}executeQuery{color}({color:#36b37e}"SELECT
* FROM "{color} + tableName +{color:#36b37e}" where _key >=
PARSEDATETIME('2019-09-05 17:43:01.144', '-MM-dd HH:mm:ss.SSS') and _key <=
PARSEDATETIME('2019-09-05 17:43:01.144', '-MM-dd
HH:mm:ss.SSS')"{color});}}{color}
expected row would be returned, however in case of
{color:#172b4d}{{stmt.{color:#172b4d}executeQuery{color}({color:#36b37e}"SELECT
* FROM "{color} + tableName +{color:#36b37e}" where _key =
PARSEDATETIME('2019-09-05 17:43:01.144', '-MM-dd
HH:mm:ss.SSS')"{color});}}{color}
no rows would be returned.
Reproducers:
org.apache.ignite.jdbc.thin.JdbcThinCacheToJdbcDataTypesCoverageTest#testLocalDateTimeDataType
org.apache.ignite.jdbc.thin.JdbcThinCacheToJdbcDataTypesCoverageTest#testLocalTimeDataType
org.apache.ignite.jdbc.thin.JdbcThinCacheToJdbcDataTypesCoverageTest#testLocalDateDataType
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12311) DELETE by PK doesn't work if PK is TINYINT or SMALLINT.
Alexander Lapin created IGNITE-12311:
Summary: DELETE by PK doesn't work if PK is TINYINT or SMALLINT.
Key: IGNITE-12311
URL: https://issues.apache.org/jira/browse/IGNITE-12311
Project: Ignite
Issue Type: Bug
Reporter: Alexander Lapin
1. Start bin\ignite.bat
2. Start bin\sqlline.bat -d org.apache.ignite.IgniteJdbcThinDriver -u
jdbc:ignite:thin://127.0.0.1/distributedJoins=true
3. Execute operations:
{color:#172b4d}{{{color:#0052cc}0{color}:
jdbc:ignite:thin://{color:#0052cc}127.0{color}{color:#0052cc}.0{color}{color:#0052cc}.1{color}/>
create table t1 (a tinyint {color:#0052cc}null{color} primary key, b
VARCHAR);{color:#6554c0}No{color} rows affected
({color:#0052cc}0{color},{color:#0052cc}198{color}
seconds){color:#0052cc}0{color}:
jdbc:ignite:thin://{color:#0052cc}127.0{color}{color:#0052cc}.0{color}{color:#0052cc}.1{color}/>
insert into t1 values ({color:#0052cc}1{color},
{color:#36b37e}'a'{color});{color:#0052cc}1{color} row affected
({color:#0052cc}0{color},{color:#0052cc}036{color}
seconds){color:#0052cc}0{color}:
jdbc:ignite:thin://{color:#0052cc}127.0{color}{color:#0052cc}.0{color}{color:#0052cc}.1{color}/>
select * from
t1;+++|
{color:#6554c0}A{color}|
{color:#6554c0}B{color}
|+++|
{color:#0052cc}1{color} | a
|+++{color:#0052cc}1{color}
row selected ({color:#0052cc}0{color},{color:#0052cc}048{color}
seconds){color:#0052cc}0{color}:
jdbc:ignite:thin://{color:#0052cc}127.0{color}{color:#0052cc}.0{color}{color:#0052cc}.1{color}/>
update t1 set b = {color:#36b37e}'b'{color} where
a={color:#0052cc}1{color};{color:#0052cc}1{color} row affected
({color:#0052cc}0{color},{color:#0052cc}018{color}
seconds){color:#0052cc}0{color}:
jdbc:ignite:thin://{color:#0052cc}127.0{color}{color:#0052cc}.0{color}{color:#0052cc}.1{color}/>
select * from
t1;+++|
{color:#6554c0}A{color}|
{color:#6554c0}B{color}
|+++|
{color:#0052cc}1{color} | b
|+++{color:#0052cc}1{color}
row selected ({color:#0052cc}0{color},{color:#0052cc}006{color}
seconds){color:#0052cc}0{color}:
jdbc:ignite:thin://{color:#0052cc}127.0{color}{color:#0052cc}.0{color}{color:#0052cc}.1{color}/>
delete from t1 where a={color:#0052cc}1{color};{color:#6554c0}No{color} rows
affected ({color:#0052cc}0{color},{color:#0052cc}003{color}
seconds){color:#0052cc}0{color}:
jdbc:ignite:thin://{color:#0052cc}127.0{color}{color:#0052cc}.0{color}{color:#0052cc}.1{color}/>
select * from
t1;+++|
{color:#6554c0}A{color}|
{color:#6554c0}B{color}
|+++|
{color:#0052cc}1{color} | b
|+++{color:#0052cc}1{color}
row selected ({color:#0052cc}0{color},{color:#0052cc}006{color}
seconds){color:#0052cc}0{color}:
jdbc:ignite:thin://{color:#0052cc}127.0{color}{color:#0052cc}.0{color}{color:#0052cc}.1{color}/>}}{color}
Same behavoir is for SMALLINT type
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12310) SortedEvictionPolicy fails with java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang. in case of Byte, Short, Long, etc.
Alexander Lapin created IGNITE-12310:
Summary: SortedEvictionPolicy fails with
java.lang.ClassCastException: java.lang.Integer cannot be cast to
java.lang. in case of Byte, Short, Long, etc.
Key: IGNITE-12310
URL: https://issues.apache.org/jira/browse/IGNITE-12310
Project: Ignite
Issue Type: Bug
Reporter: Alexander Lapin
{code:java}
java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.Integer
at java.lang.Integer.compareTo(Integer.java:52)
at
org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicy$DefaultHolderComparator.compare(SortedEvictionPolicy.java:359)
at
org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicy$DefaultHolderComparator.compare(SortedEvictionPolicy.java:347)
at
java.util.concurrent.ConcurrentSkipListMap.cpr(ConcurrentSkipListMap.java:655)
at
java.util.concurrent.ConcurrentSkipListMap.doPut(ConcurrentSkipListMap.java:835)
at
java.util.concurrent.ConcurrentSkipListMap.putIfAbsent(ConcurrentSkipListMap.java:1979)
at
org.apache.ignite.internal.util.GridConcurrentSkipListSet.add(GridConcurrentSkipListSet.java:142)
at
org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicy$GridConcurrentSkipListSetEx.add(SortedEvictionPolicy.java:397)
at
org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicy.touch(SortedEvictionPolicy.java:175)
at
org.apache.ignite.cache.eviction.AbstractEvictionPolicy.onEntryAccessed(AbstractEvictionPolicy.java:87)
at
org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.notifyPolicy(GridCacheEvictionManager.java:319)
at
org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(GridCacheEvictionManager.java:228)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.touch(GridCacheMapEntry.java:5052)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(GridDhtAtomicCache.java:3104)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1905)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.map(GridNearAtomicUpdateFuture.java:814)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapOnTopology(GridNearAtomicUpdateFuture.java:666)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAll0(GridDhtAtomicCache.java:1104)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAll0(GridDhtAtomicCache.java:654)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAll(GridCacheAdapter.java:2513)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.putAll(IgniteCacheProxyImpl.java:1264)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.putAll(GatewayProtectedCacheProxy.java:863)
at
org.apache.ignite.internal.processors.cache.GridCacheDataTypesCoverageTest.checkBasicCacheOperations(GridCacheDataTypesCoverageTest.java:624)
at
org.apache.ignite.internal.processors.cache.GridCacheDataTypesCoverageTest.testLongDataType(GridCacheDataTypesCoverageTest.java:347)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2075)
at java.lang.Thread.run(Thread.java:748)
[2019-08-23 12:26:39,784][INFO ][main][root] >>>
[jira] [Created] (IGNITE-12309) Tinyint cassandra type not supported
jifwin created IGNITE-12309: --- Summary: Tinyint cassandra type not supported Key: IGNITE-12309 URL: https://issues.apache.org/jira/browse/IGNITE-12309 Project: Ignite Issue Type: Bug Reporter: jifwin I tried to use Ignite as a read-through layer for my existing Cassandra table. The table has a compound primary key: some strings, tinyint and frozenmap. I've run into problems with key (POJO) creation due to missing codec for both tinyint and map. For tinyint I tried a few java types: byte, short, int. All of them resulted in exception thrown from cassandra driver about missing tinyint -> Byte/Short/Integer codec. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12308) Data types coverage for basic sql operations.
Alexander Lapin created IGNITE-12308: Summary: Data types coverage for basic sql operations. Key: IGNITE-12308 URL: https://issues.apache.org/jira/browse/IGNITE-12308 Project: Ignite Issue Type: Task Components: sql Reporter: Alexander Lapin Fix For: 2.8 For more details see: https://issues.apache.org/jira/browse/IGNITE-12307 -- This message was sent by Atlassian Jira (v8.3.4#803005)
RE: Documents about C++/C#/.NET
GridGain had released new documentation just a couple of weeks ago. It should contain updated content with multilanguage examples. Feel free to review the same article regarding eviction policies [1] [1] https://www.gridgain.com/docs/8.7.6/developers-guide/memory-architecture/eviction-policies From: 李玉珏@163 Sent: Monday, October 21, 2019 3:41 PM To: dev@ignite.apache.org Subject: Re: Documents about C++/C#/.NET Hi Ilya, Many simple problems, I have submitted suggest edits, and most of them have been accepted. But for example, the following page: https://apacheignite-net.readme.io/docs/eviction-policies I believe that many of the contents are outdated and many links are invalid. A lot of content on this page needs to be re edited. I think it is more appropriate for the original author to do this work, because he knows more about this aspect. 在 2019/10/21 下午8:00, Ilya Kasnacheev 写道: > Hello! > > I think it is a good idea to refer to Java documentation on same topic and > keed duplication of content to minimum. > > Please to not hesitate to suggest edits for main Ignite documentation on > readme.io! > > Thank you for your effort! > > Regards,
[jira] [Created] (IGNITE-12307) Data types coverage for basic cache operations.
Alexander Lapin created IGNITE-12307: Summary: Data types coverage for basic cache operations. Key: IGNITE-12307 URL: https://issues.apache.org/jira/browse/IGNITE-12307 Project: Ignite Issue Type: Task Components: cache Reporter: Alexander Lapin Fix For: 2.8 The data types used for testing are not collected at single test/suite and it's not clear which types are covered and which not. We should redesign the coverage and cover following Operations: * put * putAll * remove * removeAll * get * getAll Data Types both for value and key (if applicable): * byte/Byte * short/Short * int/Integer * long/Long * float/Float * double/Double * boolean/Boolean * char/String * Arrays of primitives (single type) * Arrays of Objects (different types) * Collections ** List ** Queue ** Set * Objects based on: ** primitives only ** primitives + collections ** primitives + collections + nested objects Persistance mode: * in-memory * PDS Cache configurations: * atomic/tx/mvcc * replication/partitioned * TTL/no TTL * QueryEntnty * Backups=1,2 * EvictionPolicy * writeSynchronizationMode(FULL_SYNC, PRIMARY_SYNC, FULL_ASYNC) * onheapCacheEnabled -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12306) .NET: Java version is not taken into account when detecting JAVA_HOME
Pavel Tupitsyn created IGNITE-12306: --- Summary: .NET: Java version is not taken into account when detecting JAVA_HOME Key: IGNITE-12306 URL: https://issues.apache.org/jira/browse/IGNITE-12306 Project: Ignite Issue Type: Bug Components: platforms Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 2.8 When multiple Java versions are installed on the machine, random one is picked up. For example, when 7 and 8 are installed, only 8 is suitable for Ignite. We should check versions and pick the right one: * Collect all known versions * Filter out all below 8 * Pick the lowest Lower versions are prioritized - we don't want to use latest. Brand new Java version with breaking changes might be released where Ignite does not work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Documents about C++/C#/.NET
Hi Ilya, Many simple problems, I have submitted suggest edits, and most of them have been accepted. But for example, the following page: https://apacheignite-net.readme.io/docs/eviction-policies I believe that many of the contents are outdated and many links are invalid. A lot of content on this page needs to be re edited. I think it is more appropriate for the original author to do this work, because he knows more about this aspect. 在 2019/10/21 下午8:00, Ilya Kasnacheev 写道: Hello! I think it is a good idea to refer to Java documentation on same topic and keed duplication of content to minimum. Please to not hesitate to suggest edits for main Ignite documentation on readme.io! Thank you for your effort! Regards,
[jira] [Created] (IGNITE-12305) Extend test coverage [IGNITE-11959] NullPointerException If transaction failed and failure handler doesn't configured explicitly
Kirill Tkalenko created IGNITE-12305: Summary: Extend test coverage [IGNITE-11959] NullPointerException If transaction failed and failure handler doesn't configured explicitly Key: IGNITE-12305 URL: https://issues.apache.org/jira/browse/IGNITE-12305 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 2.8 -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Documents about C++/C#/.NET
Hello! I think it is a good idea to refer to Java documentation on same topic and keed duplication of content to minimum. Please to not hesitate to suggest edits for main Ignite documentation on readme.io! Thank you for your effort! Regards, -- Ilya Kasnacheev вс, 20 окт. 2019 г. в 04:11, 李玉珏@163 <18624049...@163.com>: > Hi community, > > I am currently working on translating the documents of C++/ C#/.NET into > chinese. > > At present, it is found that this part of the document has a lot of > expired content, or even mistakes. > > Because the Java version is still developing rapidly, it is obviously a > heavy workload to maintain the consistency of multiple sets of documents. > > So for the C++/.NET version of documents, I have following improvement > schemes: > > In addition to the necessary differences in installation and deployment, > for the same part of technology and concept, reduce unnecessary > description and focus on sample code. > > What's the community's opinion? > >
[jira] [Created] (IGNITE-12304) All DataRegionMetrics should be documented
Andrey Kuznetsov created IGNITE-12304:
-
Summary: All DataRegionMetrics should be documented
Key: IGNITE-12304
URL: https://issues.apache.org/jira/browse/IGNITE-12304
Project: Ignite
Issue Type: Task
Components: documentation
Reporter: Andrey Kuznetsov
Fix For: 2.8
All metrics added to {{DataRegionMetrics}} interface by [1] should be
documented.
[1] https://issues.apache.org/jira/browse/IGNITE-8078
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Review for IGNITE-12295
Hello, Sergey. I will take a look, shortly. Additional review of index experts will be very helpful. В Пн, 21/10/2019 в 11:46 +0300, Sergey Kalashnikov пишет: > Hello Igniters! > > I'm working on the improvement > https://issues.apache.org/jira/browse/IGNITE-12295 in scope of a larger > file-based rebalancing effort. > > The ticket is aimed on making partition eviction work faster by cleaning > the shared index trees in a scanning manner instead of searching and > removing every row. > > I've prepared the PR https://github.com/apache/ignite/pull/6982 with > changes demonstrating the approach. > > It is based on master and does not contain any specifics of file-based > rebalancing. So the new code is only used in tests for the moment. > > I would be grateful if someone could take a look at the changes and provide > any feedback on the code and/or general idea. > > Thanks a lot in advance. signature.asc Description: This is a digitally signed message part
Review for IGNITE-12295
Hello Igniters! I'm working on the improvement https://issues.apache.org/jira/browse/IGNITE-12295 in scope of a larger file-based rebalancing effort. The ticket is aimed on making partition eviction work faster by cleaning the shared index trees in a scanning manner instead of searching and removing every row. I've prepared the PR https://github.com/apache/ignite/pull/6982 with changes demonstrating the approach. It is based on master and does not contain any specifics of file-based rebalancing. So the new code is only used in tests for the moment. I would be grateful if someone could take a look at the changes and provide any feedback on the code and/or general idea. Thanks a lot in advance. -- Sergey
