Geode unit tests completed in 'release-1.5.0/DistributedTest' with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/release-1.5.0/jobs/DistributedTest/builds/4

Re: Starter tickets

[Alexander Murmann]

Hi all,

I consolidated all labels mentioned above under "starter" and "starter++"
and updated the how to contribute page

accordingly.

At this point we have 21 and 3 tickets for those labels. Especially the
number of "starter" tickets seems like it's very much in the healthy range.
Let's make sure they all stay relevant.

Looking good to everyone?

On Fri, Mar 2, 2018 at 3:12 PM, Patrick Rhomberg 
wrote:

> I don't really think "newbie" has a negative connotation, but then again,
> I've been a gamer long enough to see a difference between terms "newb" and
> a "n00b."
>
> I do love consistency, though.  (You might even say "consistency is a
> must.")
>
> We currently have tickets tagged with "newbie" and its variants, a few
> "low-hanging-fruit", one closed "easyfix."
>
> Glancing at other Apache JIRAs, it looks like "starter," "newbie," and
> "beginner" are popular.
>
> If anyone knows how the ASF Bot works and has the ability to enforce a
> standard, I'd personally love to see us pick one label or another, and have
> the bot switch any of those other tags to what we land on.  Which sounds
> like it ought to be "starter."  But it defeats the purpose if after this
> thread slips from immediate memory, people go back to tagging tickets with
> whatever is top of their mind.  Otherwise we'd have to expect new
> contributors to know the ump-teen tags that would be a good starting point.
>
> On Fri, Mar 2, 2018 at 1:45 PM, Joey McAllister 
> wrote:
>
> > +1 to "starter" over "newbie." I think the ++ plan makes sense, too.
> >
> > Thanks for the initiative on this, Alexander. It seems like a very
> valuable
> > effort for the community.
> >
> > On Fri, Mar 2, 2018 at 1:35 PM Alexander Murmann 
> > wrote:
> >
> > > I am glad this already revealed that we aren't consistent in what
> labels
> > we
> > > are using. I assume the idea of newbie++ was to facilitate a
> > progression? I
> > > really like that and would love to keep something like that.
> > >
> > > I don't think the term "newbie" is great. To me it has a little bit of
> a
> > > negative connotation.
> > >
> > > Does anyone have an issue with adopting "starter" and "starter++"
> > > consistently? I am happy to do the conversion work and make sure the
> > > communication in the wiki etc. is consistent going forward.
> > >
> > > Mike, I agree that there is probably a lot of great work that someone
> who
> > > doesn't know the code base well can do in Pulse. I'd suggest that we
> > still
> > > decide on a case by case basis. A quick glance showed a few bugs that
> > > probably should be tackled sooner rather than later. I'll take a pass
> at
> > > all Pulse related tickets and see if they are a good fit.
> > >
> > > On Fri, Mar 2, 2018 at 10:45 AM, Michael Stolz 
> > wrote:
> > >
> > > > I'd love to tag all the pulse issues as newbie if we could.
> > > >
> > > >
> > > >
> > > > On Fri, Mar 2, 2018 at 1:34 PM, Anthony Baker 
> > wrote:
> > > >
> > > > > Good idea!  We he have a few other labels relevant to this as well:
> > > > >
> > > > > - newbie
> > > > > - low-hanging-fruit
> > > > >
> > > > > Anthony
> > > > >
> > > > >
> > > > > > On Mar 2, 2018, at 10:03 AM, Alexander Murmann <
> > amurm...@pivotal.io>
> > > > > wrote:
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I think we could make it easier for people to find tasks that can
> > be
> > > > > their
> > > > > > first contribution to Geode. The wiki page on how to contribute
> > > > > >  > to+Contribute
> > > >
> > > > > has a
> > > > > > list of suggested projects. Most of those are pretty ambitious
> and
> > > > likely
> > > > > > would be overwhelming to first time contributors. There also is a
> > > link
> > > > > > to tickets
> > > > > > labeled with "Starter"
> > > > > >  > > > > 3D%20Geode%20AND%20labels%20%3D%20starter%20AND%20status%
> > > > > 20in%20%28Open%2C%20%22In%20Progress%22%2C%20Reopened%29>.
> > > > > > I think the later is probably a much better angle for someone to
> > > start
> > > > > > contributing to Geode. Unfortunately there was less than a
> handful
> > of
> > > > > > tickets labeled as starter tickets.
> > > > > >
> > > > > > My suggestion is to find tickets that strike a healthy balance
> > > between
> > > > > being
> > > > > >
> > > > > >   - simple enough that someone new to the code base can
> > realistically
> > > > > take
> > > > > >   them on
> > > > > >   - rewarding enough that someone can feel a sense of
> > accomplishment
> > > > > after
> > > > > >   having their PR merged
> > > > > >   - small enough that it can be accomplished in an evening or at
> > > most a
> > > > > >   long weekend
> > > > > >   - unlikely to result in conflicts with larger efforts that
> > 

Geode unit tests completed in 'develop/DistributedTest' with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/183

Re: FunctionService Proposal

[Patrick Rhomberg]

I did not know that!  And then, yes, onRegion is much better.

On Wed, Mar 7, 2018 at 2:43 PM, Dan Smith  wrote:

> > If we're not opposed to descriptive verbosity, I might prefer
> "onServersHostingRegion" more than "onRegion".
>
> onRegion does not really mean "on the servers hosting region XXX". It only
> executes on a subset of the servers, potentially with retries, until it has
> covered that entire dataset once. So I think onRegion is more appropriate.
>
> -Dan
>
> On Wed, Mar 7, 2018 at 2:38 PM, Patrick Rhomberg 
> wrote:
>
> > +1 for iteration towards better single responsibility design and more
> > easily-digestible classes.
> >
> > Regarding method names, I think that there would be some good utility in
> > having "onGroup" methods, as well.
> > If we're not opposed to descriptive verbosity, I might prefer
> > "onServersHostingRegion" more than "onRegion".
> >
> > On Wed, Mar 7, 2018 at 1:45 PM, Dan Smith  wrote:
> >
> > > Hi Udo,
> > >
> > > +1 for making the function service not static and spitting it into
> client
> > > and server FunctionService objects!
> > >
> > > We do have Cache and ClientCache right now. So I would recommend this
> API
> > > rather than putting two methods on Cache. Cache is already the the
> server
> > > side API.
> > >
> > > Cache {
> > >   ServerFunctionService getFunctionService()
> > > }
> > >
> > > ClientCache {
> > >   ClientFunctionService getFunctionService()
> > > }
> > >
> > > If at some point we split the client side API into a separate jar the
> API
> > > shouldn't need to change. If you don't like ClientFunctionService,
> maybe
> > > o.a.g.cache.client.execute.FunctionService? We would never want two
> > > different versions of org.apache.geode.function.FunctionService.
> People
> > > wouldn't be able to test a client and server in the same JVM.
> > >
> > > Also, you might want to check out this (somewhat stalled) proposal -
> > > https://cwiki.apache.org/confluence/display/GEODE/
> > > Function+Service+Usability+Improvements. We had buy in on this on the
> > dev
> > > list but have not found cycles to actually do it yet. But maybe now is
> > the
> > > time?
> > >
> > > -Dan
> > >
> > > On Wed, Mar 7, 2018 at 11:18 AM, Udo Kohlmeyer  wrote:
> > >
> > > > Hi there Apache Dev's,
> > > >
> > > > Please look at the proposal to improve the FunctionService and remove
> > the
> > > > static invocation of it from within the Cache.
> > > >
> > > > https://cwiki.apache.org/confluence/display/GEODE/Function+
> > > > Service+Refactor+-+Removal+of+static-ness+and+splitting+of+
> > > > client+and+server-side+FunctionService
> > > >
> > > > --Udo
> > > >
> > > >
> > >
> >
>

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #849 was SUCCESSFUL (with 2378 tests)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #849 was successful.
---
Scheduled
2380 tests in total.

https://build.spring.io/browse/SGF-NAG-849/





--
This message is automatically generated by Atlassian Bamboo

Re: FunctionService Proposal

[Dan Smith]

> If we're not opposed to descriptive verbosity, I might prefer
"onServersHostingRegion" more than "onRegion".

onRegion does not really mean "on the servers hosting region XXX". It only
executes on a subset of the servers, potentially with retries, until it has
covered that entire dataset once. So I think onRegion is more appropriate.

-Dan

On Wed, Mar 7, 2018 at 2:38 PM, Patrick Rhomberg 
wrote:

> +1 for iteration towards better single responsibility design and more
> easily-digestible classes.
>
> Regarding method names, I think that there would be some good utility in
> having "onGroup" methods, as well.
> If we're not opposed to descriptive verbosity, I might prefer
> "onServersHostingRegion" more than "onRegion".
>
> On Wed, Mar 7, 2018 at 1:45 PM, Dan Smith  wrote:
>
> > Hi Udo,
> >
> > +1 for making the function service not static and spitting it into client
> > and server FunctionService objects!
> >
> > We do have Cache and ClientCache right now. So I would recommend this API
> > rather than putting two methods on Cache. Cache is already the the server
> > side API.
> >
> > Cache {
> >   ServerFunctionService getFunctionService()
> > }
> >
> > ClientCache {
> >   ClientFunctionService getFunctionService()
> > }
> >
> > If at some point we split the client side API into a separate jar the API
> > shouldn't need to change. If you don't like ClientFunctionService, maybe
> > o.a.g.cache.client.execute.FunctionService? We would never want two
> > different versions of org.apache.geode.function.FunctionService. People
> > wouldn't be able to test a client and server in the same JVM.
> >
> > Also, you might want to check out this (somewhat stalled) proposal -
> > https://cwiki.apache.org/confluence/display/GEODE/
> > Function+Service+Usability+Improvements. We had buy in on this on the
> dev
> > list but have not found cycles to actually do it yet. But maybe now is
> the
> > time?
> >
> > -Dan
> >
> > On Wed, Mar 7, 2018 at 11:18 AM, Udo Kohlmeyer  wrote:
> >
> > > Hi there Apache Dev's,
> > >
> > > Please look at the proposal to improve the FunctionService and remove
> the
> > > static invocation of it from within the Cache.
> > >
> > > https://cwiki.apache.org/confluence/display/GEODE/Function+
> > > Service+Refactor+-+Removal+of+static-ness+and+splitting+of+
> > > client+and+server-side+FunctionService
> > >
> > > --Udo
> > >
> > >
> >
>

Re: FunctionService Proposal

[Patrick Rhomberg]

+1 for iteration towards better single responsibility design and more
easily-digestible classes.

Regarding method names, I think that there would be some good utility in
having "onGroup" methods, as well.
If we're not opposed to descriptive verbosity, I might prefer
"onServersHostingRegion" more than "onRegion".

On Wed, Mar 7, 2018 at 1:45 PM, Dan Smith  wrote:

> Hi Udo,
>
> +1 for making the function service not static and spitting it into client
> and server FunctionService objects!
>
> We do have Cache and ClientCache right now. So I would recommend this API
> rather than putting two methods on Cache. Cache is already the the server
> side API.
>
> Cache {
>   ServerFunctionService getFunctionService()
> }
>
> ClientCache {
>   ClientFunctionService getFunctionService()
> }
>
> If at some point we split the client side API into a separate jar the API
> shouldn't need to change. If you don't like ClientFunctionService, maybe
> o.a.g.cache.client.execute.FunctionService? We would never want two
> different versions of org.apache.geode.function.FunctionService. People
> wouldn't be able to test a client and server in the same JVM.
>
> Also, you might want to check out this (somewhat stalled) proposal -
> https://cwiki.apache.org/confluence/display/GEODE/
> Function+Service+Usability+Improvements. We had buy in on this on the dev
> list but have not found cycles to actually do it yet. But maybe now is the
> time?
>
> -Dan
>
> On Wed, Mar 7, 2018 at 11:18 AM, Udo Kohlmeyer  wrote:
>
> > Hi there Apache Dev's,
> >
> > Please look at the proposal to improve the FunctionService and remove the
> > static invocation of it from within the Cache.
> >
> > https://cwiki.apache.org/confluence/display/GEODE/Function+
> > Service+Refactor+-+Removal+of+static-ness+and+splitting+of+
> > client+and+server-side+FunctionService
> >
> > --Udo
> >
> >
>

Re: FunctionService Proposal

[Jacob Barrett]

I agree with Dan here. The C++ client took a stab at making
ExecutionService less static but didn't go this far. Rather than pull Cache
out of the either it is passed into each of the static factory methods,
wither as a Region, Pool or Cache itself. I like propose to add
Cache::getFunctionService to cache.

I find UML diagrams to be a bit heavy handed for describing APIs. Can we
just simplify this into so sample code that users will actually interact
with.

So if we were to make this change on the C++ side we would have that (C++
Cache is client cache, confusing yes).
class Cache ... {
  ...
  FunctionService& getFunctionService();
}

class FunctionService ... {
  ...
  Execution& onRegion(const std::string& regionName);
  Execution& onRegion(std::shared_ptr region);

  Execution& onServers(std::shared_ptr pool);
  Execution& onServers(); // was onServer(std::shared_ptr)

  Execution& onServer(std::shared_ptr pool);
  Execution& onServer(); // was onServer(std::shared_ptr)
}

class Region ... {
  ...
  Execution& createExecution(); // nice shortcut
}

void doExecution(Cache& cache) {
  auto results = cache.getExecutionService()
  .onRegion("myRegion")
  .withArgs(MyFunctionArgs{"arg1", 2})
  .execute("MyFunction");
  ...
}

void doExecution(Region& cache) {
  auto results = region.createExecution()
  .withArgs(MyFunctionArgs{"arg1", 2})
  .execute("MyFunction");
  ...
}

On a related note, I would suggest we use the unqualified names for the
client since that is where real "users" of our API will be spending most of
their time. For them calling everything ClientX and ClientY is a bit
redundant.



On Wed, Mar 7, 2018 at 1:45 PM Dan Smith  wrote:

> Hi Udo,
>
> +1 for making the function service not static and spitting it into client
> and server FunctionService objects!
>
> We do have Cache and ClientCache right now. So I would recommend this API
> rather than putting two methods on Cache. Cache is already the the server
> side API.
>
> Cache {
>   ServerFunctionService getFunctionService()
> }
>
> ClientCache {
>   ClientFunctionService getFunctionService()
> }
>
> If at some point we split the client side API into a separate jar the API
> shouldn't need to change. If you don't like ClientFunctionService, maybe
> o.a.g.cache.client.execute.FunctionService? We would never want two
> different versions of org.apache.geode.function.FunctionService. People
> wouldn't be able to test a client and server in the same JVM.
>
> Also, you might want to check out this (somewhat stalled) proposal -
> https://cwiki.apache.org/confluence/display/GEODE/
> Function+Service+Usability+Improvements. We had buy in on this on the dev
> list but have not found cycles to actually do it yet. But maybe now is the
> time?
>
> -Dan
>
> On Wed, Mar 7, 2018 at 11:18 AM, Udo Kohlmeyer  wrote:
>
> > Hi there Apache Dev's,
> >
> > Please look at the proposal to improve the FunctionService and remove the
> > static invocation of it from within the Cache.
> >
> > https://cwiki.apache.org/confluence/display/GEODE/Function+
> > Service+Refactor+-+Removal+of+static-ness+and+splitting+of+
> > client+and+server-side+FunctionService
> >
> > --Udo
> >
> >
>

Geode unit tests completed in 'develop/FlakyTest' with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/FlakyTest/builds/290

Re: Simple serialize/deserialize test using DataSerializers

[Darrel Schneider]

BlobHelper ends up calling DataSerializer.writeObject. The nice thing about
BlobHelper is can
call org.apache.geode.internal.util.BlobHelper.serializeToBlob(Object)
and org.apache.geode.internal.util.BlobHelper.deserializeBlob(byte[])
without needing to write any of your own code the create the input and
output streams.


On Wed, Mar 7, 2018 at 11:40 AM, Dan Smith  wrote:

> DataSerializer.writeObject, if you want a public API.
>
> -Dan
>
> On Wed, Mar 7, 2018 at 11:20 AM, Anthony Baker  wrote:
>
> > BlobHelper?
> >
> > > On Mar 7, 2018, at 10:13 AM, Kirk Lund  wrote:
> > >
> > > Does anyone know what Geode API(s) I should use instead of Apache Geode
> > > SerializationUtils to change the following test to use Geode
> > > DataSerializers?
> > >
> > > @Test
> > > public void serializesAndDeserializes() throws Exception {
> > >  PartitionRegionConfig config = new PartitionRegionConfig(prId, path,
> > > partitionAttributes, scope, evictionAttributes, regionIdleTimeout,
> > > regionTimeToLive, entryIdleTimeout, entryTimeToLive, gatewaySenderIds);
> > >  byte[] bytes = SerializationUtils.serialize(config);
> > >  assertThat(bytes).isNotNull().isNotEmpty();
> > >
> > > assertThat(SerializationUtils.deserialize(bytes)).isNotSameAs(config).
> > isInstanceOf(PartitionRegionConfig.class);
> > > }
> >
> >
>

Broken: jinmeiliao/geode#249 (clusterConfig - b18bf0d)

[Travis CI]

Build Update for jinmeiliao/geode
-

Build: #249
Status: Broken

Duration: 20 minutes and 49 seconds
Commit: b18bf0d (clusterConfig)
Author: Jinmei Liao
Message: add tests

View the changeset: 
https://github.com/jinmeiliao/geode/compare/4255afe11efe^...b18bf0dbf142

View the full build log and details: 
https://travis-ci.org/jinmeiliao/geode/builds/350464189?utm_source=email_medium=notification

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

Re: [PROPOSAL]: configure pdx command mandatory flags

[Dan Smith]

I think the configure pdx command also lets you configure persistence or
read-serialized for pdx, right? So some people might not be using either of
those auto-serializable-classes options.

-Dan

On Wed, Mar 7, 2018 at 4:13 AM, Ju@N  wrote:

> Hello all,
>
> While working on a fix for  GEODE-4771
>  I've came across a
> non-reported bug: the configure pdx command fails when no parameters are
> specified, even when we state in the User Guide
>  command-pages/configure.html>
> that
> no parameters are mandatory to execute the command. The source code doesn't
> enforce any of the parameters and, as such, the resulting XmlEntity ends up
> being empty, so a NullPointerException is thrown when the command tries to
> persist the changes to the cluster configuration service:
>
> [error 2018/03/07 11:07:48.242 GMT locator1  Connection(2)-127.0.0.1> tid=0x55] error updating cluster
> configuration for group cluster
> java.lang.NullPointerException
> at java.io.StringReader.(StringReader.java:50)
> at org.apache.geode.management.internal.configuration.utils.
> XmlUtils.createNode(XmlUtils.java:242)
> at org.apache.geode.management.internal.configuration.utils.
> XmlUtils.addNewNode(XmlUtils.java:133)
> at org.apache.geode.distributed.internal.
> ClusterConfigurationService.addXmlEntity(ClusterConfigurationService.
> java:204)
> at org.apache.geode.management.internal.cli.commands.
> ConfigurePDXCommand.lambda$configurePDX$0(ConfigurePDXCommand.java:131)
> at org.apache.geode.management.internal.cli.commands.GfshCommand.
> persistClusterConfiguration(GfshCommand.java:72)
> at org.apache.geode.management.internal.cli.commands.
> ConfigurePDXCommand.configurePDX(ConfigurePDXCommand.java:130)
> 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.springframework.util.ReflectionUtils.invokeMethod(
> ReflectionUtils.java:216)
> at org.apache.geode.management.internal.cli.remote.
> CommandExecutor.invokeCommand(CommandExecutor.java:97)
> at org.apache.geode.management.internal.cli.remote.
> CommandExecutor.execute(CommandExecutor.java:45)
> at org.apache.geode.management.internal.cli.remote.
> CommandExecutor.execute(CommandExecutor.java:39)
> at org.apache.geode.management.internal.cli.remote.
> OnlineCommandProcessor.executeCommand(OnlineCommandProcessor.java:133)
> at org.apache.geode.management.internal.beans.MemberMBeanBridge.
> processCommand(MemberMBeanBridge.java:1579)
> at org.apache.geode.management.internal.beans.MemberMBean.
> processCommand(MemberMBean.java:412)
> 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 sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(
> ConvertingMethod.java:193)
> at com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(
> ConvertingMethod.java:175)
> at com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(
> MXBeanIntrospector.java:117)
> at com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(
> MXBeanIntrospector.java:54)
> at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(
> MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(
> PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(
> MBeanSupport.java:252)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(
> DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(
> JmxMBeanServer.java:801)
> at javax.management.remote.rmi.RMIConnectionImpl.doOperation(
> RMIConnectionImpl.java:1468)
> at javax.management.remote.rmi.RMIConnectionImpl.access$300(
> RMIConnectionImpl.java:76)
> at javax.management.remote.rmi.RMIConnectionImpl$
> PrivilegedOperation.run(RMIConnectionImpl.java:1309)
> at javax.management.remote.rmi.RMIConnectionImpl.
> 

Re: Simple serialize/deserialize test using DataSerializers

[Dan Smith]

DataSerializer.writeObject, if you want a public API.

-Dan

On Wed, Mar 7, 2018 at 11:20 AM, Anthony Baker  wrote:

> BlobHelper?
>
> > On Mar 7, 2018, at 10:13 AM, Kirk Lund  wrote:
> >
> > Does anyone know what Geode API(s) I should use instead of Apache Geode
> > SerializationUtils to change the following test to use Geode
> > DataSerializers?
> >
> > @Test
> > public void serializesAndDeserializes() throws Exception {
> >  PartitionRegionConfig config = new PartitionRegionConfig(prId, path,
> > partitionAttributes, scope, evictionAttributes, regionIdleTimeout,
> > regionTimeToLive, entryIdleTimeout, entryTimeToLive, gatewaySenderIds);
> >  byte[] bytes = SerializationUtils.serialize(config);
> >  assertThat(bytes).isNotNull().isNotEmpty();
> >
> > assertThat(SerializationUtils.deserialize(bytes)).isNotSameAs(config).
> isInstanceOf(PartitionRegionConfig.class);
> > }
>
>

FunctionService Proposal

[Udo Kohlmeyer]

Hi there Apache Dev's,

Please look at the proposal to improve the FunctionService and remove 
the static invocation of it from within the Cache.


https://cwiki.apache.org/confluence/display/GEODE/Function+Service+Refactor+-+Removal+of+static-ness+and+splitting+of+client+and+server-side+FunctionService

--Udo

Simple serialize/deserialize test using DataSerializers

[Kirk Lund]

Does anyone know what Geode API(s) I should use instead of Apache Geode
SerializationUtils to change the following test to use Geode
DataSerializers?

@Test
public void serializesAndDeserializes() throws Exception {
  PartitionRegionConfig config = new PartitionRegionConfig(prId, path,
partitionAttributes, scope, evictionAttributes, regionIdleTimeout,
regionTimeToLive, entryIdleTimeout, entryTimeToLive, gatewaySenderIds);
  byte[] bytes = SerializationUtils.serialize(config);
  assertThat(bytes).isNotNull().isNotEmpty();

assertThat(SerializationUtils.deserialize(bytes)).isNotSameAs(config).isInstanceOf(PartitionRegionConfig.class);
}

Re: jdbc schema is missing on apache

[Anthony Baker]

You need to add it to the geode-site repo on the asf-site branch:

~/code/geode-site (asf-site)$ find . -name *.xsd
./schema/lucene/lucene-1.0.xsd
./schema/cache/cache-1.0.xsd


Anthony


> On Mar 7, 2018, at 10:08 AM, Kirk Lund  wrote:
> 
> Yep, I believe it should exist. Any ideas where and how to copy it from
> Geode src so that it appears at http://geode.apache.org/schema/jdbc?
> 
> On Wed, Mar 7, 2018 at 9:59 AM, Jinmei Liao  wrote:
> 
>> I am looking at some xml that specifies jdbc connector, the namespace is
>> pointing to "
>> 
>> http://geode.apache.org/schema/jdbc;, but that url is missing on
>> apache website. Is it supposed to be there?
>> 
>> 
>> >  xmlns="http://geode.apache.org/schema/cache;
>>  xmlns:jdbc="http://geode.apache.org/schema/jdbc;
>>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>>  xsi:schemaLocation="http://geode.apache.org/schema/cache
>>  http://geode.apache.org/schema/cache/cache-1.0.xsd
>>  http://geode.apache.org/schema/jdbc
>>  http://geode.apache.org/schema/jdbc/jdbc-1.0.xsd;
>>  version="1.0">
>> 
>> 
>> --
>> Cheers
>> 
>> Jinmei
>> 

Re: jdbc schema is missing on apache

[Kirk Lund]

Yep, I believe it should exist. Any ideas where and how to copy it from
Geode src so that it appears at http://geode.apache.org/schema/jdbc?

On Wed, Mar 7, 2018 at 9:59 AM, Jinmei Liao  wrote:

> I am looking at some xml that specifies jdbc connector, the namespace is
> pointing to "
>
> http://geode.apache.org/schema/jdbc;, but that url is missing on
> apache website. Is it supposed to be there?
>
>
>xmlns="http://geode.apache.org/schema/cache;
>   xmlns:jdbc="http://geode.apache.org/schema/jdbc;
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>   xsi:schemaLocation="http://geode.apache.org/schema/cache
>   http://geode.apache.org/schema/cache/cache-1.0.xsd
>   http://geode.apache.org/schema/jdbc
>   http://geode.apache.org/schema/jdbc/jdbc-1.0.xsd;
>   version="1.0">
>
>
> --
> Cheers
>
> Jinmei
>

jdbc schema is missing on apache

[Jinmei Liao]

I am looking at some xml that specifies jdbc connector, the namespace is
pointing to "

http://geode.apache.org/schema/jdbc;, but that url is missing on
apache website. Is it supposed to be there?


http://geode.apache.org/schema/cache;
  xmlns:jdbc="http://geode.apache.org/schema/jdbc;
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation="http://geode.apache.org/schema/cache
  http://geode.apache.org/schema/cache/cache-1.0.xsd
  http://geode.apache.org/schema/jdbc
  http://geode.apache.org/schema/jdbc/jdbc-1.0.xsd;
  version="1.0">


-- 
Cheers

Jinmei

Re: Next release: 1.5.0

[Anthony Baker]

Thanks, John.  I did a round of updates for this release and expect we can 
continue do this in subsequent releases.

Bundled dependencies:
Commons Lang is at *3.7;* Geode is at 2.6
Log4j is at *2.10.0*; Geode is at 2.8.2
Netty is at *4.1.22.Final*; Geode is at 4.1.21.Final
Spring Security is at *5.0.3.RELEASE*; Geode is at 4.2.4.RELEASE.
Spring Framework is at *5.0.3.RELEASE*; Geode is at 4.3.14.RELEASE

Non-bundled dependencies:
AssertJ is at *3.9.1;  *Geode is at 3.8.0
Mockito is at *2.15.0*; Geode is at 2.8.9
JSON Path is at *2.4.0*; Geode is at 2.2.0
Tomcat is at *8.5.28*; Geode is at 8.5.9.


I haven’t explored the Spring update to see how painful that will be.  I do 
like the dependency management plugin provided by Spring and would like to 
incorporate that into our build.  The log4j update to 2.10.0 had some conflicts 
with jetty IIRC so I backed off on that one for this release.

Anthony


> On Mar 6, 2018, at 9:31 AM, John Blum  wrote:
> 
> I also noticed that there are several outdated dependency versions yet...
> 
> AssertJ is at *3.9.1;  *Geode is at 3.8.0
> Commons Lang is at *3.7;* Geode is at 2.6
> JSON Path is at *2.4.0*; Geode is at 2.2.0
> Log4j is at *2.10.0*; Geode is at 2.8.2
> Mockito is at *2.15.0*; Geode is at 2.8.9
> Netty is at *4.1.22.Final*; Geode is at 4.1.21.Final
> Spring Security is at *5.0.3.RELEASE*; Geode is at 4.2.4.RELEASE.
> Spring Framework is at *5.0.3.RELEASE*; Geode is at 4.3.14.RELEASE
> Tomcat is at *8.5.28*; Geode is at 8.5.9.
> 
> NOTE: the separate spring-tx.version is not needed as it does not differ
> from the core Spring Framework.
> NOTE: it would probably be easier to import the Spring Framework BOM file
> than individual Spring Framework deps.
> 
> These are just want I noticed at a quick glance when comparing to the *Spring
> Boot/Spring IO Platform* curated and managed set of dependencies.
> 
> -j
> 
> 
> 
> 
> On Tue, Mar 6, 2018 at 9:06 AM, Anthony Baker  > wrote:
> 
>> Looks like there are some things broken related to serialization filtering
>> as well on the release branch:
>> 
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/ 
>> 
>> release-1.5.0/jobs/DistributedTest/builds/2 > .
>> apachegeode-ci.info/teams/main/pipelines/release-1.5.0/ 
>> 
>> jobs/DistributedTest/builds/2>
>> 
>> Anthony
>> 
>> 
>>> On Mar 6, 2018, at 8:57 AM, John Blum >> > wrote:
>>> 
>>> I don't think this should wait since it affects downstream artifacts
>>> (already)... Pivotal GemFire -> PCC.
>>> 
>>> As I stated, I am will have the changes prepared a few hours.  This is
>>> pretty low risk from Apache Geode's side but is imperative for Spring/PCC
>>> users.
>>> 
>>> On Tue, Mar 6, 2018 at 8:40 AM, Alexander Murmann >> >
>>> wrote:
>>> 
 John, how much of an issue would it be if the change was added one month
 from now?
 
 On Tue, Mar 6, 2018 at 8:36 AM, John Blum > wrote:
 
> I have 1 addition (planning to submit a PR for review) for the 1.5
 release
> that is imperative for *Spring Data for Apache Geode*, and
>> specifically,
> client-side Cluster Configuration Push [1].
> 
> Details to follow soon; will file a ticket in JIRA.
> 
> -j
> 
> 
> [1]
> https://docs.spring.io/spring-data/geode/docs/current/
> reference/html/#bootstrap-annotation-config-cluster
> 
> 
> On Mon, Mar 5, 2018 at 1:09 PM, Anthony Baker 
>> wrote:
> 
>> Could you make the pipeline public?
>> 
>> Anthony
>> 
>> 
>>> On Mar 5, 2018, at 12:46 PM, Sean Goller  wrote:
>>> 
>>> 1.5.0 pipeline is up and running, please take a look at it and let
 the
>> list
>>> know if there are problems.
>>> 
>>> https://concourse.apachegeode-ci.info/teams/main/pipelines/
> release-1.5.0
>>> 
>>> On Mon, Mar 5, 2018 at 11:07 AM, Anthony Baker 
>> wrote:
>>> 
 LGTM
 
> On Mar 2, 2018, at 4:05 PM, Swapnil Bawaskar  
 wrote:
> 
> Thanks Dave!
> 
> All, I have created a release branch (
> https://github.com/apache/geode/tree/release/1.5.0) Please review.
> 
> On Fri, Mar 2, 2018 at 9:56 AM Dave Barnes 
> wrote:
> 
>> Status on the 3 doc issues:
>> GEODE-4737 / GEODE-3915: JSON args in gfsh - Done
>> GEODE-4101:  redirect-output - Done
>> GEODE-3948: client timeout - Done

[PROPOSAL]: configure pdx command mandatory flags

[Ju@N]

Hello all,

While working on a fix for  GEODE-4771
 I've came across a
non-reported bug: the configure pdx command fails when no parameters are
specified, even when we state in the User Guide

that
no parameters are mandatory to execute the command. The source code doesn't
enforce any of the parameters and, as such, the resulting XmlEntity ends up
being empty, so a NullPointerException is thrown when the command tries to
persist the changes to the cluster configuration service:

[error 2018/03/07 11:07:48.242 GMT locator1  tid=0x55] error updating cluster
configuration for group cluster
java.lang.NullPointerException
at java.io.StringReader.(StringReader.java:50)
at 
org.apache.geode.management.internal.configuration.utils.XmlUtils.createNode(XmlUtils.java:242)
at 
org.apache.geode.management.internal.configuration.utils.XmlUtils.addNewNode(XmlUtils.java:133)
at 
org.apache.geode.distributed.internal.ClusterConfigurationService.addXmlEntity(ClusterConfigurationService.java:204)
at 
org.apache.geode.management.internal.cli.commands.ConfigurePDXCommand.lambda$configurePDX$0(ConfigurePDXCommand.java:131)
at 
org.apache.geode.management.internal.cli.commands.GfshCommand.persistClusterConfiguration(GfshCommand.java:72)
at 
org.apache.geode.management.internal.cli.commands.ConfigurePDXCommand.configurePDX(ConfigurePDXCommand.java:130)
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.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:216)
at 
org.apache.geode.management.internal.cli.remote.CommandExecutor.invokeCommand(CommandExecutor.java:97)
at 
org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:45)
at 
org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:39)
at 
org.apache.geode.management.internal.cli.remote.OnlineCommandProcessor.executeCommand(OnlineCommandProcessor.java:133)
at 
org.apache.geode.management.internal.beans.MemberMBeanBridge.processCommand(MemberMBeanBridge.java:1579)
at 
org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:412)
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 sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
at 
com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:193)
at 
com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175)
at 
com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117)
at 
com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54)
at 
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
at 
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
at 
javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
at 
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
at 
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
at 
javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
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