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

Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/FlakyTest/builds/155

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

Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/release-1.4.0/jobs/DistributedTest/builds/14

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

Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/FlakyTest/builds/153

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

--- Spring Data GemFire > Nightly-ApacheGeode > #808 was successful. --- Scheduled 2326 tests in total. https://build.spring.io/browse/SGF-NAG-808/ -- This

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

Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/101

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

It is no different really than how the Java client works. If on a Java client I put an object who's class implements PdxSerializable the object is serialized as PDX. If form the Java client I call a function with that object as an argument then the server will try to deserialize the PDX to the name

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

Hi Jake, I'm not really familiar with how the .NET client works - from what you're saying, it sounds like there is a way to serialize PDX objects without having access to a domain class? Can the .NET client tag PDX-serialized objects with the name of the domain class that they represent, so that t

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

*One more thing...* Regarding arguments passed to Functions, which can equally apply to return types as well, particularly in SDG, since Functions can be methods on a POJO, having strongly typed return values, for example ... @GemfireFunction(..) Customer someFunction(CustomerIdentifier id, PdxIn

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

To Swap's point about making ReflectionBasedAutoSerializer the default (which I think is a good idea), comparably, in SDG, I have made SDG's o.s.d.g.mapping.MappingPdxSerializer [1] the default when PDX is enabled (i.e. @EnablePdx). No need to explicitly declare/register it. SDG's MappingPdxSeria

Re: Addition of rmi-io library

To address this we have two Jiras tracking the issue: GEODE-4370 - jar deployment should not require additional ports to be opened GEODE-4379 - gfsh deploy should push jars not have the server pull them Essentially these will result in no new RMI ports being used/opened. Code for 4370 is already

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

> On Jan 25, 2018, at 12:06 PM, Anilkumar Gingade wrote: > > Jake, > > Interesting...Its the argument passed to function that is in deserialized > form, right? Yes, if pdx read serialized is false (default) the argument is deserialized to domain object or fails if no domain object found. If

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

Jake, Interesting...Its the argument passed to function that is in deserialized form, right? -Anil. On Thu, Jan 25, 2018 at 10:12 AM, Jacob Barrett wrote: > Anil, this wouldn't fix a function execution where a parameter sent to the > function is a PDX serialized object. The function would

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

+1 to making PDX being more usable by adding an API rather than the current flag. I also think we should make the client-side usage of PDX simpler by always using ReflectionBasedAutoSerializer when no serialization mechanism has been specified see GEODE-2722

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

+1 storing data in binary form (long time ask). On Thu, Jan 25, 2018 at 11:07 AM, John Blum wrote: > I have always thought/wondered, why not just store the data in serialized > form always. There are several reasons to do so... > > 1. Whenever data is transferred between client & server, bet

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

I have always thought/wondered, why not just store the data in serialized form always. There are several reasons to do so... 1. Whenever data is transferred between client & server, between peers, over the WAN, overflowed to disk or persisted to disk, it must be serialized. 2. Naturally it follow

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

Anil, this wouldn't fix a function execution where a parameter sent to the function is a PDX serialized object. The function would be invoked on the server with the current global setting and file to deserialize the PDX to domain object. This is why the ask is for it to fall back to PdxInstance if

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

Internally, there is an option to override read-serialized flag (to true); the query engine and other components uses this to keep the data in serialized form and work with PdxInstance... public static void setPdxReadSerialized(Cache cache, boolean readSerialized); We had discussed, making this a

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

Bruce, the flag only applies to values serialized with PDX, DataSerializable objects are not effected by this property. I think there is some real value here as a stop gap until we have a better solution in Geode 2 where the user can have a per request context that specifies what return type they

Re: [VOTE] Apache Geode release - 1.4.0 RC1

This vote is now cancelled. I will send a vote thread for RC2 when this issue is resolved. On Thu, Jan 25, 2018 at 7:40 AM Bruce Schuchardt wrote: > -1 based on Dan's findings > > > On 1/24/18 8:08 AM, Anthony Baker wrote: > > Here’s a better URL for release notes that doesn’t require logging in

Re: [VOTE] Apache Geode release - 1.4.0 RC1

-1 based on Dan's findings On 1/24/18 8:08 AM, Anthony Baker wrote: Here’s a better URL for release notes that doesn’t require logging in: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420&version=12341842

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

+1 I've found the current read-serialized property to be pretty useless. Having said that, what if the value isn't actually in serialized form in the local cache?  Is Geode supposed to serialize it & return it?  What if it isn't PDX-serialized?  Do we return a byte array? On 1/24/18 12:21 P