date:20171018

geode and open JDK / newer version of java

2017-10-18 Thread Roi Apelker

Hi,

Has anyone tried to operate GEODE with open JDK - any version - rather than 
Oracle's JDK?

Has anyone tried to operate GEODE with open JDK - specifically version 9 
(released Sep 21 2017)?

What about Oracle's version 9?

Any migration issues, problems etc. ?

Thanks,

Roi
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer

Re: geode and open JDK / newer version of java

2017-10-18 Thread Jens Deppe

Hi Roi,

We've spent a little time doing some cursory testing with Java 9 and there
are definitely some issues:

- Compilation requires additional JVM args because of the new
modularization in Java 9.
- A few lambda syntaxes in tests need to be adjusted.
- Some tests fail due to powermock issues.
- Using a distro built with Java 1.8, but running on Java 9, I was not able
to start locators or servers.

I don't remember the exact version used, but I believe it was an OpenJDK
downloaded just a few days before the official release.

--Jens

On Wed, Oct 18, 2017 at 2:51 AM, Roi Apelker  wrote:

> Hi,
>
> Has anyone tried to operate GEODE with open JDK - any version - rather
> than Oracle's JDK?
>
> Has anyone tried to operate GEODE with open JDK - specifically version 9
> (released Sep 21 2017)?
>
> What about Oracle's version 9?
>
> Any migration issues, problems etc. ?
>
> Thanks,
>
> Roi
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at https://www.amdocs.com/about/email-disclaimer <
> https://www.amdocs.com/about/email-disclaimer>
>

Re: DSFIDNotFoundException: Unknown DataSerializableFixedID: -158

2017-10-18 Thread Kirk Lund

My latest sighting of this was in
ResourceManagerDUnitTest.testRemoveDuringGetEntry which just shows this for
previously run tests:

Previously run tests: [ResourceManagerDUnitTest]

On Tue, Oct 17, 2017 at 7:30 PM, Bruce Schuchardt 
wrote:

> I think this is a secure UDP test leaving something behind that's
> infecting other tests.  If we can identify the previously run tests that
> might help.
>
>
>
> On 10/17/17 4:23 PM, Kirk Lund wrote:
>
>> At first I was just seeing a couple WAN tests fail with this but just now
>> I
>> had GIIDeltaDUnitTest fail due to this suspect string as well.
>>
>> Anyone know what's causing this?
>>
>> org.apache.geode.internal.cache.GIIDeltaDUnitTest > testSavingRVVGC
>> FAILED
>>  java.lang.AssertionError: Suspicious strings were written to the log
>> during this run.
>>  Fix the strings or use IgnoredException.addIgnoredException to
>> ignore.
>>  ---
>> 
>>  Found suspect string in log4j at line 916
>>
>>  [error 2017/10/17 19:37:34.907 UTC > receiver,4f2f4190aa4e-57131> tid=0x130] Exception deserializing message
>> payload: [dst: 172.17.0.4:32771, src: 172.17.0.4:32769 (2
>> headers),
>> size=108 bytes, flags=OOB|DONT_BUNDLE|NO_FC|SKIP_BARRIER]
>>  org.apache.geode.internal.DSFIDNotFoundException: Unknown
>> DataSerializableFixedID: -158
>>  at org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.
>> java:1003)
>>  at
>> org.apache.geode.internal.InternalDataSerializer.basicReadOb
>> ject(InternalDataSerializer.java:2693)
>>  at org.apache.geode.DataSerializer.readObject(DataSerializer.
>> java:2961)
>>  at
>> org.apache.geode.distributed.internal.membership.gms.messeng
>> er.JGroupsMessenger.deserializeMessage(JGroupsMessenger.java:1121)
>>  at
>> org.apache.geode.distributed.internal.membership.gms.messeng
>> er.JGroupsMessenger.readJGMessage(JGroupsMessenger.java:1013)
>>  at
>> org.apache.geode.distributed.internal.membership.gms.messeng
>> er.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1279)
>>  at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
>>  at org.jgroups.JChannel.up(JChannel.java:741)
>>  at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
>>  at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
>>  at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
>>  at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070)
>>  at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.
>> java:785)
>>  at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426)
>>  at
>> org.apache.geode.distributed.internal.membership.gms.messeng
>> er.StatRecorder.up(StatRecorder.java:74)
>>  at
>> org.apache.geode.distributed.internal.membership.gms.messeng
>> er.AddressManager.up(AddressManager.java:72)
>>  at org.jgroups.protocols.TP.passMessageUp(TP.java:1601)
>>  at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817)
>>  at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
>>  at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1729)
>>  at org.jgroups.protocols.TP.receive(TP.java:1654)
>>  at
>> org.apache.geode.distributed.internal.membership.gms.messeng
>> er.Transport.receive(Transport.java:160)
>>  at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
>>  at java.lang.Thread.run(Thread.java:748)
>>
>> Thanks,
>> Kirk
>>
>>
>

Re: DSFIDNotFoundException: Unknown DataSerializableFixedID: -158

2017-10-18 Thread Kirk Lund

Here's a log snippet with the failure -- looks like there's a UDP socket
WARN stack logged by this test before the ERROR stack. Is suspect string
search no longer including WARN log statements?

[vm2] [info 2017/10/17 21:03:46.296 UTC 
tid=0x1b] No locator(s) found with cluster configuration service

[vm2] [info 2017/10/17 21:03:46.347 UTC 
tid=0x1b] Requesting cluster configuration

[vm2] [info 2017/10/17 21:03:46.430 UTC 
tid=0x1b] Initializing region _monitoringRegion_172.17.0.432772

[vm2] [info 2017/10/17 21:03:46.437 UTC 
tid=0x1b] Initialization of region _monitoringRegion_172.17.0.432772
completed

[vm2] 15.848: [GC (Allocation Failure) [PSYoungGen:
131584K->9505K(153088K)] 138902K->16831K(502784K), 0.0131806 secs] [Times:
user=0.06 sys=0.00, real=0.01 secs]
[vm1] [warn 2017/10/17 21:03:46.794 UTC  tid=0x155]
Unable to send message to 172.17.0.4(155):32772
[vm1] java.io.IOException: Operation not permitted (sendto failed)
[vm1] at java.net.PlainDatagramSocketImpl.send(Native Method)
[vm1] at java.net.DatagramSocket.send(DatagramSocket.java:693)
[vm1] at org.jgroups.protocols.UDP._send(UDP.java:224)
[vm1] at org.jgroups.protocols.UDP.sendUnicast(UDP.java:215)
[vm1] at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1906)
[vm1] at org.jgroups.protocols.TP.doSend(TP.java:1883)
[vm1] at
org.apache.geode.distributed.internal.membership.gms.messenger.Transport.doSend(Transport.java:86)
[vm1] at org.jgroups.protocols.TP.send(TP.java:1869)
[vm1] at
org.apache.geode.distributed.internal.membership.gms.messenger.Transport._send(Transport.java:52)
[vm1] at org.jgroups.protocols.TP.down(TP.java:1474)
[vm1] at org.jgroups.stack.Protocol.down(Protocol.java:439)
[vm1] at
org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.down(StatRecorder.java:89)
[vm1] at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:675)
[vm1] at org.jgroups.protocols.FlowControl.down(FlowControl.java:347)
[vm1] at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
[vm1] at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1039)
[vm1] at org.jgroups.JChannel.down(JChannel.java:790)
[vm1] at org.jgroups.JChannel.send(JChannel.java:426)
[vm1] at
org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.send(JGroupsMessenger.java:774)
[vm1] at
org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.sendUnreliably(JGroupsMessenger.java:629)
[vm1] at
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$3.sendHeartbeats(GMSHealthMonitor.java:811)
[vm1] at
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$3.sendPeriodicHeartbeats(GMSHealthMonitor.java:769)
[vm1] at
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$3.run(GMSHealthMonitor.java:751)
[vm1] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[vm1] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[vm1] at java.lang.Thread.run(Thread.java:748)

[locator] [info 2017/10/17 21:03:46.798 UTC  tid=0x2a] received suspect message from
fea3cee77fa7(150):32771 for fea3cee77fa7(155):32772: Unable to
send messages to this member via JGroups

[locator] [info 2017/10/17 21:03:46.800 UTC  tid=0x7f] Performing final check for suspect member
fea3cee77fa7(155):32772 reason=Unable to send messages to this member
via JGroups

[locator] [info 2017/10/17 21:03:46.801 UTC  tid=0x2a] No longer suspecting
fea3cee77fa7(155):32772

[locator] [info 2017/10/17 21:03:46.803 UTC  tid=0x7f] Final check passed for suspect member
fea3cee77fa7(155):32772

[vm1] [error 2017/10/17 21:03:46.803 UTC  tid=0x150] Exception deserializing message
payload: [dst: 172.17.0.4:32771, src: 172.17.0.4:32769 (2
headers), size=108 bytes, flags=OOB|DONT_BUNDLE|NO_FC|SKIP_BARRIER]
[vm1] org.apache.geode.internal.DSFIDNotFoundException: Unknown
DataSerializableFixedID: -158
[vm1] at
org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:1003)
[vm1] at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2693)
[vm1] at
org.apache.geode.DataSerializer.readObject(DataSerializer.java:2961)
[vm1] at
org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.deserializeMessage(JGroupsMessenger.java:1121)
[vm1] at
org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.readJGMessage(JGroupsMessenger.java:1013)
[vm1] at
org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1279)
[vm1] at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
[vm1] at org.jgroups.JChannel.up(JChannel.java:741)
[vm1] at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
[vm1] at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
[vm1] at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
[vm1] at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070)
[vm1] at
org.jgroups.pro

Re: DSFIDNotFoundException: Unknown DataSerializableFixedID: -158

2017-10-18 Thread Nabarun Nag

GEODE-3841 was opened to address this issue. Also complete logs of tests
that ran before and after the failed test were also added in the comment
section of the JIRA

On Wed, Oct 18, 2017 at 10:10 AM Kirk Lund  wrote:

> Here's a log snippet with the failure -- looks like there's a UDP socket
> WARN stack logged by this test before the ERROR stack. Is suspect string
> search no longer including WARN log statements?
>
> [vm2] [info 2017/10/17 21:03:46.296 UTC 
> tid=0x1b] No locator(s) found with cluster configuration service
>
> [vm2] [info 2017/10/17 21:03:46.347 UTC 
> tid=0x1b] Requesting cluster configuration
>
> [vm2] [info 2017/10/17 21:03:46.430 UTC 
> tid=0x1b] Initializing region _monitoringRegion_172.17.0.432772
>
> [vm2] [info 2017/10/17 21:03:46.437 UTC 
> tid=0x1b] Initialization of region _monitoringRegion_172.17.0.432772
> completed
>
> [vm2] 15.848: [GC (Allocation Failure) [PSYoungGen:
> 131584K->9505K(153088K)] 138902K->16831K(502784K), 0.0131806 secs] [Times:
> user=0.06 sys=0.00, real=0.01 secs]
> [vm1] [warn 2017/10/17 21:03:46.794 UTC  tid=0x155]
> Unable to send message to 172.17.0.4(155):32772
> [vm1] java.io.IOException: Operation not permitted (sendto failed)
> [vm1] at java.net.PlainDatagramSocketImpl.send(Native Method)
> [vm1] at java.net.DatagramSocket.send(DatagramSocket.java:693)
> [vm1] at org.jgroups.protocols.UDP._send(UDP.java:224)
> [vm1] at org.jgroups.protocols.UDP.sendUnicast(UDP.java:215)
> [vm1] at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1906)
> [vm1] at org.jgroups.protocols.TP.doSend(TP.java:1883)
> [vm1] at
>
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.doSend(Transport.java:86)
> [vm1] at org.jgroups.protocols.TP.send(TP.java:1869)
> [vm1] at
>
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport._send(Transport.java:52)
> [vm1] at org.jgroups.protocols.TP.down(TP.java:1474)
> [vm1] at org.jgroups.stack.Protocol.down(Protocol.java:439)
> [vm1] at
>
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.down(StatRecorder.java:89)
> [vm1] at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:675)
> [vm1] at org.jgroups.protocols.FlowControl.down(FlowControl.java:347)
> [vm1] at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
> [vm1] at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1039)
> [vm1] at org.jgroups.JChannel.down(JChannel.java:790)
> [vm1] at org.jgroups.JChannel.send(JChannel.java:426)
> [vm1] at
>
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.send(JGroupsMessenger.java:774)
> [vm1] at
>
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.sendUnreliably(JGroupsMessenger.java:629)
> [vm1] at
>
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$3.sendHeartbeats(GMSHealthMonitor.java:811)
> [vm1] at
>
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$3.sendPeriodicHeartbeats(GMSHealthMonitor.java:769)
> [vm1] at
>
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$3.run(GMSHealthMonitor.java:751)
> [vm1] at
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [vm1] at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [vm1] at java.lang.Thread.run(Thread.java:748)
>
> [locator] [info 2017/10/17 21:03:46.798 UTC  receiver,fea3cee77fa7-28483> tid=0x2a] received suspect message from
> fea3cee77fa7(150):32771 for fea3cee77fa7(155):32772: Unable to
> send messages to this member via JGroups
>
> [locator] [info 2017/10/17 21:03:46.800 UTC  2> tid=0x7f] Performing final check for suspect member
> fea3cee77fa7(155):32772 reason=Unable to send messages to this member
> via JGroups
>
> [locator] [info 2017/10/17 21:03:46.801 UTC  receiver,fea3cee77fa7-28483> tid=0x2a] No longer suspecting
> fea3cee77fa7(155):32772
>
> [locator] [info 2017/10/17 21:03:46.803 UTC  2> tid=0x7f] Final check passed for suspect member
> fea3cee77fa7(155):32772
>
> [vm1] [error 2017/10/17 21:03:46.803 UTC  receiver,fea3cee77fa7-3885> tid=0x150] Exception deserializing message
> payload: [dst: 172.17.0.4:32771, src: 172.17.0.4:32769 (2
> headers), size=108 bytes, flags=OOB|DONT_BUNDLE|NO_FC|SKIP_BARRIER]
> [vm1] org.apache.geode.internal.DSFIDNotFoundException: Unknown
> DataSerializableFixedID: -158
> [vm1] at
> org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:1003)
> [vm1] at
>
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2693)
> [vm1] at
> org.apache.geode.DataSerializer.readObject(DataSerializer.java:2961)
> [vm1] at
>
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.deserializeMessage(JGroupsMessenger.java:1121)
> [vm1] at
>
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.readJGMessage(JGroupsMessenger.java:1013)
> [vm1] at
>
> org.apache.geode.distributed.

Re: [VOTE] Apache Geode release - 1.3.0 RC2

2017-10-18 Thread Swapnil Bawaskar

Ok, I will cut another release candidate. This vote is cancelled. However,
we don't really ship the examples in the geode distribution (the examples
is a different set of files: binary and src distributions). So, voting for
1.3 of geode, followed by voting for 1.3 of examples, I think should have
worked.

On Tue, Oct 17, 2017 at 2:33 PM Jared Stewart  wrote:

> If we do end up cutting a new RC, I would like to add @Experimental to
> GfshRule since it is going to be made public for the first time and I think
> the API is still being hammered out.  Any thoughts?
>
> - Jared
>
> > On Oct 17, 2017, at 2:04 PM, Dan Smith  wrote:
> >
> > -1 without the examples.
> >
> > We *could* theoretically be releasing the examples separately, but that's
> > not our current release process. The release steps include releasing the
> > examples -
> https://cwiki.apache.org/confluence/display/GEODE/Release+Steps.
> >
> > I don't think the examples release needs to wait for the outstanding PRs,
> > unless any of those are critical for 1.3.0?
> >
> > -Dan
> >
> > On Tue, Oct 17, 2017 at 11:20 AM, Swapnil Bawaskar  >
> > wrote:
> >
> >> Since geode-examples is a separate repo, I would think that it enables
> us
> >> to release independently. Can you elaborate on why not including
> examples
> >> makes it -1 for you?
> >>
> >> Yes, I will update geode-examples to expect a tgz filename before
> cutting a
> >> 1.3.0 release of examples.
> >>
> >> On Sun, Oct 15, 2017 at 8:52 PM Anthony Baker 
> wrote:
> >>
> >>> -1
> >>>
> >>> The geode-examples source should be included in this release.
> >>>
> >>> The download task in the geode-examples build also needs to be updated
> >>> since the distribution archive name has changed from .tar.gz to .tgz.
> >> Are
> >>> there any other downstream dependencies affected by this change?
> >>>
> >>> Anthony
> >>>
> >>>
>  On Oct 13, 2017, at 1:39 PM, Swapnil Bawaskar 
> >>> wrote:
> 
>  This is the second release candidate for Apache Geode, version 1.3.0.
> I
>  will send out a separate vote thread for geode-examples.
>  Thanks to all the community members for their contributions to this
>  release!
> 
>  *** Please download, test and vote by Monday, October 16, 0800 hrs
>  US Pacific. ***
> 
>  It fixes 376 issues. release notes can be found at:
> 
> >>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> >> projectId=12318420&version=12340669
> 
>  Note that we are voting upon the source tags:  rel/v1.3.0.RC2
>  https://github.com/apache/geode/tree/rel/v1.3.0.RC2
> 
>  Commit ID:
>  9e076738fc2ae40f95bd179b5c1624e664a28d61
> 
>  Source and binary files:
>  https://dist.apache.org/repos/dist/dev/geode/1.3.0.RC2
> 
>  Maven staging repo:
> 
> https://repository.apache.org/content/repositories/orgapachegeode-1033
> 
>  Geode's KEYS file containing PGP keys we use to sign the release:
>  https://github.com/apache/geode/blob/develop/KEYS
> 
>  Release Signed with Key: pub 4096R/18F902DB 2016-04-07
>  Fingerprint: E1B1 ABE3 4753 E7BA 8097 4285 8F8F 2BCC 18F9 02DB
> >>>
> >>>
> >>
>
>

Re: DSFIDNotFoundException: Unknown DataSerializableFixedID: -158

2017-10-18 Thread Bruce Schuchardt

I'm looking into this more.  I recently introduced DSFID -158 for the 
FinalCheckPassedMessage.  I added this DSFID to DataSerializableFixedID 
and I can see that change in my commit but it's not in the source on 
develop.





On 10/18/17 10:03 AM, Kirk Lund wrote:

My latest sighting of this was in
ResourceManagerDUnitTest.testRemoveDuringGetEntry which just shows this for
previously run tests:

Previously run tests: [ResourceManagerDUnitTest]

On Tue, Oct 17, 2017 at 7:30 PM, Bruce Schuchardt 
wrote:


I think this is a secure UDP test leaving something behind that's
infecting other tests.  If we can identify the previously run tests that
might help.



On 10/17/17 4:23 PM, Kirk Lund wrote:


At first I was just seeing a couple WAN tests fail with this but just now
I
had GIIDeltaDUnitTest fail due to this suspect string as well.

Anyone know what's causing this?

org.apache.geode.internal.cache.GIIDeltaDUnitTest > testSavingRVVGC
FAILED
  java.lang.AssertionError: Suspicious strings were written to the log
during this run.
  Fix the strings or use IgnoredException.addIgnoredException to
ignore.
  ---

  Found suspect string in log4j at line 916

  [error 2017/10/17 19:37:34.907 UTC  tid=0x130] Exception deserializing message
payload: [dst: 172.17.0.4:32771, src: 172.17.0.4:32769 (2
headers),
size=108 bytes, flags=OOB|DONT_BUNDLE|NO_FC|SKIP_BARRIER]
  org.apache.geode.internal.DSFIDNotFoundException: Unknown
DataSerializableFixedID: -158
  at org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.
java:1003)
  at
org.apache.geode.internal.InternalDataSerializer.basicReadOb
ject(InternalDataSerializer.java:2693)
  at org.apache.geode.DataSerializer.readObject(DataSerializer.
java:2961)
  at
org.apache.geode.distributed.internal.membership.gms.messeng
er.JGroupsMessenger.deserializeMessage(JGroupsMessenger.java:1121)
  at
org.apache.geode.distributed.internal.membership.gms.messeng
er.JGroupsMessenger.readJGMessage(JGroupsMessenger.java:1013)
  at
org.apache.geode.distributed.internal.membership.gms.messeng
er.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1279)
  at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
  at org.jgroups.JChannel.up(JChannel.java:741)
  at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
  at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
  at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
  at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070)
  at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.
java:785)
  at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426)
  at
org.apache.geode.distributed.internal.membership.gms.messeng
er.StatRecorder.up(StatRecorder.java:74)
  at
org.apache.geode.distributed.internal.membership.gms.messeng
er.AddressManager.up(AddressManager.java:72)
  at org.jgroups.protocols.TP.passMessageUp(TP.java:1601)
  at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817)
  at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
  at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1729)
  at org.jgroups.protocols.TP.receive(TP.java:1654)
  at
org.apache.geode.distributed.internal.membership.gms.messeng
er.Transport.receive(Transport.java:160)
  at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
  at java.lang.Thread.run(Thread.java:748)

Thanks,
Kirk

Re: DSFIDNotFoundException: Unknown DataSerializableFixedID: -158

2017-10-18 Thread Bruce Schuchardt

I see what's wrong.  The new message needs to be registered in 
DSFIDFactory.  I'll get a fix checked in today.



On 10/18/17 11:48 AM, Bruce Schuchardt wrote:
I'm looking into this more.  I recently introduced DSFID -158 for the 
FinalCheckPassedMessage.  I added this DSFID to 
DataSerializableFixedID and I can see that change in my commit but 
it's not in the source on develop.





On 10/18/17 10:03 AM, Kirk Lund wrote:

My latest sighting of this was in
ResourceManagerDUnitTest.testRemoveDuringGetEntry which just shows 
this for

previously run tests:

Previously run tests: [ResourceManagerDUnitTest]

On Tue, Oct 17, 2017 at 7:30 PM, Bruce Schuchardt 


wrote:


I think this is a secure UDP test leaving something behind that's
infecting other tests.  If we can identify the previously run tests 
that

might help.



On 10/17/17 4:23 PM, Kirk Lund wrote:

At first I was just seeing a couple WAN tests fail with this but 
just now

I
had GIIDeltaDUnitTest fail due to this suspect string as well.

Anyone know what's causing this?

org.apache.geode.internal.cache.GIIDeltaDUnitTest > testSavingRVVGC
FAILED
  java.lang.AssertionError: Suspicious strings were written to 
the log

during this run.
  Fix the strings or use IgnoredException.addIgnoredException to
ignore.
---

  Found suspect string in log4j at line 916

  [error 2017/10/17 19:37:34.907 UTC receiver,4f2f4190aa4e-57131> tid=0x130] Exception deserializing 
message

payload: [dst: 172.17.0.4:32771, src: 172.17.0.4:32769 (2
headers),
size=108 bytes, flags=OOB|DONT_BUNDLE|NO_FC|SKIP_BARRIER]
  org.apache.geode.internal.DSFIDNotFoundException: Unknown
DataSerializableFixedID: -158
  at org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.
java:1003)
  at
org.apache.geode.internal.InternalDataSerializer.basicReadOb
ject(InternalDataSerializer.java:2693)
  at org.apache.geode.DataSerializer.readObject(DataSerializer.
java:2961)
  at
org.apache.geode.distributed.internal.membership.gms.messeng
er.JGroupsMessenger.deserializeMessage(JGroupsMessenger.java:1121)
  at
org.apache.geode.distributed.internal.membership.gms.messeng
er.JGroupsMessenger.readJGMessage(JGroupsMessenger.java:1013)
  at
org.apache.geode.distributed.internal.membership.gms.messeng
er.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1279) 


  at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
  at org.jgroups.JChannel.up(JChannel.java:741)
  at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
  at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
  at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
  at 
org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070)

  at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.
java:785)
  at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426)
  at
org.apache.geode.distributed.internal.membership.gms.messeng
er.StatRecorder.up(StatRecorder.java:74)
  at
org.apache.geode.distributed.internal.membership.gms.messeng
er.AddressManager.up(AddressManager.java:72)
  at org.jgroups.protocols.TP.passMessageUp(TP.java:1601)
  at 
org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817)
  at 
org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)

  at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1729)
  at org.jgroups.protocols.TP.receive(TP.java:1654)
  at
org.apache.geode.distributed.internal.membership.gms.messeng
er.Transport.receive(Transport.java:160)
  at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
  at java.lang.Thread.run(Thread.java:748)

Thanks,
Kirk

[VOTE] Apache Geode release - 1.3.0 RC3

2017-10-18 Thread Swapnil Bawaskar

This is the third release candidate for Apache Geode, version 1.3.0.
Thanks to all the community members for their contributions to this
release!

*** Please download, test and vote by Monday, October 23, 0800 hrs
US Pacific. ***

It fixes 376 issues. release notes can be found at:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420&version=12340669

Note that we are voting upon the source tags:  rel/v1.3.0.RC3
https://github.com/apache/geode/tree/rel/v1.3.0.RC3
https://github.com/apache/geode-examples/tree/rel/v1.3.0.RC3

Commit ID:
9e076738fc2ae40f95bd179b5c1624e664a28d61 (geode)
4ff8f8eafd0927888e711ee45d283ab07d345000   (geode-examples)

Source and binary files:
 https://dist.apache.org/repos/dist/dev/geode/1.3.0.RC3

Maven staging repo:
https://repository.apache.org/content/repositories/orgapachegeode-1034


Geode's KEYS file containing PGP keys we use to sign the release:
 https://github.com/apache/geode/blob/develop/KEYS

Release Signed with Key: pub 4096R/18F902DB 2016-04-07
Fingerprint: E1B1 ABE3 4753 E7BA 8097 4285 8F8F 2BCC 18F9 02DB

Errored: apache/geode-examples#95 (rel/v1.3.0.RC3 - 4ff8f8e)

2017-10-18 Thread Travis CI

Build Update for apache/geode-examples
-

Build: #95
Status: Errored

Duration: 1 minute and 29 seconds
Commit: 4ff8f8e (rel/v1.3.0.RC3)
Author: Swapnil Bawaskar
Message: - removing SNAPSHOT from release version
- change geode distribution extenstion from tar.gz to tgz

View the changeset: 
https://github.com/apache/geode-examples/compare/rel/v1.3.0.RC3

View the full build log and details: 
https://travis-ci.org/apache/geode-examples/builds/289685442?utm_source=email&utm_medium=notification

--

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

Errored: apache/geode-examples#96 (develop - bf9ab05)

2017-10-18 Thread Travis CI

Build Update for apache/geode-examples
-

Build: #96
Status: Errored

Duration: 1 minute and 17 seconds
Commit: bf9ab05 (develop)
Author: Swapnil Bawaskar
Message: bump version

View the changeset: 
https://github.com/apache/geode-examples/compare/e55efcc77380...bf9ab058379b

View the full build log and details: 
https://travis-ci.org/apache/geode-examples/builds/289691752?utm_source=email&utm_medium=notification

--

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

Re: [VOTE] C++ standardize on return values only

2017-10-18 Thread Mark Hanson

Hello All,

So in doing some work on this subject, we have come across a case that
David and I believed was worth raising for discussion.

As one might expect, at some point, someone is going to pass in a buffer
and a length into a function and expect data put into that buffer, e.g.

On Tue, Oct 3, 2017 at 4:26 PM, Jacob Barrett  wrote:

> Voting on the conversation around C++ return values vs. out parameters.
> This vote is to adopt the standard of return values over the use of out
> parameters. On functions that must return more than one value to use the
> C++11 std::tuple type for future compatibility with C++17.
>
> For example:
>
> std::tuple foo::getAAndB() {...}
>
> And call it with:
>
> int a;
> std::string b;
> std::tie(a, b) = foo.getAAndB();
>
> Alternatively the tuple can be called like:
>
> auto r = foo.getAAndB();
> auto a = std::get<0>(r);
> auto b = std::get<1>(r);
>
> In C++17:
>
> auto [a, b] = foo.getAAndB();
>
>
>
> Rather than:
>
> int foo::getAAndB(std::string& b) {...}
>
> Called like
>
> std::string b;
> auto a = foo.getAAndB(b);
>
> -Jake
>

Re: [VOTE] C++ standardize on return values only

2017-10-18 Thread Jacob Barrett



> On Oct 18, 2017, at 2:49 PM, Mark Hanson  wrote:
> So in doing some work on this subject, we have come across a case that
> David and I believed was worth raising for discussion.
> 
> As one might expect, at some point, someone is going to pass in a buffer
> and a length into a function and expect data put into that buffer, e.g.

And did you have a position to discuss?

Passing a buffer to get filled is an ok exception. 

-Jake

Re: [VOTE] C++ standardize on return values only

2017-10-18 Thread Mark Hanson

Sorry about that last email...  to begin again

Hello All,

So in doing some work on this subject, we have come across a case that David 
and I believed was worth raising for discussion.

As one might expect, at some point, someone is going to pass in a buffer and a 
length into a function and expect data put into that buffer, e.g.
inline void readBytesOnly(int8_t* buffer, uint32_t len) {
  if (len > 0) {
checkBufferSize(len);
std::memcpy(buffer, m_buf, len);
m_buf += len;
  }
}

That throws a kink into the whole no out variables discussion. It is 
addressable, for this question, we want to know how the community would like to 
move forward, would it be best just to leave an API like this  alone and call 
it exceptional?  Would it be best for us to allocate a std::unique_ptr, or less 
desirably a share_ptr? I could see leaving it as is, because the java API does 
this and it give greater discretion to the caller, however, I think a fine case 
can be made for using a unique_ptr as well.

From a higher level for this API only, should we get rid of this API and have 
it dealt with through its more standard types? This is kind of an end run for 
accessing generic data, if you look at it right… 

What do you think?

Thanks,
Mark


On Wed, Oct 18, 2017 at 2:49 PM, Mark Hanson mailto:mhan...@pivotal.io>> wrote:
Hello All,

So in doing some work on this subject, we have come across a case that David 
and I believed was worth raising for discussion.

As one might expect, at some point, someone is going to pass in a buffer and a 
length into a function and expect data put into that buffer, e.g.


On Tue, Oct 3, 2017 at 4:26 PM, Jacob Barrett mailto:jbarr...@pivotal.io>> wrote:
Voting on the conversation around C++ return values vs. out parameters.
This vote is to adopt the standard of return values over the use of out
parameters. On functions that must return more than one value to use the
C++11 std::tuple type for future compatibility with C++17.

For example:

std::tuple foo::getAAndB() {...}

And call it with:

int a;
std::string b;
std::tie(a, b) = foo.getAAndB();

Alternatively the tuple can be called like:

auto r = foo.getAAndB();
auto a = std::get<0>(r);
auto b = std::get<1>(r);

In C++17:

auto [a, b] = foo.getAAndB();



Rather than:

int foo::getAAndB(std::string& b) {...}

Called like

std::string b;
auto a = foo.getAAndB(b);

-Jake

Re: [VOTE] C++ standardize on return values only

2017-10-18 Thread Michael William Dodge

I have seen the uint8_t *, uint32_t tuple mostly with C-style system level 
calls (e.g., reading from a resource). Perhaps these could be allowed to remain 
as part of lowering impedance with a legacy API.

Sarge

> On 18 Oct, 2017, at 15:08, Mark Hanson  wrote:
> 
> Sorry about that last email...  to begin again
> 
> Hello All,
> 
> So in doing some work on this subject, we have come across a case that David 
> and I believed was worth raising for discussion.
> 
> As one might expect, at some point, someone is going to pass in a buffer and 
> a length into a function and expect data put into that buffer, e.g.
> inline void readBytesOnly(int8_t* buffer, uint32_t len) {
>  if (len > 0) {
>checkBufferSize(len);
>std::memcpy(buffer, m_buf, len);
>m_buf += len;
>  }
> }
> 
> That throws a kink into the whole no out variables discussion. It is 
> addressable, for this question, we want to know how the community would like 
> to move forward, would it be best just to leave an API like this  alone and 
> call it exceptional?  Would it be best for us to allocate a std::unique_ptr, 
> or less desirably a share_ptr? I could see leaving it as is, because the java 
> API does this and it give greater discretion to the caller, however, I think 
> a fine case can be made for using a unique_ptr as well.
> 
> From a higher level for this API only, should we get rid of this API and have 
> it dealt with through its more standard types? This is kind of an end run for 
> accessing generic data, if you look at it right… 
> 
> What do you think?
> 
> Thanks,
> Mark
> 
> 
> On Wed, Oct 18, 2017 at 2:49 PM, Mark Hanson  > wrote:
> Hello All,
> 
> So in doing some work on this subject, we have come across a case that David 
> and I believed was worth raising for discussion.
> 
> As one might expect, at some point, someone is going to pass in a buffer and 
> a length into a function and expect data put into that buffer, e.g.
> 
> 
> On Tue, Oct 3, 2017 at 4:26 PM, Jacob Barrett  > wrote:
> Voting on the conversation around C++ return values vs. out parameters.
> This vote is to adopt the standard of return values over the use of out
> parameters. On functions that must return more than one value to use the
> C++11 std::tuple type for future compatibility with C++17.
> 
> For example:
> 
> std::tuple foo::getAAndB() {...}
> 
> And call it with:
> 
> int a;
> std::string b;
> std::tie(a, b) = foo.getAAndB();
> 
> Alternatively the tuple can be called like:
> 
> auto r = foo.getAAndB();
> auto a = std::get<0>(r);
> auto b = std::get<1>(r);
> 
> In C++17:
> 
> auto [a, b] = foo.getAAndB();
> 
> 
> 
> Rather than:
> 
> int foo::getAAndB(std::string& b) {...}
> 
> Called like
> 
> std::string b;
> auto a = foo.getAAndB(b);
> 
> -Jake
> 
>

Re: [VOTE] C++ standardize on return values only

2017-10-18 Thread Jacob Barrett

Stick with the out variable on this one and any others like this that are 
consistent with the Java API. The primary goal was to remove the very odd void 
readInt(int& int) calls.


> On Oct 18, 2017, at 3:08 PM, Mark Hanson  wrote:
> 
> Sorry about that last email...  to begin again
> 
> Hello All,
> 
> So in doing some work on this subject, we have come across a case that David 
> and I believed was worth raising for discussion.
> 
> As one might expect, at some point, someone is going to pass in a buffer and 
> a length into a function and expect data put into that buffer, e.g.
> inline void readBytesOnly(int8_t* buffer, uint32_t len) {
>  if (len > 0) {
>checkBufferSize(len);
>std::memcpy(buffer, m_buf, len);
>m_buf += len;
>  }
> }
> 
> That throws a kink into the whole no out variables discussion. It is 
> addressable, for this question, we want to know how the community would like 
> to move forward, would it be best just to leave an API like this  alone and 
> call it exceptional?  Would it be best for us to allocate a std::unique_ptr, 
> or less desirably a share_ptr? I could see leaving it as is, because the java 
> API does this and it give greater discretion to the caller, however, I think 
> a fine case can be made for using a unique_ptr as well.
> 
> From a higher level for this API only, should we get rid of this API and have 
> it dealt with through its more standard types? This is kind of an end run for 
> accessing generic data, if you look at it right… 
> 
> What do you think?
> 
> Thanks,
> Mark
> 
> 
> On Wed, Oct 18, 2017 at 2:49 PM, Mark Hanson  > wrote:
> Hello All,
> 
> So in doing some work on this subject, we have come across a case that David 
> and I believed was worth raising for discussion.
> 
> As one might expect, at some point, someone is going to pass in a buffer and 
> a length into a function and expect data put into that buffer, e.g.
> 
> 
> On Tue, Oct 3, 2017 at 4:26 PM, Jacob Barrett  > wrote:
> Voting on the conversation around C++ return values vs. out parameters.
> This vote is to adopt the standard of return values over the use of out
> parameters. On functions that must return more than one value to use the
> C++11 std::tuple type for future compatibility with C++17.
> 
> For example:
> 
> std::tuple foo::getAAndB() {...}
> 
> And call it with:
> 
> int a;
> std::string b;
> std::tie(a, b) = foo.getAAndB();
> 
> Alternatively the tuple can be called like:
> 
> auto r = foo.getAAndB();
> auto a = std::get<0>(r);
> auto b = std::get<1>(r);
> 
> In C++17:
> 
> auto [a, b] = foo.getAAndB();
> 
> 
> 
> Rather than:
> 
> int foo::getAAndB(std::string& b) {...}
> 
> Called like
> 
> std::string b;
> auto a = foo.getAAndB(b);
> 
> -Jake
> 
>

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

2017-10-18 Thread Spring CI


---
Spring Data GemFire > Nightly-ApacheGeode > #713 was successful.
---
Scheduled
2184 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Errored: apache/geode-examples#96 (develop - bf9ab05)

2017-10-18 Thread Travis CI

Build Update for apache/geode-examples
-

Build: #96
Status: Errored

Duration: 1 minute and 17 seconds
Commit: bf9ab05 (develop)
Author: Swapnil Bawaskar
Message: bump version

View the changeset: 
https://github.com/apache/geode-examples/compare/e55efcc77380...bf9ab058379b

View the full build log and details: 
https://travis-ci.org/apache/geode-examples/builds/289691752?utm_source=email&utm_medium=notification

--

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

Build failed in Jenkins: Geode-nightly #988

2017-10-18 Thread Apache Jenkins Server

See 


Changes:

[upthewaterspout] GEODE-3568: User can set a LuceneSerializer through the Java 
API

[upthewaterspout] GEODE-3240: Refactor LuceneSerializer to have only a 
toDocuments method

[upthewaterspout] GEODE-3240: Moving LuceneSerializer to the public package

[upthewaterspout] GEODE-3240: Start of public API for setLuceneSerializer

[gzhou] GEODE-3240: add implementation for java api of set serializer   

[gzhou] GEODE-3569: save the serializer class name into

[lhughesgodfrey] GEODE-3241: User can set a LuceneSerializer through XML

[gzhou] GEODE-3606: add index as parameter for toDocuments()

[gzhou] GEODE-3273: catch serializer's exception for current event, 

[gzhou] GEODE-3273: If serializer returns empty, should update index.   

[gzhou] GEODE-3275: test LuceneSerializer should not cause PDX values to be

[dsmith] GEODE-3242, GEODE-3243: Add gfsh support for LuceneSerializer

[dsmith] GEODE-3242: Adding lucene serializer to describe command

[gzhou] GEODE-3244: provide a build in LuceneSerializer that flattens objects

[jstewart] GEODE-3827: SecurityManager does not leak between separate

[bschuchardt] GEODE-3846 create a 1.3.0 test set in geode-old-versions

[kohlmu-pivotal] GEODE-3774: moved service loader initialization around to avoid

[kohlmu-pivotal] GEODE-3774: Amended TCPServer code to store the loader and not 
the

[kohlmu-pivotal] GEODE-3774: Amended ProtobufProtocolService.java to create 
statistics

[kohlmu-pivotal] GEODE-2542: Push DH keys when locator becomes coordinator

[github] GEODE-3798: Refactor backup script code (#932)

[dsmith] GEODE-3784: Removing old function timeout test and adding a better one

[gzhou] GEODE-3727: FlatFormatSerializer should support collection

--
[...truncated 120.56 KB...]
:geode-lucene:sourcesJar
:geode-lucene:signArchives SKIPPED
:geode-old-client-support:jar
:geode-old-client-support:javadoc
:geode-old-client-support:javadocJar
:geode-old-client-support:sourcesJar
:geode-old-client-support:signArchives SKIPPED
:geode-protobuf:jar
:geode-protobuf:javadoc
:geode-protobuf:javadocJar
:geode-protobuf:sourcesJar
:geode-protobuf:signArchives SKIPPED
:geode-pulse:javadoc
:geode-pulse:javadocJar
:geode-pulse:sourcesJar
:geode-pulse:war
:geode-pulse:signArchives SKIPPED
:geode-rebalancer:jar
:geode-rebalancer:javadoc
:geode-rebalancer:javadocJar
:geode-rebalancer:sourcesJar
:geode-rebalancer:signArchives SKIPPED
:geode-wan:jar
:geode-wan:javadoc
:geode-wan:javadocJar
:geode-wan:sourcesJar
:geode-wan:signArchives SKIPPED
:geode-web:javadoc NO-SOURCE
:geode-web:javadocJar
:geode-web:sourcesJar
:geode-web:war
:geode-web:signArchives SKIPPED
:geode-web-api:javadoc
:geode-web-api:javadocJar
:geode-web-api:sourcesJar
:geode-web-api:war
:geode-web-api:signArchives SKIPPED
:geode-assembly:installDist
:geode-pulse:jar
:geode-assembly:compileTestJava
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/cargo-core-uberjar/1.6.3/cargo-core-uberjar-1.6.3.pom
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/cargo-core/1.6.3/cargo-core-1.6.3.pom
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/codehaus-cargo/1.6.3/codehaus-cargo-1.6.3.pom
Download 
https://repo1.maven.org/maven2/commons-discovery/commons-discovery/0.5/commons-discovery-0.5.pom
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/cargo-core-uberjar/1.6.3/cargo-core-uberjar-1.6.3.jar
Download 
https://repo1.maven.org/maven2/commons-discovery/commons-discovery/0.5/commons-discovery-0.5.jar
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:geode-assembly:processTestResources
:geode-assembly:testClasses
:geode-assembly:acceptanceTest
:extensions/geode-modules-assembly:jar
:extensions/geode-modules-assembly:signArchives SKIPPED
:extensions/geode-modules-assembly:assemble
:extensions/geode-modules-assembly:compileTestJava NO-SOURCE
:extensions/geode-modules-assembly:processTestResources NO-SOURCE
:extensions/geode-modules-assembly:testClasses UP-TO-DATE
:extensions/geode-modules-assembly:checkMissedTests NO-SOURCE
:extensions/geode-modules-assembly:spotlessJavaCheck
:extensions/geode-modules-assembly:spotlessCheck
:extensions/geode-modules-assembly:test NO-SOURCE
:extensions/geode-modules-assembly:check
:extensions/geode-modules-assembly:build
:extensions/geode-modules-assembly:distributedTest NO-SOURCE
:extensions/geode-modules-assembly:integrationTest NO-SOURCE
:extensions/geode-modules-session:compileTestJava
Download 
https://repo1.maven.org/maven2/com/mockrunner/mockrunner-servlet/1.1.2/mockrunner-servlet-1.1.2.pom
Download 
https://repo1.maven.org/maven2/com/mockrunner/mockrunner/1.1.2/mockrunner-1.1.2.pom
Download 
https://repo1.maven.org/maven2/com/mo

Build failed in Jenkins: Geode-nightly-flaky #153

2017-10-18 Thread Apache Jenkins Server

See 


Changes:

[upthewaterspout] GEODE-3568: User can set a LuceneSerializer through the Java 
API

[upthewaterspout] GEODE-3240: Refactor LuceneSerializer to have only a 
toDocuments method

[upthewaterspout] GEODE-3240: Moving LuceneSerializer to the public package

[upthewaterspout] GEODE-3240: Start of public API for setLuceneSerializer

[gzhou] GEODE-3240: add implementation for java api of set serializer   

[gzhou] GEODE-3569: save the serializer class name into

[lhughesgodfrey] GEODE-3241: User can set a LuceneSerializer through XML

[gzhou] GEODE-3606: add index as parameter for toDocuments()

[gzhou] GEODE-3273: catch serializer's exception for current event, 

[gzhou] GEODE-3273: If serializer returns empty, should update index.   

[gzhou] GEODE-3275: test LuceneSerializer should not cause PDX values to be

[dsmith] GEODE-3242, GEODE-3243: Add gfsh support for LuceneSerializer

[dsmith] GEODE-3242: Adding lucene serializer to describe command

[gzhou] GEODE-3244: provide a build in LuceneSerializer that flattens objects

[jstewart] GEODE-3827: SecurityManager does not leak between separate

[bschuchardt] GEODE-3846 create a 1.3.0 test set in geode-old-versions

[kohlmu-pivotal] GEODE-3774: moved service loader initialization around to avoid

[kohlmu-pivotal] GEODE-3774: Amended TCPServer code to store the loader and not 
the

[kohlmu-pivotal] GEODE-3774: Amended ProtobufProtocolService.java to create 
statistics

[kohlmu-pivotal] GEODE-2542: Push DH keys when locator becomes coordinator

[github] GEODE-3798: Refactor backup script code (#932)

[dsmith] GEODE-3784: Removing old function timeout test and adding a better one

[gzhou] GEODE-3727: FlatFormatSerializer should support collection

[github] GEODE-2563: fix flaky test (#942)

[github] GEODE-3819: correctly set the result status code when building the re…

[khowe] GEODE-3299: refactor functions to get Cache from FunctionContext

[khowe] GEODE-3299: Remove unneeded constructor

[dbarnes] GEODE-2405 Update docs with changes to export cluster-configuration

[bschuchardt] GEODE-3841 CI Failure :

[dsmith] Parameterizing LuceneSerializer with a type

[gosullivan] GEODE-3614 remove JUnit3CacheTestCase, cleanup JUnit4CacheTestCase

[nabarunnag] GEODE-3708: Added a separate iterator for MemoryIndexStore which 
doesn't

[github] GEODE-3857: Pulse login fails after second login (#939)

[github] GEODE-3538 Update doc section Running Geode Server Processes (#945)

[github] GEODE-3701 Emphasize performance penalty of hash indexes in docs (#949)

[github] GEODE-3026: Removed the AsyncEventQueue for the Lucene index if the

--
[...truncated 110.40 KB...]
Download 
https://repo1.maven.org/maven2/org/springframework/hateoas/spring-hateoas/0.23.0.RELEASE/spring-hateoas-0.23.0.RELEASE.jar
Download 
https://repo1.maven.org/maven2/com/fasterxml/jackson/module/jackson-module-paranamer/2.8.6/jackson-module-paranamer-2.8.6.jar
Download 
https://repo1.maven.org/maven2/io/swagger/swagger-annotations/1.5.10/swagger-annotations-1.5.10.jar
Download 
https://repo1.maven.org/maven2/io/swagger/swagger-models/1.5.10/swagger-models-1.5.10.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-spi/2.6.1/springfox-spi-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-schema/2.6.1/springfox-schema-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger-common/2.6.1/springfox-swagger-common-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-spring-web/2.6.1/springfox-spring-web-2.6.1.jar
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin-core/1.2.0.RELEASE/spring-plugin-core-1.2.0.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin-metadata/1.2.0.RELEASE/spring-plugin-metadata-1.2.0.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/mapstruct/mapstruct/1.0.0.Final/mapstruct-1.0.0.Final.jar
Download 
https://repo1.maven.org/maven2/com/thoughtworks/paranamer/paranamer/2.8/paranamer-2.8.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-core/2.6.1/springfox-core-2.6.1.jar
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:geode-web-api:processResources
:geode-web-api:classes
:geode-assembly:docs:44:
 warning - Tag @link: reference not found: Field.Store#NO
:44:
 warning - Tag @link: reference not found: Field.Store#NO

geode and open JDK / newer version of java

Re: geode and open JDK / newer version of java

Re: DSFIDNotFoundException: Unknown DataSerializableFixedID: -158

Re: DSFIDNotFoundException: Unknown DataSerializableFixedID: -158

Re: DSFIDNotFoundException: Unknown DataSerializableFixedID: -158

Re: [VOTE] Apache Geode release - 1.3.0 RC2

Re: DSFIDNotFoundException: Unknown DataSerializableFixedID: -158

Re: DSFIDNotFoundException: Unknown DataSerializableFixedID: -158

[VOTE] Apache Geode release - 1.3.0 RC3

Errored: apache/geode-examples#95 (rel/v1.3.0.RC3 - 4ff8f8e)

Errored: apache/geode-examples#96 (develop - bf9ab05)

Re: [VOTE] C++ standardize on return values only

Re: [VOTE] C++ standardize on return values only

Re: [VOTE] C++ standardize on return values only

Re: [VOTE] C++ standardize on return values only

Re: [VOTE] C++ standardize on return values only

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

Errored: apache/geode-examples#96 (develop - bf9ab05)

Build failed in Jenkins: Geode-nightly #988

Build failed in Jenkins: Geode-nightly-flaky #153

20 matches

Site Navigation

Mail list logo

Footer information