Re: Update the rebalance configuration documentation
Hello Maxim, I'll take a look at this soon and make sure the documentation is up to date. Also, you're always welcome to make suggested edits to the readme.io page. Thanks! === Garrett Alley Documentation GridGain Systems On Tue, Aug 27, 2019 at 10:38 AM Maxim Muzafarov wrote: > Igniters, > > I'm worrying about updating the Ignite documentation. > > Can you advise who will or should update the Ignite documentation > rebalancing page [2] since the [1] issue has merged to the master > branch and some of the parameters have moved to the > IgniteConfiguration level? > > I've marked this issue [1] as `Docs Required` but should I make some > changes at readme.io page? > > [1] https://issues.apache.org/jira/browse/IGNITE-11821 > [2] https://apacheignite.readme.io/docs/rebalancing >
Re: Community week status: Aug 13 – Aug 20
Thanks, Denis! We'll take a look at those doc issues and create tickets soon. -g- === Garrett Alley Documentation GridGain Systems On Thu, Aug 22, 2019 at 8:30 AM Denis Mekhanikov wrote: > Hi everyone! > > The following threads created last week address potential issues in the > product. > > *Code issues:* > *Incomplete results of SQL queries with equality conditions on a primary > key.* JIRA ticket: https://issues.apache.org/jira/browse/IGNITE-12068 > StackOverflow question: > https://stackoverflow.com/questions/57479636/simple-select-query-missing-rows-in-ignite > The issue has already been fixed. > > *IgniteQueue.removeAll throws NPE.* Currently it’s unclear, why it > happens. Investigation is needed. > StackOverflow question: > https://stackoverflow.com/questions/57473783/ignite-2-5-ignitequeue-removeall-throwing-npe > Userlist thread: > http://apache-ignite-users.70518.x6.nabble.com/IgniteQueue-removeAll-throwing-NPE-td29072.html > > *Unclear error message in SQL.* > The following query results in an unclear error message: > > SELECT > CASE WHEN YEAR(A1) = 2016 THEN SUM(A2) END FROM > > Error: Failed to run reduce query locally. > StackOverflow question: > https://stackoverflow.com/questions/57472293/ignite-failed-to-run-reduce-query-locally > > *Async continuous queries in .NET generates Java threads, that never > finish.* JIRA: https://issues.apache.org/jira/browse/IGNITE-9638 > StackOverflow: > https://stackoverflow.com/questions/57513576/apache-ignite-spawns-too-much-threads > > *Hanging cache operations when async/await is used in .NET* > JIRA issue: https://issues.apache.org/jira/browse/IGNITE-12033 > Userlist thread: > http://apache-ignite-users.70518.x6.nabble.com/Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td27871.html > > *Metadata is stored in a work directory which is cleared on restarts.* > This issue has a long history, and users keep suffering from it. > StackOverflow: > https://stackoverflow.com/questions/57529702/ignite-persisting-a-set-cannot-find-metadata-for-object-with-compact-footer > > *SQL create schema support* > Userlist thread: > http://apache-ignite-users.70518.x6.nabble.com/Will-ignite-support-the-CREATE-SCHEMA-statement-td29078.html > > *Documentation:* > *Possible too long JVM pause.* > The error message appears in logs pretty often when people have issues > with garbage collection, and it doesn’t sound English. Should we fix the > message? > In any case, we should mention this message on a page about GC tuning. > StackOverflow question: > https://stackoverflow.com/questions/57541462/possible-too-long-jvm-pause > > *Run a script in SQLLine.* It would be nice to mention this ability in > the documentation. > StackOverflow question: > https://stackoverflow.com/questions/57483908/shell-script-to-connect-to-ignite > > *Backup filter vs Node filter. Rack awareness.* > The user in the thread bellow confused a backup filter in > RendezvousAffinityFunction with a node filter in CacheConfiguration. > Also the rack awareness topic was brought up in that thread. I noticed, > that we don’t have it documented. It’s a nice thing to mention in the docs. > Userlist thread: > http://apache-ignite-users.70518.x6.nabble.com/Cache-spreading-to-new-nodes-td29063.html > > Denis > >
Re: Coding guidelines. Useless JavaDoc comments.
Hello Igniters,
[A quick introduction: My name is Garrett and I manage documentation at
GridGain. I'm relatively new here — I've been at GridGain for 4 months —
but I've been in Documentation for most of my career.]
I put together some _proposed_ guidelines for Javadocs as a starting point
for us to discuss, *modify*, and hopefully eventually adopt.
These are based on what I've seen succeed at other companies/on the
internet:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=123900577
For me, the reason I prefer optional comments is that I don't want users to
have to wade through the obvious stuff to find the useful/insightful
information. If we can reduce the amount of comments, but still retain the
useful information, the readers will be rewarded.
Thanks!
===
Garrett Alley
Documentation
GridGain Systems
On Thu, Aug 8, 2019 at 7:52 AM Maxim Muzafarov wrote:
> Ivan,
>
> It is not a problem to check Javadocs at the moment code syle checking
> performed, but do we really need this? And the human-factor you
> mentioned above is also related to the `self-descriptive` names. I
> assume, that someone now is desiring to use single-letter variables
> and single-letter class names to save space an time. We will always
> have such an opinion race.
>
> I'd prefer to leave the current situation with Javadoc as it is and
> just to ask to apply the patch [1][2]. Can you? :-)
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12051
> [2] https://github.com/apache/ignite/pull/6760
>
> On Thu, 8 Aug 2019 at 17:24, Павлухин Иван wrote:
> >
> > Maxim,
> >
> > My main concern here is a human factor. Humans are usually not so good
> > in keeping documentation always in sync with a code. Examples from an
> > actual PR:
> > /**
> > * @param nodeId The remote node id.
> > * @param channel The channel to notify listeners with.
> > */
> > private void onChannelOpened0(UUID nodeId, GridIoMessage initMsg,
> > Channel channel)
> >
> > First, there is a mismatch between number of parameters in javadoc and
> > code. Second, e.g. nodeId name can be made self-descriptive rmtNodeId
> > name.
> >
> > Mandatory javadocs do not imply good javadocs. Good javadocs do not
> > imply javadocs for every method and field. For me, mandatory and good
> > javadocs are like communism. Sounds quite nice in theory, but not
> > feasible in practice.
> >
> > чт, 8 авг. 2019 г. в 16:55, Denis Garus :
> > >
> > > Thank you, Maxim.
> > >
> > > >>On what we are trying to save by making Javadoc optional?
> > >
> > > Space and time.
> > >
> > > I doubt that we need a verbal description of what private method make.
> > > Why we need it if we just can read the code?
> > >
> > > Bright examples:
> > >
> > > /**
> > > * @param helper Helper to attach to kernal context.
> > > */
> > > private void addHelper(Object helper) {
> > > ctx.addHelper(helper);
> > > }
> > >
> > > /**
> > > * Gets "on" or "off" string for given boolean value.
> > > *
> > > * @param b Boolean value to convert.
> > > * @return Result string.
> > > */
> > > private String onOff(boolean b) {
> > > return b ? "on" : "off";
> > > }
> > >
> > > You have to support both code of method and their JavaDoc description,
> but
> > > it doesn't get any sake.
> > >
> > > >>Let's just help them to read the source code.
> > >
> > > But at the same time, public method IgniteKernal#start doesn't have any
> > > description except enumeration of attributes with apparent notes.
> > > Maybe to give it a verbal description needs one or two pages of the
> screen.
> > > Does it make sense?
> > >
> > > чт, 8 авг. 2019 г. в 15:41, Maxim Muzafarov :
> > >
> > > > Igniters,
> > > >
> > > > I'm -1 with making Javadoc optional (except tests).
> > > >
> > > > Here is my patch [1] with PR [2] which fixes all the Javadoc comments
> > > > for the IgniteKernal class mentioned above. Please, take a look. The
> > > > review is very appreciated.
> > > >
> > > > On what we are trying to save by making Javadoc optional? In my
> humble
> > > > opinion - Javadoc comments are mostly concern users who debug the
> > > > Ignite when they have faced with some unhandled exception or related
> > > > to the community members with an average involvement (pr
Re: Ignite stops working suddenly during dev
Denis,
Minor changes to your suggestion:
*"ERROR: Type 'Person' has a different/incorrect type
for field 'salary'. Expected 'double' but 'string' was provided. Field
type's modification is unsupported, clean {root_path}/marshaller directory
if the type change is required."*
===
Garrett Alley
Documentation
GridGain Systems
On Wed, Jun 12, 2019 at 11:15 AM Denis Magda wrote:
> Alex, Garrett,
>
> How about this error message?
>
> That's what we have know: *ERROR: Binary type has different field types
> [typeName=Person, fieldName=salary, fieldTypeName1=double,
> fieldTypeName2=String]*
>
> That's how I would change it: *"Type 'Person' has different/incorrect type
> for field 'salary'. Expected 'double' but 'string' was provided. Field
> type's modification is unsupported, clean {root_path}/marshaller directory
> if the type change is required"*
>
> -
> Denis
>
>
> On Thu, Jun 6, 2019 at 5:24 AM Alexey Goncharuk <
> alexey.goncha...@gmail.com>
> wrote:
>
> > Hello Denis,
> >
> > As for p.1 - fully agree. For p.2 - I have some ideas to be implemented
> in
> > the future in Ignite 3.0, will share some ideas later.
> >
> > чт, 6 июн. 2019 г. в 13:29, Denis Magda :
> >
> > > Hey Igniters,
> > >
> > > I'd like us to brainstorm how to solve the following usability issue.
> > >
> > > A user starts developing an app and can change the data model via a
> > > configuration or DDL frequently. However, if there is an incompatible
> > data
> > > model change like a type/field modification Ignite will fail to restart
> > or
> > > begins throwing "wrong data type" exceptions.
> > >
> > > A solution for these scenarios is to clean the "marshaller/" folder.
> > Guess
> > > who knows this trick? A few of us. Had to do this all the time while
> > baking
> > > a demo for one of the recent shows and here is a good example of users'
> > > hardships:
> > >
> > >
> >
> https://stackoverflow.com/questions/56384773/apache-ignite-programmatically-destroy-persistent-cache
> > >
> > > How do you see this needs to be addressed considering:
> > >
> > >1. Current Ignite serialization format - a special message that
> > explains
> > >what to clean and where or some sort of automation?
> > >2. Future storage independent format - when binary serialization
> logic
> > >will be revisited. @Alex Goncharuk, please step in.
> > >
> > >
> > > -
> > > Denis
> > >
> >
>
Re: [Discussion] Documentation process improvement: Release notes
I like the flag, it would help cut down on the work involved in creating the release notes. Eventually, we may want to group the fixes "by component" in the release notes. -g- On Mon, May 20, 2019 at 4:28 AM Ilya Kasnacheev wrote: > Hello! > > I think it definitely makes sense to have Release Notes field in JIRA > tickets (start using it if it is already present?). Not sure about the > flag. > > Regards, > -- > Ilya Kasnacheev > > > пн, 20 мая 2019 г. в 13:23, Dmitriy Pavlov : > > > Hi Ignite Developers, > > > > Kindly Reminder, please review the proposed changes and share your > vision. > > I would appreciate if this change will be approved by community members, > > but not via silence. > > > > Sincerely > > Dmitriy Pavlov > > > > вт, 14 мая 2019 г. в 15:19, Dmitriy Pavlov : > > > > > Hi Igniters, > > > > > > During the preparation of release candidate 2.7.5, I’ve missed the > > > development of Release notes for it, and this caused delay for a vote. > > > > > > I want to suggest simple changes in our documentation process. Some > time > > > ago Artem B. proposed similar for the doc, but I would like to adapt it > > for > > > release notes. > > > > > > Let us > > > - Enrich Ignite flags with 'Release Notes required' flag (default is, > as > > > always, true) > > > - Add field 'Release Notes' to Ignite project. > > > > > > All tickets with empty Release Notes fields but with flag set may be > > > checked with contributor if it needs to be mentioned in > > RELEASE_NOTES.txt. > > > > > > If we agree on these changes, I’ll ask infra to add these fields in 3 > > > days. > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > > > >
