Re: Next release
Hi Mario, There is still some work to be done to ensure performance is on par with previous releases... here are a few tickets related to the efforts https://issues.apache.org/jira/browse/GEODE-7763 https://issues.apache.org/jira/browse/GEODE-7832 https://issues.apache.org/jira/browse/GEODE-7853 https://issues.apache.org/jira/browse/GEODE-7863 https://issues.apache.org/jira/browse/GEODE-6154 Best regards, EB On Mon, Mar 16, 2020 at 2:03 AM Mario Kevo wrote: > Hi geode-dev, > > When we will have Apache Geode 1.12.0 release? > I saw that all test passed and the last commit was before 4 days(typos > correct). > Are we waiting fix for some critical issue or something else? > > Thanks and BR, > Mario >
[DISCUSS] Client side configuration for a SNI proxy
Hi all, A new RFC is up for this feature https://cwiki.apache.org/confluence/display/GEODE/Client+side+configuration+for+a+SNI+proxy. Please review and comment by this Friday, 3/20/2020. This hopefully addresses some of the concerns with the previous RFC for this feature. The new proposal is for a more general SocketFactory property that users can implement, along the lines of what Jake and Owen suggested. -Dan
Server not starting for no good reason. Snapshot attached
Hi team, I use Eclipse OpenJ9 JDK 8 on Ubuntu machine & started Geode server with no locator running. (Even if locator is running, I get the same result as shown below) The process goes on and on with no termination and no possible clue. I had to kill the process to get terminal control. The same is the behavior when I start a locator successfully on the Ubuntu machine. I am able to telnet to the locator from my local machine. What mistake have I done? Please help. [image: image.png] Regards, Aj
Re: Discussion on Deprecation
> On Mar 16, 2020, at 8:50 AM, Dan Smith wrote: > > +1 > > One point though - we do need to leave some tests that specifically test > the deprecated method(s), since we still support the deprecated APIs until > we remove them. Everything else should be converted. +1 for sure. Those tests would be annotated with @SupressWarnings(“deprecation”) with a comment that they intentionally test the old methods and that the test should be deleted when the old methods are removed.
Re: Discussion on Deprecation
+1 on leaving testing of deprecated functionality in place
On Mon, Mar 16, 2020 at 11:50 AM Dan Smith wrote:
> +1
>
> One point though - we do need to leave some tests that specifically test
> the deprecated method(s), since we still support the deprecated APIs until
> we remove them. Everything else should be converted.
>
> -Dan
>
> On Sun, Mar 15, 2020 at 6:41 PM Jacob Barrett wrote:
>
> > Hey Team,
> >
> > When deprecating a symbol, like class or method, please included a
> > reference to the replacement in the java docs. Also please include an
> > example of converting from the old API to the new. I am finding many many
> > places in the source where deprecated code has no hints at all. As many
> of
> > us don’t take the effort to immediately convert old tests over to the new
> > APIs the context is lost when someone finally does get around to it. For
> > public APIs this is extremely important so that users know how to migrate
> > their code with as few roadblocks as possible.
> >
> > Here is an example of something that is much better than most of what I
> am
> > seeing.
> >
> > /**
> > * @deprecated Replaced with something better and safer.
> > * Replaced by {@link Bar}.
> > */
> > @Deprecated
> > class Foo {
> > /**
> >* Do something.
> >*
> >* @deprecated Replaced with something better.
> >* Replaced by {@link Bar#doSomethingBetter()}
> >*/
> > @Deprecated
> > public void doSomething() {}
> >
> > /**
> >* Do something.
> >*
> >* @deprecated Implementation is not safe.
> >* Replaced with {@link Bar#doSomethingBetter()} and {@link
> > Bar#doSomethingElse()}.
> >* Migration example, replace:
> >* {@code
> >* Foo foo = new Foo();
> >* foo.doSomethingAndSomethingElse();
> >* }
> >* with:
> >* {@code
> >* Bar bar = Bar();
> >* bar.doSomethingBetter();
> >* bar.doSomethingElse();
> >* }
> >*/
> > @Deprecated
> > public void doSomethingAndSomethingElse() {}
> > }
> >
> > class Bar {
> > public void doSomethingBetter() {}
> > public void doSomethingElse() {}
> > }
> >
> > -Jake
> >
> >
>
--
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427
“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
Re: Discussion on Deprecation
+1
One point though - we do need to leave some tests that specifically test
the deprecated method(s), since we still support the deprecated APIs until
we remove them. Everything else should be converted.
-Dan
On Sun, Mar 15, 2020 at 6:41 PM Jacob Barrett wrote:
> Hey Team,
>
> When deprecating a symbol, like class or method, please included a
> reference to the replacement in the java docs. Also please include an
> example of converting from the old API to the new. I am finding many many
> places in the source where deprecated code has no hints at all. As many of
> us don’t take the effort to immediately convert old tests over to the new
> APIs the context is lost when someone finally does get around to it. For
> public APIs this is extremely important so that users know how to migrate
> their code with as few roadblocks as possible.
>
> Here is an example of something that is much better than most of what I am
> seeing.
>
> /**
> * @deprecated Replaced with something better and safer.
> * Replaced by {@link Bar}.
> */
> @Deprecated
> class Foo {
> /**
>* Do something.
>*
>* @deprecated Replaced with something better.
>* Replaced by {@link Bar#doSomethingBetter()}
>*/
> @Deprecated
> public void doSomething() {}
>
> /**
>* Do something.
>*
>* @deprecated Implementation is not safe.
>* Replaced with {@link Bar#doSomethingBetter()} and {@link
> Bar#doSomethingElse()}.
>* Migration example, replace:
>* {@code
>* Foo foo = new Foo();
>* foo.doSomethingAndSomethingElse();
>* }
>* with:
>* {@code
>* Bar bar = Bar();
>* bar.doSomethingBetter();
>* bar.doSomethingElse();
>* }
>*/
> @Deprecated
> public void doSomethingAndSomethingElse() {}
> }
>
> class Bar {
> public void doSomethingBetter() {}
> public void doSomethingElse() {}
> }
>
> -Jake
>
>
Re: Discussion on Deprecation
+1
I think we should make it a habit to convert all Geode code as part of the
pull request that introduces the deprecation so that this is not left as a
low priority item for some later point in time.
Something to look for when reviewing pull requests IMO.
On Sun, Mar 15, 2020 at 9:41 PM Jacob Barrett wrote:
> Hey Team,
>
> When deprecating a symbol, like class or method, please included a
> reference to the replacement in the java docs. Also please include an
> example of converting from the old API to the new. I am finding many many
> places in the source where deprecated code has no hints at all. As many of
> us don’t take the effort to immediately convert old tests over to the new
> APIs the context is lost when someone finally does get around to it. For
> public APIs this is extremely important so that users know how to migrate
> their code with as few roadblocks as possible.
>
> Here is an example of something that is much better than most of what I am
> seeing.
>
> /**
> * @deprecated Replaced with something better and safer.
> * Replaced by {@link Bar}.
> */
> @Deprecated
> class Foo {
> /**
>* Do something.
>*
>* @deprecated Replaced with something better.
>* Replaced by {@link Bar#doSomethingBetter()}
>*/
> @Deprecated
> public void doSomething() {}
>
> /**
>* Do something.
>*
>* @deprecated Implementation is not safe.
>* Replaced with {@link Bar#doSomethingBetter()} and {@link
> Bar#doSomethingElse()}.
>* Migration example, replace:
>* {@code
>* Foo foo = new Foo();
>* foo.doSomethingAndSomethingElse();
>* }
>* with:
>* {@code
>* Bar bar = Bar();
>* bar.doSomethingBetter();
>* bar.doSomethingElse();
>* }
>*/
> @Deprecated
> public void doSomethingAndSomethingElse() {}
> }
>
> class Bar {
> public void doSomethingBetter() {}
> public void doSomethingElse() {}
> }
>
> -Jake
>
>
--
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427
“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
Next release
Hi geode-dev, When we will have Apache Geode 1.12.0 release? I saw that all test passed and the last commit was before 4 days(typos correct). Are we waiting fix for some critical issue or something else? Thanks and BR, Mario
