Re: Orphaned Server processes

[Jens Deppe]

Also, don't forget that you can start a server in a 'wait for locator' mode
(I forget the actual option) which should be distinguished from an actual
'orphaned' instance.

--Jens

On Wed, Apr 5, 2017 at 3:54 PM, Michael Stolz  wrote:

> I think the current behavior is probably left over from the multicast
> member discovery days, which are...thankfully...behind us.
>
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771
>
> On Wed, Apr 5, 2017 at 6:53 PM, Michael Stolz  wrote:
>
> > Anyway, at the very least it's an unusual configuration, so it would be
> > best if it required some explicit option to start server to say "Yes I
> know
> > what I'm doing...I really want a server that has no peers and no
> locator."
> >
> > Without that explicit acknowledgement it should just fail and report the
> > reason why.
> >
> >
> > --
> > Mike Stolz
> > Principal Engineer, GemFire Product Manager
> > Mobile: +1-631-835-4771 <(631)%20835-4771>
> >
> > On Wed, Apr 5, 2017 at 6:50 PM, Udo Kohlmeyer 
> > wrote:
> >
> >> I disagree
> >>
> >> +1 you can use stop/status by pointing at the directory where the server
> >> is logging.
> >>
> >> -1 You cannot connect to the server and issue the command "create
> region"
> >> or at the simplest "list members".
> >>
> >> The GFSH/management behavior should exactly the same as what one would
> >> have when one is "connected" to the system via locator/jmx
> >>
> >> --Udo
> >>
> >>
> >>
> >> On 4/5/17 15:47, Kirk Lund wrote:
> >>
> >>> But you can interact with it...
> >>>
> >>> 1) You can issue "stop server --dir=server1" which will stop it
> >>>
> >>> 2) You can issue "status server --dir=server1" which will show the
> status
> >>> for it
> >>>
> >>> 3) You can attach with JConsole and manipulate the MBeans. If the
> MBeans
> >>> have operations to create something you can invoke those. You can even
> >>> pass
> >>> gfsh commands to the server via MemberMXBean#processCommand. Is this
> >>> ideal?
> >>> No, but it's still "interactive" and not "orphaned."
> >>>
> >>> 4) Geode has a search pattern to search for cache.xml and if it finds
> one
> >>> it will use it. Perhaps the directly server1/ already exists and
> >>> contains a
> >>> cache.xml. Perhaps you have a cache.xml sitting in your user.home. So
> >>> even
> >>> if you specify the "start server --name=server1" as you state, it may
> >>> still
> >>> find a cache.xml to configure itself. I'm not saying this is better
> than
> >>> using GFSH to configure the server, but it exists today and your
> proposal
> >>> should explain how and why the search pattern for cache.xml is going
> away
> >>> or something like that if you do in fact want this feature to go away.
> >>>
> >>> -Kirk
> >>>
> >>> On Wed, Apr 5, 2017 at 3:18 PM, Udo Kohlmeyer 
> >>> wrote:
> >>>
> >>> Once again..
> 
>  you missing the point... starting a server with "start server
>  --name=server1" without a locator or cache.xml or jmx-manager
>  you
>  have created a useless server which you cannot interact with We
>  need to
>  avoid that...
> 
>  All the other discussions of how we can start an embedded locator or
> add
>  extra properties to the starting of the server... is just noise...
> 
>  The problem is... we allow for the creation of a server that cannot be
>  accessed other than through a client pool... Which as a matter of fact
>  cannot do anything with the server, OTHER than confirming it could
>  connect
>  to the server
> 
> 
> 
>  On 4/5/17 13:10, Anilkumar Gingade wrote:
> 
>  One could create data model using cache.xml or embedded
> > application/api...The server/node could be used as front-end cache
> for
> > database to handle peek loads (or streamed data)Client
> application
> > can
> > connect to the server and register interest, execute queries,
> > function
> >
> > -Anil.
> >
> >
> > On Wed, Apr 5, 2017 at 11:03 AM, Udo Kohlmeyer <
> ukohlme...@pivotal.io>
> > wrote:
> >
> > @Anil,
> >
> >> I agree... quick start to evaluate the product... "start server
> >> --name=server1" is the simplest way to start a server... BUT there
> >> are no
> >> regions or anything ... So we really only have a GemFire process
> that
> >> does
> >> not allow you to do anything with it... except connect to it from a
> >> client
> >> and even the client cannot do anything with the server, because it
> has
> >> not
> >> admin capability.
> >>
> >> --Udo
> >>
> >>
> >> On 4/5/17 10:53, Anilkumar Gingade wrote:
> >>
> >> But does a use case for a server with no locator exist? What about
> >> ease
> >>
> >>> of development?
>  I could see that it would be easier to start just a single server
> 

Re: Review Request 58225: GEODE-2757: netsearch has a race that may return null object incorrectly

[Darrel Schneider]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58225/#review171175
---




geode-core/src/main/java/org/apache/geode/internal/cache/DistributedRegion.java
Line 2129 (original), 2129 (patched)


just get rid of the "final" instead of commenting it out



geode-core/src/main/java/org/apache/geode/internal/cache/SearchLoadAndWriteProcessor.java
Line 220 (original), 222 (patched)


did you look into using this existing "pendingResponders" instead of adding 
the new "departedMembers" list?

If you get a response message from a member that is not in 
pendingResponders then ignore it.

Hmmm... incomingResponse already checks pendingResponders so perhaps that 
part of the fix is not needed? The only problem I see is that when 
netSearchForBlob is doing the replicates one at a time it does not set 
pendingResponders



geode-core/src/main/java/org/apache/geode/internal/cache/SearchLoadAndWriteProcessor.java
Lines 229 (patched)


I think "id" would be better here than "selectedNode".
Either would be correct since you just made sure they are equal but I think 
id is clearer since it was passed to memberDeparted as the id of the member 
that departed.



geode-core/src/main/java/org/apache/geode/internal/cache/SearchLoadAndWriteProcessor.java
Lines 510 (patched)


I think this synchronization is too complicated.
Just sync here and hold it until line 532.
Both sendValueRequest and waitForObject2 are synchronized methods so it 
really does not make any sense to keep releasing the sync and reacquiring it.


- Darrel Schneider


On April 5, 2017, 3:20 p.m., Eric Shu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58225/
> ---
> 
> (Updated April 5, 2017, 3:20 p.m.)
> 
> 
> Review request for geode, anilkumar gingade and Darrel Schneider.
> 
> 
> Bugs: GEODE-2757
> https://issues.apache.org/jira/browse/GEODE-2757
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Do not process netsearch reply from a departed node that membership listener 
> already detected.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/DistributedRegion.java
>  fa02574 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/SearchLoadAndWriteProcessor.java
>  3d969f9 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/SearchLoadAndWriteProcessorTest.java
>  bfe78b0 
> 
> 
> Diff: https://reviews.apache.org/r/58225/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin.
> 
> 
> Thanks,
> 
> Eric Shu
> 
>

[jira] [Commented] (GEODE-2732) after auto-reconnect a server is restarted on the default port of 40404

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15958054#comment-15958054
 ] 

ASF subversion and git services commented on GEODE-2732:


Commit 669d3ed1f2ab7e05edfa15bb19b5782ebc05d753 in geode's branch 
refs/heads/develop from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=669d3ed ]

GEODE-2732 after auto-reconnect a server is restarted on the default port

Changes to the new test based on feedback from Galen


> after auto-reconnect a server is restarted on the default port of 40404
> ---
>
> Key: GEODE-2732
> URL: https://issues.apache.org/jira/browse/GEODE-2732
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
> Fix For: 1.2.0
>
>
> If you start a server using gfsh with the server defined in a cache.xml and 
> you specify the server's port Geode will ignore this setting in the event of 
> an auto-reconnect.  I observed this in a GemFire deployment and the code in 
> this area hasn't changed in Apache Geode.  By chance port 40404 was already 
> in use when the auto-reconnect occurred and an exception was thrown.
> {noformat}
> com.gemstone.gemfire.GemFireIOException: While starting bridge server  
> CacheServer on port=40404 client subscription config policy=none client 
> subscription config capacity=1 client subscription config overflow directory=.
>   at 
> com.gemstone.gemfire.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:611)
>   at 
> com.gemstone.gemfire.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:340)
>   at 
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4263)
>   at 
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1178)
>   at 
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.init(GemFireCacheImpl.java:1020)
>   at 
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:684)
>   at 
> com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2909)
>   at 
> com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2655)
>   at 
> com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1058)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionManager$MyListener.membershipFailure(DistributionManager.java:4822)
>   at 
> com.gemstone.gemfire.distributed.internal.membership.jgroup.JGroupMembershipManager.uncleanShutdown(JGroupMembershipManager.java:2733)
>   at 
> com.gemstone.gemfire.distributed.internal.membership.jgroup.JGroupMembershipManager$Puller.channelClosing(JGroupMembershipManager.java:1213)
>   at 
> com.gemstone.org.jgroups.JChannel$CloserThread.run(JChannel.java:1617)
> Caused by: java.net.BindException: Address already in use
>   at sun.nio.ch.Net.bind0(Native Method)
>   at sun.nio.ch.Net.bind(Net.java:463)
>   at sun.nio.ch.Net.bind(Net.java:455)
>   at 
> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
>   at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.AcceptorImpl.(AcceptorImpl.java:432)
>   at 
> com.gemstone.gemfire.internal.cache.BridgeServerImpl.start(BridgeServerImpl.java:342)
>   at 
> com.gemstone.gemfire.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:607)
>   ... 12 more
> {noformat}
> I think the fix is to get rid of the ThreadLocal storage of the port and bind 
> address in CacheServerLauncher.  These variables are used by the XML parser 
> to configure a server.  Gfsh sets them in its thread but they aren't 
> available in the auto-reconnect thread that rebuilds the cache.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2684) org.apache.geode.internal.tcp.Connection & ConnectionTable cleanup

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15958053#comment-15958053
 ] 

ASF subversion and git services commented on GEODE-2684:


Commit 742c8f27ea45ec55445f1047fda3c54b86f89f94 in geode's branch 
refs/heads/develop from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=742c8f2 ]

GEODE-2684 Connection & ConnectionTable cleanup

removed another old comment


> org.apache.geode.internal.tcp.Connection & ConnectionTable cleanup
> --
>
> Key: GEODE-2684
> URL: https://issues.apache.org/jira/browse/GEODE-2684
> Project: Geode
>  Issue Type: Task
>  Components: membership
>Reporter: Bruce Schuchardt
> Fix For: 1.2.0
>
>
> These classes contain a lot of commented-out code, poorly named methods and 
> incorrect calculations that need to be cleaned up.  For instance, Connection 
> contains this:
> short aShort = -1;
> bytes[x] = (byte)(aShort & 0xff / 0x100);
> bytes[x+1] = (byte)(aShort & 0xff);
> which is incorrect and results in bytes[x] being zero when the intent is for 
> it to be 255.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 58155: GEODE-2653: fix a flaky test.

[Galen O'Sullivan]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58155/
---

(Updated April 5, 2017, 11:44 p.m.)


Review request for geode, Bruce Schuchardt, Hitesh Khamesra, and Udo Kohlmeyer.


Changes
---

Remove a redundant assert.

I can't push this 'cause I'm not a committer.


Repository: geode


Description
---

And do some cleanup while I'm here:
 * Change Mockito's `any` to `isA`.
 * Replace some `Thread.sleep()` calls with Awaitility calls.
 * Remove our `MethodExecuted` class -- this can be done with Mockito's 
`verify()`.


Diffs (updated)
-

  
geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeaveJUnitTest.java
 05ab6f7e5 


Diff: https://reviews.apache.org/r/58155/diff/2/

Changes: https://reviews.apache.org/r/58155/diff/1-2/


Testing (updated)
---

Precheckin passed.

Ran the test suite in IntelliJ a few hundred times on my machine.


Thanks,

Galen O'Sullivan

Re: Review Request 58187: GEODE-2732 after auto-reconnect a server is restarted on the default port of 40404

[Bruce Schuchardt]

> On April 5, 2017, 11:24 p.m., Galen O'Sullivan wrote:
> > geode-core/src/main/java/org/apache/geode/internal/tcp/Connection.java
> > Line 1288 (original)
> > 
> >
> > No more JRockit! I'm hoping we've officially dropped support?

I'll remove that comment but I'm not sure we can remove the code it's attached 
to.


> On April 5, 2017, 11:24 p.m., Galen O'Sullivan wrote:
> > geode-core/src/test/java/org/apache/geode/cache30/ReconnectWithCacheXMLDUnitTest.java
> > Lines 30 (patched)
> > 
> >
> > Could you replace this with a helpful description, perhaps?

I'll replace it with this:

/**
 * This test exercises auto-reconnect functionality when there is a cache-server
 * that was started by gfsh but was configured both by gfsh and a cache.xml
 * file.  The JIRA ticket for this is GEODE-2732.
 */


> On April 5, 2017, 11:24 p.m., Galen O'Sullivan wrote:
> > geode-core/src/test/java/org/apache/geode/cache30/ReconnectWithCacheXMLDUnitTest.java
> > Lines 40 (patched)
> > 
> >
> > Why is this necessary?
> > ... wait, I'll guess. It's a distributed test, so it will need to get 
> > serialized to the other VMs in the system, but we don't need to actually 
> > check that its serialization is the same because it's the only time it will 
> > get sent, so we just set this to a bogus value?
> > 
> > (this means that serialization doesn't have an internal numerical type 
> > registry but just checks `serialVersionUID` for failure?)

I copied another test and gutted most of it to create this test class.  We set 
the serialVersionUID to 1 in lots of test classes to get rid of findbugs 
warnings.  We don't need to worry about the on-wire format of the test changing 
since all JVMs are using the same classpath so the value of this variable 
doesn't matter.


> On April 5, 2017, 11:24 p.m., Galen O'Sullivan wrote:
> > geode-core/src/test/java/org/apache/geode/cache30/ReconnectWithCacheXMLDUnitTest.java
> > Lines 75 (patched)
> > 
> >
> > Does the `CacheServerLauncher` actually get used to create a Cache?

These variables are used in various places in GemFire to discover gfsh "start 
server" settings.  I'm told they're going to be removed during a refactoring in 
the future.


- Bruce


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58187/#review171087
---


On April 4, 2017, 8:46 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58187/
> ---
> 
> (Updated April 4, 2017, 8:46 p.m.)
> 
> 
> Review request for geode, Galen O'Sullivan, Hitesh Khamesra, and Udo 
> Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Gfsh command line parameters were put into ThreadLocals to make them 
> available to the XML parser.  These are now held in non-thread-local 
> variables so that all threads, including the auto-reconnect thread, can see 
> them when building the cache.
> 
> This diff also includes some minor refactoring in 
> org.apache.geode.internal.tcp.  It primarily removes some 
> "this.owner.getConduit().doSomething" with "this.conduit.doSomething" and 
> removes dead code.
> 
> 
> Diffs
> -
> 
>   
> extensions/geode-modules-tomcat8/src/test/java/org/apache/geode/modules/session/Tomcat8SessionsClientServerDUnitTest.java
>  e475f40339e294ad48b403db1afa7aa624d5e80c 
>   geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java 
> 9435bd8178248c4fa34f6867d15a7cdfdec06d6b 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/CacheServerLauncher.java
>  760abd3d946281d474502a9af2e8fe823a011329 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/xmlcache/CacheCreation.java
>  1c3c93314841f5623c0e6387500af88f106328d9 
>   geode-core/src/main/java/org/apache/geode/internal/tcp/Connection.java 
> a0af24501a5081fe483160c5bf4fc7671545684e 
>   geode-core/src/main/java/org/apache/geode/internal/tcp/ConnectionTable.java 
> 08a90096c0cf0348c0fa34b7ff8e18806810ab68 
>   
> geode-core/src/main/java/org/apache/geode/internal/tcp/DirectReplySender.java 
> 3872ee98ec24fe95894c0def538e3752136b05c3 
>   geode-core/src/main/java/org/apache/geode/internal/tcp/MsgReader.java 
> fc5627112ac8dd456976139d3750fd951812879b 
>   geode-core/src/main/java/org/apache/geode/internal/tcp/NIOMsgReader.java 
> 50f5faedba056ec4f57124aefd56477dc11c1cf6 
>   
> 

Re: Review Request 58187: GEODE-2732 after auto-reconnect a server is restarted on the default port of 40404

[Galen O'Sullivan]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58187/#review171087
---



Looks good. I left a few questions on the test, but the non-test code looks 
rockin'. Mostly I didn't understand how the CacheServerLauncher gets used.


geode-core/src/main/java/org/apache/geode/internal/tcp/Connection.java
Line 1288 (original)


No more JRockit! I'm hoping we've officially dropped support?



geode-core/src/test/java/org/apache/geode/cache30/ReconnectWithCacheXMLDUnitTest.java
Lines 30 (patched)


Could you replace this with a helpful description, perhaps?



geode-core/src/test/java/org/apache/geode/cache30/ReconnectWithCacheXMLDUnitTest.java
Lines 40 (patched)


Why is this necessary?
... wait, I'll guess. It's a distributed test, so it will need to get 
serialized to the other VMs in the system, but we don't need to actually check 
that its serialization is the same because it's the only time it will get sent, 
so we just set this to a bogus value?

(this means that serialization doesn't have an internal numerical type 
registry but just checks `serialVersionUID` for failure?)



geode-core/src/test/java/org/apache/geode/cache30/ReconnectWithCacheXMLDUnitTest.java
Lines 75 (patched)


Does the `CacheServerLauncher` actually get used to create a Cache?



geode-core/src/test/java/org/apache/geode/cache30/ReconnectWithCacheXMLDUnitTest.java
Lines 89 (patched)


I'm trying to parse the use of an `AtomicBoolean` without Awaitility.

looks like this is guaranteed to be called once the function returns, but 
not necessarily to have been called in this thread?



geode-core/src/test/java/org/apache/geode/cache30/ReconnectWithCacheXMLDUnitTest.java
Lines 93 (patched)


So Cache is a singleton except when it gets replaced by reconnection? Whoa.


- Galen O'Sullivan


On April 4, 2017, 8:46 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58187/
> ---
> 
> (Updated April 4, 2017, 8:46 p.m.)
> 
> 
> Review request for geode, Galen O'Sullivan, Hitesh Khamesra, and Udo 
> Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Gfsh command line parameters were put into ThreadLocals to make them 
> available to the XML parser.  These are now held in non-thread-local 
> variables so that all threads, including the auto-reconnect thread, can see 
> them when building the cache.
> 
> This diff also includes some minor refactoring in 
> org.apache.geode.internal.tcp.  It primarily removes some 
> "this.owner.getConduit().doSomething" with "this.conduit.doSomething" and 
> removes dead code.
> 
> 
> Diffs
> -
> 
>   
> extensions/geode-modules-tomcat8/src/test/java/org/apache/geode/modules/session/Tomcat8SessionsClientServerDUnitTest.java
>  e475f40339e294ad48b403db1afa7aa624d5e80c 
>   geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java 
> 9435bd8178248c4fa34f6867d15a7cdfdec06d6b 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/CacheServerLauncher.java
>  760abd3d946281d474502a9af2e8fe823a011329 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/xmlcache/CacheCreation.java
>  1c3c93314841f5623c0e6387500af88f106328d9 
>   geode-core/src/main/java/org/apache/geode/internal/tcp/Connection.java 
> a0af24501a5081fe483160c5bf4fc7671545684e 
>   geode-core/src/main/java/org/apache/geode/internal/tcp/ConnectionTable.java 
> 08a90096c0cf0348c0fa34b7ff8e18806810ab68 
>   
> geode-core/src/main/java/org/apache/geode/internal/tcp/DirectReplySender.java 
> 3872ee98ec24fe95894c0def538e3752136b05c3 
>   geode-core/src/main/java/org/apache/geode/internal/tcp/MsgReader.java 
> fc5627112ac8dd456976139d3750fd951812879b 
>   geode-core/src/main/java/org/apache/geode/internal/tcp/NIOMsgReader.java 
> 50f5faedba056ec4f57124aefd56477dc11c1cf6 
>   
> geode-core/src/test/java/org/apache/geode/cache30/ReconnectWithCacheXMLDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/resources/org/apache/geode/cache30/ReconnectWithCacheXMLDUnitTest.xml
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/58187/diff/1/
> 
> 
> Testing
> ---
> 
> new test, precheckin
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

Re: Orphaned Server processes

[Michael Stolz]

I think the current behavior is probably left over from the multicast
member discovery days, which are...thankfully...behind us.


--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: +1-631-835-4771

On Wed, Apr 5, 2017 at 6:53 PM, Michael Stolz  wrote:

> Anyway, at the very least it's an unusual configuration, so it would be
> best if it required some explicit option to start server to say "Yes I know
> what I'm doing...I really want a server that has no peers and no locator."
>
> Without that explicit acknowledgement it should just fail and report the
> reason why.
>
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771 <(631)%20835-4771>
>
> On Wed, Apr 5, 2017 at 6:50 PM, Udo Kohlmeyer 
> wrote:
>
>> I disagree
>>
>> +1 you can use stop/status by pointing at the directory where the server
>> is logging.
>>
>> -1 You cannot connect to the server and issue the command "create region"
>> or at the simplest "list members".
>>
>> The GFSH/management behavior should exactly the same as what one would
>> have when one is "connected" to the system via locator/jmx
>>
>> --Udo
>>
>>
>>
>> On 4/5/17 15:47, Kirk Lund wrote:
>>
>>> But you can interact with it...
>>>
>>> 1) You can issue "stop server --dir=server1" which will stop it
>>>
>>> 2) You can issue "status server --dir=server1" which will show the status
>>> for it
>>>
>>> 3) You can attach with JConsole and manipulate the MBeans. If the MBeans
>>> have operations to create something you can invoke those. You can even
>>> pass
>>> gfsh commands to the server via MemberMXBean#processCommand. Is this
>>> ideal?
>>> No, but it's still "interactive" and not "orphaned."
>>>
>>> 4) Geode has a search pattern to search for cache.xml and if it finds one
>>> it will use it. Perhaps the directly server1/ already exists and
>>> contains a
>>> cache.xml. Perhaps you have a cache.xml sitting in your user.home. So
>>> even
>>> if you specify the "start server --name=server1" as you state, it may
>>> still
>>> find a cache.xml to configure itself. I'm not saying this is better than
>>> using GFSH to configure the server, but it exists today and your proposal
>>> should explain how and why the search pattern for cache.xml is going away
>>> or something like that if you do in fact want this feature to go away.
>>>
>>> -Kirk
>>>
>>> On Wed, Apr 5, 2017 at 3:18 PM, Udo Kohlmeyer 
>>> wrote:
>>>
>>> Once again..

 you missing the point... starting a server with "start server
 --name=server1" without a locator or cache.xml or jmx-manager
 you
 have created a useless server which you cannot interact with We
 need to
 avoid that...

 All the other discussions of how we can start an embedded locator or add
 extra properties to the starting of the server... is just noise...

 The problem is... we allow for the creation of a server that cannot be
 accessed other than through a client pool... Which as a matter of fact
 cannot do anything with the server, OTHER than confirming it could
 connect
 to the server



 On 4/5/17 13:10, Anilkumar Gingade wrote:

 One could create data model using cache.xml or embedded
> application/api...The server/node could be used as front-end cache for
> database to handle peek loads (or streamed data)Client application
> can
> connect to the server and register interest, execute queries,
> function
>
> -Anil.
>
>
> On Wed, Apr 5, 2017 at 11:03 AM, Udo Kohlmeyer 
> wrote:
>
> @Anil,
>
>> I agree... quick start to evaluate the product... "start server
>> --name=server1" is the simplest way to start a server... BUT there
>> are no
>> regions or anything ... So we really only have a GemFire process that
>> does
>> not allow you to do anything with it... except connect to it from a
>> client
>> and even the client cannot do anything with the server, because it has
>> not
>> admin capability.
>>
>> --Udo
>>
>>
>> On 4/5/17 10:53, Anilkumar Gingade wrote:
>>
>> But does a use case for a server with no locator exist? What about
>> ease
>>
>>> of development?
 I could see that it would be easier to start just a single server
 process instead of two (locator and server).

 Agree with Darrel, for someone who is evaluating the product, it
>>> helps
>>> to
>>> build quick application and play around, without getting too much
>>> into
>>> the
>>> cluster setup. Also, it is needed/helpful for use cases where its
>>> used
>>> as
>>> embedded caching.
>>>
>>> -Anil.
>>>
>>>
>>> On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider <
>>> dschnei...@pivotal.io>
>>> wrote:
>>>
>>> I 

Re: Orphaned Server processes

[Michael Stolz]

Anyway, at the very least it's an unusual configuration, so it would be
best if it required some explicit option to start server to say "Yes I know
what I'm doing...I really want a server that has no peers and no locator."

Without that explicit acknowledgement it should just fail and report the
reason why.


--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: +1-631-835-4771

On Wed, Apr 5, 2017 at 6:50 PM, Udo Kohlmeyer  wrote:

> I disagree
>
> +1 you can use stop/status by pointing at the directory where the server
> is logging.
>
> -1 You cannot connect to the server and issue the command "create region"
> or at the simplest "list members".
>
> The GFSH/management behavior should exactly the same as what one would
> have when one is "connected" to the system via locator/jmx
>
> --Udo
>
>
>
> On 4/5/17 15:47, Kirk Lund wrote:
>
>> But you can interact with it...
>>
>> 1) You can issue "stop server --dir=server1" which will stop it
>>
>> 2) You can issue "status server --dir=server1" which will show the status
>> for it
>>
>> 3) You can attach with JConsole and manipulate the MBeans. If the MBeans
>> have operations to create something you can invoke those. You can even
>> pass
>> gfsh commands to the server via MemberMXBean#processCommand. Is this
>> ideal?
>> No, but it's still "interactive" and not "orphaned."
>>
>> 4) Geode has a search pattern to search for cache.xml and if it finds one
>> it will use it. Perhaps the directly server1/ already exists and contains
>> a
>> cache.xml. Perhaps you have a cache.xml sitting in your user.home. So even
>> if you specify the "start server --name=server1" as you state, it may
>> still
>> find a cache.xml to configure itself. I'm not saying this is better than
>> using GFSH to configure the server, but it exists today and your proposal
>> should explain how and why the search pattern for cache.xml is going away
>> or something like that if you do in fact want this feature to go away.
>>
>> -Kirk
>>
>> On Wed, Apr 5, 2017 at 3:18 PM, Udo Kohlmeyer 
>> wrote:
>>
>> Once again..
>>>
>>> you missing the point... starting a server with "start server
>>> --name=server1" without a locator or cache.xml or jmx-manager you
>>> have created a useless server which you cannot interact with We need
>>> to
>>> avoid that...
>>>
>>> All the other discussions of how we can start an embedded locator or add
>>> extra properties to the starting of the server... is just noise...
>>>
>>> The problem is... we allow for the creation of a server that cannot be
>>> accessed other than through a client pool... Which as a matter of fact
>>> cannot do anything with the server, OTHER than confirming it could
>>> connect
>>> to the server
>>>
>>>
>>>
>>> On 4/5/17 13:10, Anilkumar Gingade wrote:
>>>
>>> One could create data model using cache.xml or embedded
 application/api...The server/node could be used as front-end cache for
 database to handle peek loads (or streamed data)Client application
 can
 connect to the server and register interest, execute queries,
 function

 -Anil.


 On Wed, Apr 5, 2017 at 11:03 AM, Udo Kohlmeyer 
 wrote:

 @Anil,

> I agree... quick start to evaluate the product... "start server
> --name=server1" is the simplest way to start a server... BUT there are
> no
> regions or anything ... So we really only have a GemFire process that
> does
> not allow you to do anything with it... except connect to it from a
> client
> and even the client cannot do anything with the server, because it has
> not
> admin capability.
>
> --Udo
>
>
> On 4/5/17 10:53, Anilkumar Gingade wrote:
>
> But does a use case for a server with no locator exist? What about ease
>
>> of development?
>>> I could see that it would be easier to start just a single server
>>> process instead of two (locator and server).
>>>
>>> Agree with Darrel, for someone who is evaluating the product, it
>> helps
>> to
>> build quick application and play around, without getting too much into
>> the
>> cluster setup. Also, it is needed/helpful for use cases where its used
>> as
>> embedded caching.
>>
>> -Anil.
>>
>>
>> On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider <
>> dschnei...@pivotal.io>
>> wrote:
>>
>> I like the idea of servers failing to start if no locator exists.
>>
>> But does a use case for a server with no locator exist? What about
>>> ease
>>> of
>>> development?
>>>
>>> I could see that it would be easier to start just a single server
>>> process
>>> instead of two (locator and server). But for this use case couldn't
>>> the
>>> developer just configure a colocated locator in the same server
>>> process?
>>> This would have 

Re: Orphaned Server processes

[Udo Kohlmeyer]

I disagree

+1 you can use stop/status by pointing at the directory where the server 
is logging.


-1 You cannot connect to the server and issue the command "create 
region" or at the simplest "list members".


The GFSH/management behavior should exactly the same as what one would 
have when one is "connected" to the system via locator/jmx


--Udo


On 4/5/17 15:47, Kirk Lund wrote:

But you can interact with it...

1) You can issue "stop server --dir=server1" which will stop it

2) You can issue "status server --dir=server1" which will show the status
for it

3) You can attach with JConsole and manipulate the MBeans. If the MBeans
have operations to create something you can invoke those. You can even pass
gfsh commands to the server via MemberMXBean#processCommand. Is this ideal?
No, but it's still "interactive" and not "orphaned."

4) Geode has a search pattern to search for cache.xml and if it finds one
it will use it. Perhaps the directly server1/ already exists and contains a
cache.xml. Perhaps you have a cache.xml sitting in your user.home. So even
if you specify the "start server --name=server1" as you state, it may still
find a cache.xml to configure itself. I'm not saying this is better than
using GFSH to configure the server, but it exists today and your proposal
should explain how and why the search pattern for cache.xml is going away
or something like that if you do in fact want this feature to go away.

-Kirk

On Wed, Apr 5, 2017 at 3:18 PM, Udo Kohlmeyer  wrote:


Once again..

you missing the point... starting a server with "start server
--name=server1" without a locator or cache.xml or jmx-manager you
have created a useless server which you cannot interact with We need to
avoid that...

All the other discussions of how we can start an embedded locator or add
extra properties to the starting of the server... is just noise...

The problem is... we allow for the creation of a server that cannot be
accessed other than through a client pool... Which as a matter of fact
cannot do anything with the server, OTHER than confirming it could connect
to the server



On 4/5/17 13:10, Anilkumar Gingade wrote:


One could create data model using cache.xml or embedded
application/api...The server/node could be used as front-end cache for
database to handle peek loads (or streamed data)Client application can
connect to the server and register interest, execute queries, function

-Anil.


On Wed, Apr 5, 2017 at 11:03 AM, Udo Kohlmeyer 
wrote:

@Anil,

I agree... quick start to evaluate the product... "start server
--name=server1" is the simplest way to start a server... BUT there are no
regions or anything ... So we really only have a GemFire process that
does
not allow you to do anything with it... except connect to it from a
client
and even the client cannot do anything with the server, because it has
not
admin capability.

--Udo


On 4/5/17 10:53, Anilkumar Gingade wrote:

But does a use case for a server with no locator exist? What about ease

of development?
I could see that it would be easier to start just a single server
process instead of two (locator and server).


Agree with Darrel, for someone who is evaluating the product, it helps
to
build quick application and play around, without getting too much into
the
cluster setup. Also, it is needed/helpful for use cases where its used
as
embedded caching.

-Anil.


On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider <
dschnei...@pivotal.io>
wrote:

I like the idea of servers failing to start if no locator exists.


But does a use case for a server with no locator exist? What about ease
of
development?

I could see that it would be easier to start just a single server
process
instead of two (locator and server). But for this use case couldn't the
developer just configure a colocated locator in the same server
process?
This would have the benefit of the clients during development and
production using a locator consistently.

Is it true that the server with no locator will never have any peer
members
in its cluster?
Clients can still connect to this singleton server by being configured
with
the server host and port instead of the locator.


On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao 
wrote:

Without connecting to the server, I think you can still stop it by


specifying --pid or --dir in "stop server" command.

On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer 

Re: Orphaned Server processes

[Kirk Lund]

"--start-locator=" was originally present on "start server" but was
commented out for some reason. You can find the lines in CliStrings.java:

// public static final String START_SERVER__START_LOCATOR = "start-locator";
// public static final String START_SERVER__START_LOCATOR__HELP =
// "To start embedded Locator with given endpoints in the format:
host[port]. If no endpoints are
// given defaults (localhost[10334]) are assumed.";

I don't know why it was removed or why it was dead-coded instead of
deleting it.

-Kirk

On Wed, Apr 5, 2017 at 3:18 PM, Swapnil Bawaskar 
wrote:

> +1 to add a "--start-locator=" option for starting an embedded locator.
> However, I can easily see a user starting two servers and expecting to form
> a distributed system, but if we start the embedded locator by default, they
> won't.
> So, I think we should prevent the server from starting up, but give an
> error message to either start a locator or use the --start-locator option.
>
> On Wed, Apr 5, 2017 at 2:50 PM Kirk Lund  wrote:
>
> > You can still control a lone server with GFSH. And if you configure it up
> > front, then you can still have Regions for a Client to use.
> >
> > $ start server --name=server1 --cache-xml-file=mycachefile.xml
> >
> > 
> >
> > $ stop server --dir=server1
> >
> > You could also start a JMX Manager in the server or an embedded Locator
> as
> > others have mentioned. I'm not sure if it's possible to startup cluster
> > config service in a server or if that comes for free when you start an
> > embedded Locator.
> >
> > -Kirk
> >
> > On Wed, Apr 5, 2017 at 12:26 PM, Jianxia Chen  wrote:
> >
> > > Thanks Jinmei! You are right. I missed that.
> > >
> > > Thanks,
> > > Jianxia
> > >
> > > On Wed, Apr 5, 2017 at 12:24 PM, Jinmei Liao 
> wrote:
> > >
> > > > for your #1, there is a --properties-file option when you do "start
> > > > server".
> > > >
> > > > On Wed, Apr 5, 2017 at 12:20 PM, Jianxia Chen 
> > wrote:
> > > >
> > > > > Thank you William!
> > > > >
> > > > > I tried with it. It works. But there is something tricky in order
> to
> > > > start
> > > > > the embedded locator.
> > > > >
> > > > > 1) the gemfire.properties file has to be in the right place, either
> > in
> > > > the
> > > > > server directory or home directory. Looks like this is not
> > documented.
> > > > > I was trying to specify the properties file in gfsh when starting
> > > server.
> > > > > However, there is no such option for `start server` command. There
> is
> > > an
> > > > > `--security-properties-file` option though, for
> > gfsecurity.properties.
> > > > >
> > > > > 2) jmx-manager has to be true. Otherwise the embedded locator won't
> > > > start.
> > > > > The server can be started successfully though.
> > > > >
> > > > > Thanks,
> > > > > Jianxia
> > > > >
> > > > > On Wed, Apr 5, 2017 at 11:03 AM, William Markito Oliveira <
> > > > > william.mark...@gmail.com> wrote:
> > > > >
> > > > > > Jianxia, you can set the property "start-locator" in
> > > gemfire.properties
> > > > > as
> > > > > > below...  So the server then will have an embedded locator.
> > > > > >
> > > > > > http://geode.apache.org/docs/guide/11/reference/topics/
> > > > > > gemfire_properties.html
> > > > > > start-locator If set, automatically starts a locator in the
> current
> > > > > process
> > > > > > when the member connects to the distributed system and stops the
> > > > locator
> > > > > > when the member disconnects.
> > > > > >
> > > > > > To use, specify the locator with an optional address or host
> > > > > specification
> > > > > > and a required port number, in one of these formats:
> > > > > >
> > > > > > start-locator=address[port1]
> > > > > >
> > > > > > start-locator=port1
> > > > > >
> > > > > > If you only specify the port, the address assigned to the member
> is
> > > > used
> > > > > > for the locator.
> > > > > >
> > > > > > If not already there, this locator is automatically added to the
> > list
> > > > of
> > > > > > locators in this set of gemfire properties.
> > > > > > *not set*
> > > > > >
> > > > > > On Wed, Apr 5, 2017 at 12:50 PM, Jianxia Chen 
> > > > wrote:
> > > > > >
> > > > > > > Hi Darrel,
> > > > > > >
> > > > > > > How to configure a colocated locator in the same server
> process?
> > > Just
> > > > > > > curious. What I understand is that the locator is in its own
> > > process.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Jianxia
> > > > > > >
> > > > > > > On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider <
> > > > > dschnei...@pivotal.io
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I like the idea of servers failing to start if no locator
> > exists.
> > > > > > > > But does a use case for a server with no locator exist? What
> > > about
> > > > > ease
> > > > > > > of
> > > > > > > > development?
> > > > > > > >
> > > > > > > > I could see that it would be easier to 

Re: Orphaned Server processes

[Kirk Lund]

But you can interact with it...

1) You can issue "stop server --dir=server1" which will stop it

2) You can issue "status server --dir=server1" which will show the status
for it

3) You can attach with JConsole and manipulate the MBeans. If the MBeans
have operations to create something you can invoke those. You can even pass
gfsh commands to the server via MemberMXBean#processCommand. Is this ideal?
No, but it's still "interactive" and not "orphaned."

4) Geode has a search pattern to search for cache.xml and if it finds one
it will use it. Perhaps the directly server1/ already exists and contains a
cache.xml. Perhaps you have a cache.xml sitting in your user.home. So even
if you specify the "start server --name=server1" as you state, it may still
find a cache.xml to configure itself. I'm not saying this is better than
using GFSH to configure the server, but it exists today and your proposal
should explain how and why the search pattern for cache.xml is going away
or something like that if you do in fact want this feature to go away.

-Kirk

On Wed, Apr 5, 2017 at 3:18 PM, Udo Kohlmeyer  wrote:

> Once again..
>
> you missing the point... starting a server with "start server
> --name=server1" without a locator or cache.xml or jmx-manager you
> have created a useless server which you cannot interact with We need to
> avoid that...
>
> All the other discussions of how we can start an embedded locator or add
> extra properties to the starting of the server... is just noise...
>
> The problem is... we allow for the creation of a server that cannot be
> accessed other than through a client pool... Which as a matter of fact
> cannot do anything with the server, OTHER than confirming it could connect
> to the server
>
>
>
> On 4/5/17 13:10, Anilkumar Gingade wrote:
>
>> One could create data model using cache.xml or embedded
>> application/api...The server/node could be used as front-end cache for
>> database to handle peek loads (or streamed data)Client application can
>> connect to the server and register interest, execute queries, function
>>
>> -Anil.
>>
>>
>> On Wed, Apr 5, 2017 at 11:03 AM, Udo Kohlmeyer 
>> wrote:
>>
>> @Anil,
>>>
>>> I agree... quick start to evaluate the product... "start server
>>> --name=server1" is the simplest way to start a server... BUT there are no
>>> regions or anything ... So we really only have a GemFire process that
>>> does
>>> not allow you to do anything with it... except connect to it from a
>>> client
>>> and even the client cannot do anything with the server, because it has
>>> not
>>> admin capability.
>>>
>>> --Udo
>>>
>>>
>>> On 4/5/17 10:53, Anilkumar Gingade wrote:
>>>
>>> But does a use case for a server with no locator exist? What about ease

> of development?
> I could see that it would be easier to start just a single server
> process instead of two (locator and server).
>
 Agree with Darrel, for someone who is evaluating the product, it helps
 to
 build quick application and play around, without getting too much into
 the
 cluster setup. Also, it is needed/helpful for use cases where its used
 as
 embedded caching.

 -Anil.


 On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider <
 dschnei...@pivotal.io>
 wrote:

 I like the idea of servers failing to start if no locator exists.

> But does a use case for a server with no locator exist? What about ease
> of
> development?
>
> I could see that it would be easier to start just a single server
> process
> instead of two (locator and server). But for this use case couldn't the
> developer just configure a colocated locator in the same server
> process?
> This would have the benefit of the clients during development and
> production using a locator consistently.
>
> Is it true that the server with no locator will never have any peer
> members
> in its cluster?
> Clients can still connect to this singleton server by being configured
> with
> the server host and port instead of the locator.
>
>
> On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao 
> wrote:
>
> Without connecting to the server, I think you can still stop it by
>
>> specifying --pid or --dir in "stop server" command.
>>
>> On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer > >
>> wrote:
>>
>> Hey there,
>>
>>> Current Geode allows a user to start a server without being linked
>>> to a
>>> Locator. Which in itself is not incorrect, but once started there is
>>> no
>>>
>>> way
>>
>> to connect to that server to manage it.
>>>
>>> I know that we have taken an opinionated view that member discovery
>>> can
>>> only now happen through a locator and that multicast is an option
>>>
>>> 

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #515 was successful.
---
Scheduled
1845 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Re: Orphaned Server processes

[Udo Kohlmeyer]

My apologies,

"you" should not be interpreted as personal.

I'm highlighting that a server can be created without any configuration, 
which allows for an orphan server. A solution should be found for 
that either through failing or starting a means that can correctly 
administer the server.


--Udo


On 4/5/17 15:25, Anilkumar Gingade wrote:

Udo,

I was commenting on the statement:

Current Geode allows a user to start a server without being linked to a

Locator.
Not specifically starting server with gfsh...

-Anil.









On Wed, Apr 5, 2017 at 3:18 PM, Udo Kohlmeyer  wrote:


Once again..

you missing the point... starting a server with "start server
--name=server1" without a locator or cache.xml or jmx-manager you
have created a useless server which you cannot interact with We need to
avoid that...

All the other discussions of how we can start an embedded locator or add
extra properties to the starting of the server... is just noise...

The problem is... we allow for the creation of a server that cannot be
accessed other than through a client pool... Which as a matter of fact
cannot do anything with the server, OTHER than confirming it could connect
to the server


On 4/5/17 13:10, Anilkumar Gingade wrote:


One could create data model using cache.xml or embedded
application/api...The server/node could be used as front-end cache for
database to handle peek loads (or streamed data)Client application can
connect to the server and register interest, execute queries, function

-Anil.


On Wed, Apr 5, 2017 at 11:03 AM, Udo Kohlmeyer 
wrote:

@Anil,

I agree... quick start to evaluate the product... "start server
--name=server1" is the simplest way to start a server... BUT there are no
regions or anything ... So we really only have a GemFire process that
does
not allow you to do anything with it... except connect to it from a
client
and even the client cannot do anything with the server, because it has
not
admin capability.

--Udo


On 4/5/17 10:53, Anilkumar Gingade wrote:

But does a use case for a server with no locator exist? What about ease

of development?
I could see that it would be easier to start just a single server
process instead of two (locator and server).


Agree with Darrel, for someone who is evaluating the product, it helps
to
build quick application and play around, without getting too much into
the
cluster setup. Also, it is needed/helpful for use cases where its used
as
embedded caching.

-Anil.


On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider <
dschnei...@pivotal.io>
wrote:

I like the idea of servers failing to start if no locator exists.


But does a use case for a server with no locator exist? What about ease
of
development?

I could see that it would be easier to start just a single server
process
instead of two (locator and server). But for this use case couldn't the
developer just configure a colocated locator in the same server
process?
This would have the benefit of the clients during development and
production using a locator consistently.

Is it true that the server with no locator will never have any peer
members
in its cluster?
Clients can still connect to this singleton server by being configured
with
the server host and port instead of the locator.


On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao 
wrote:

Without connecting to the server, I think you can still stop it by


specifying --pid or --dir in "stop server" command.

On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer 

[jira] [Resolved] (GEODE-2751) UniversalMembershipListenerAdapterDUnitTest.testSystemClientEventsInServer fails on Jenkins

[Bruce Schuchardt (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruce Schuchardt resolved GEODE-2751.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

> UniversalMembershipListenerAdapterDUnitTest.testSystemClientEventsInServer 
> fails on Jenkins
> ---
>
> Key: GEODE-2751
> URL: https://issues.apache.org/jira/browse/GEODE-2751
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Hitesh Khamesra
> Fix For: 1.2.0
>
>
> Error Message
> org.junit.ComparisonFailure: 
> expected:<[67.195.81.156](15619):32...> but 
> was:<[asf912](15619):32...>
> Stacktrace
> org.junit.ComparisonFailure: 
> expected:<[67.195.81.156](15619):32...> but 
> was:<[asf912](15619):32...>
>   at org.junit.Assert.assertEquals(Assert.java:115)
>   at org.junit.Assert.assertEquals(Assert.java:144)
>   at 
> org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest.doTestSystemClientEventsInServer(UniversalMembershipListenerAdapterDUnitTest.java:946)
>   at 
> org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest.testSystemClientEventsInServer(UniversalMembershipListenerAdapterDUnitTest.java:731)
>   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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.GeneratedMethodAccessor352.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.GeneratedMethodAccessor351.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> 

[jira] [Resolved] (GEODE-2684) org.apache.geode.internal.tcp.Connection & ConnectionTable cleanup

[Bruce Schuchardt (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruce Schuchardt resolved GEODE-2684.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

> org.apache.geode.internal.tcp.Connection & ConnectionTable cleanup
> --
>
> Key: GEODE-2684
> URL: https://issues.apache.org/jira/browse/GEODE-2684
> Project: Geode
>  Issue Type: Task
>  Components: membership
>Reporter: Bruce Schuchardt
> Fix For: 1.2.0
>
>
> These classes contain a lot of commented-out code, poorly named methods and 
> incorrect calculations that need to be cleaned up.  For instance, Connection 
> contains this:
> short aShort = -1;
> bytes[x] = (byte)(aShort & 0xff / 0x100);
> bytes[x+1] = (byte)(aShort & 0xff);
> which is incorrect and results in bytes[x] being zero when the intent is for 
> it to be 255.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2732) after auto-reconnect a server is restarted on the default port of 40404

[Bruce Schuchardt (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruce Schuchardt resolved GEODE-2732.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

> after auto-reconnect a server is restarted on the default port of 40404
> ---
>
> Key: GEODE-2732
> URL: https://issues.apache.org/jira/browse/GEODE-2732
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
> Fix For: 1.2.0
>
>
> If you start a server using gfsh with the server defined in a cache.xml and 
> you specify the server's port Geode will ignore this setting in the event of 
> an auto-reconnect.  I observed this in a GemFire deployment and the code in 
> this area hasn't changed in Apache Geode.  By chance port 40404 was already 
> in use when the auto-reconnect occurred and an exception was thrown.
> {noformat}
> com.gemstone.gemfire.GemFireIOException: While starting bridge server  
> CacheServer on port=40404 client subscription config policy=none client 
> subscription config capacity=1 client subscription config overflow directory=.
>   at 
> com.gemstone.gemfire.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:611)
>   at 
> com.gemstone.gemfire.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:340)
>   at 
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4263)
>   at 
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1178)
>   at 
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.init(GemFireCacheImpl.java:1020)
>   at 
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:684)
>   at 
> com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2909)
>   at 
> com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2655)
>   at 
> com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1058)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionManager$MyListener.membershipFailure(DistributionManager.java:4822)
>   at 
> com.gemstone.gemfire.distributed.internal.membership.jgroup.JGroupMembershipManager.uncleanShutdown(JGroupMembershipManager.java:2733)
>   at 
> com.gemstone.gemfire.distributed.internal.membership.jgroup.JGroupMembershipManager$Puller.channelClosing(JGroupMembershipManager.java:1213)
>   at 
> com.gemstone.org.jgroups.JChannel$CloserThread.run(JChannel.java:1617)
> Caused by: java.net.BindException: Address already in use
>   at sun.nio.ch.Net.bind0(Native Method)
>   at sun.nio.ch.Net.bind(Net.java:463)
>   at sun.nio.ch.Net.bind(Net.java:455)
>   at 
> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
>   at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.AcceptorImpl.(AcceptorImpl.java:432)
>   at 
> com.gemstone.gemfire.internal.cache.BridgeServerImpl.start(BridgeServerImpl.java:342)
>   at 
> com.gemstone.gemfire.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:607)
>   ... 12 more
> {noformat}
> I think the fix is to get rid of the ThreadLocal storage of the port and bind 
> address in CacheServerLauncher.  These variables are used by the XML parser 
> to configure a server.  Gfsh sets them in its thread but they aren't 
> available in the auto-reconnect thread that rebuilds the cache.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2485) CacheTransactionManager suspend/resume can leak memory for 30 minutes

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15957925#comment-15957925
 ] 

Darrel Schneider commented on GEODE-2485:
-

It looks like a simple way to optimize code that suspends and resumes in a 
try/finally it to call internalSuspend instead of suspend. Since the finally 
block will always call resume we can safely use internalSuspend which does not 
schedule expiration with the SystemTimer.

> CacheTransactionManager suspend/resume can leak memory for 30 minutes
> -
>
> Key: GEODE-2485
> URL: https://issues.apache.org/jira/browse/GEODE-2485
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> Each time you suspend/resume a transaction it leaves about 80 bytes of heap 
> allocated for 30 minutes. If you are doing a high rate of suspend/resume 
> calls then this could cause you to run out of memory in that 30 minute window.
> As a workaround you can set -Dgemfire.suspendedTxTimeout to a value as small 
> as 1 (which would cause the memory to be freed up after 1 minute instead of 
> 30 minutes).
> One fix for this is to periodically call cache.getCCPTimer().timerPurge() 
> after a certain number of resume calls have been done (for example 1000). 
> Currently resume is calling cancel on the TimerTask but that leaves the task 
> in the SystemTimer queue until it expires. Calling timerPurge it addition to 
> cancel will fix this bug. Calling timerPurge for every cancel may cause the 
> resume method to take too long and keep in mind the getCCPTimer is used by 
> other things so the size of the SystemTimer queue that is being purged will 
> not only be the number of suspended txs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2684) org.apache.geode.internal.tcp.Connection & ConnectionTable cleanup

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15957921#comment-15957921
 ] 

ASF subversion and git services commented on GEODE-2684:


Commit 6b2b7b2f7f3f63b8ae638e9afffa5edc0f763783 in geode's branch 
refs/heads/develop from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=6b2b7b2 ]

GEODE-2684 Connection & ConnectionTable cleanup

removed dead code and indirect access of TcpConduit through the
connection table.


> org.apache.geode.internal.tcp.Connection & ConnectionTable cleanup
> --
>
> Key: GEODE-2684
> URL: https://issues.apache.org/jira/browse/GEODE-2684
> Project: Geode
>  Issue Type: Task
>  Components: membership
>Reporter: Bruce Schuchardt
>
> These classes contain a lot of commented-out code, poorly named methods and 
> incorrect calculations that need to be cleaned up.  For instance, Connection 
> contains this:
> short aShort = -1;
> bytes[x] = (byte)(aShort & 0xff / 0x100);
> bytes[x+1] = (byte)(aShort & 0xff);
> which is incorrect and results in bytes[x] being zero when the intent is for 
> it to be 255.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2732) after auto-reconnect a server is restarted on the default port of 40404

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15957919#comment-15957919
 ] 

ASF subversion and git services commented on GEODE-2732:


Commit 391502a2615dbc80cde0b9a111fa967f4d76c39a in geode's branch 
refs/heads/develop from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=391502a ]

GEODE-2732 after auto-reconnect a server is restarted on the default port

Gfsh command line parameters were put into ThreadLocals to make them
available to the XML parser.  These are now held in non-thread-local
variables so that all threads, including the auto-reconnect thread,
can see them when building the cache.


> after auto-reconnect a server is restarted on the default port of 40404
> ---
>
> Key: GEODE-2732
> URL: https://issues.apache.org/jira/browse/GEODE-2732
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>
> If you start a server using gfsh with the server defined in a cache.xml and 
> you specify the server's port Geode will ignore this setting in the event of 
> an auto-reconnect.  I observed this in a GemFire deployment and the code in 
> this area hasn't changed in Apache Geode.  By chance port 40404 was already 
> in use when the auto-reconnect occurred and an exception was thrown.
> {noformat}
> com.gemstone.gemfire.GemFireIOException: While starting bridge server  
> CacheServer on port=40404 client subscription config policy=none client 
> subscription config capacity=1 client subscription config overflow directory=.
>   at 
> com.gemstone.gemfire.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:611)
>   at 
> com.gemstone.gemfire.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:340)
>   at 
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4263)
>   at 
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1178)
>   at 
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.init(GemFireCacheImpl.java:1020)
>   at 
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:684)
>   at 
> com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2909)
>   at 
> com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2655)
>   at 
> com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1058)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionManager$MyListener.membershipFailure(DistributionManager.java:4822)
>   at 
> com.gemstone.gemfire.distributed.internal.membership.jgroup.JGroupMembershipManager.uncleanShutdown(JGroupMembershipManager.java:2733)
>   at 
> com.gemstone.gemfire.distributed.internal.membership.jgroup.JGroupMembershipManager$Puller.channelClosing(JGroupMembershipManager.java:1213)
>   at 
> com.gemstone.org.jgroups.JChannel$CloserThread.run(JChannel.java:1617)
> Caused by: java.net.BindException: Address already in use
>   at sun.nio.ch.Net.bind0(Native Method)
>   at sun.nio.ch.Net.bind(Net.java:463)
>   at sun.nio.ch.Net.bind(Net.java:455)
>   at 
> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
>   at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.AcceptorImpl.(AcceptorImpl.java:432)
>   at 
> com.gemstone.gemfire.internal.cache.BridgeServerImpl.start(BridgeServerImpl.java:342)
>   at 
> com.gemstone.gemfire.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:607)
>   ... 12 more
> {noformat}
> I think the fix is to get rid of the ThreadLocal storage of the port and bind 
> address in CacheServerLauncher.  These variables are used by the XML parser 
> to configure a server.  Gfsh sets them in its thread but they aren't 
> available in the auto-reconnect thread that rebuilds the cache.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Orphaned Server processes

[Anilkumar Gingade]

Udo,

I was commenting on the statement:
>> Current Geode allows a user to start a server without being linked to a
Locator.
Not specifically starting server with gfsh...

-Anil.









On Wed, Apr 5, 2017 at 3:18 PM, Udo Kohlmeyer  wrote:

> Once again..
>
> you missing the point... starting a server with "start server
> --name=server1" without a locator or cache.xml or jmx-manager you
> have created a useless server which you cannot interact with We need to
> avoid that...
>
> All the other discussions of how we can start an embedded locator or add
> extra properties to the starting of the server... is just noise...
>
> The problem is... we allow for the creation of a server that cannot be
> accessed other than through a client pool... Which as a matter of fact
> cannot do anything with the server, OTHER than confirming it could connect
> to the server
>
>
> On 4/5/17 13:10, Anilkumar Gingade wrote:
>
>> One could create data model using cache.xml or embedded
>> application/api...The server/node could be used as front-end cache for
>> database to handle peek loads (or streamed data)Client application can
>> connect to the server and register interest, execute queries, function
>>
>> -Anil.
>>
>>
>> On Wed, Apr 5, 2017 at 11:03 AM, Udo Kohlmeyer 
>> wrote:
>>
>> @Anil,
>>>
>>> I agree... quick start to evaluate the product... "start server
>>> --name=server1" is the simplest way to start a server... BUT there are no
>>> regions or anything ... So we really only have a GemFire process that
>>> does
>>> not allow you to do anything with it... except connect to it from a
>>> client
>>> and even the client cannot do anything with the server, because it has
>>> not
>>> admin capability.
>>>
>>> --Udo
>>>
>>>
>>> On 4/5/17 10:53, Anilkumar Gingade wrote:
>>>
>>> But does a use case for a server with no locator exist? What about ease

> of development?
> I could see that it would be easier to start just a single server
> process instead of two (locator and server).
>
 Agree with Darrel, for someone who is evaluating the product, it helps
 to
 build quick application and play around, without getting too much into
 the
 cluster setup. Also, it is needed/helpful for use cases where its used
 as
 embedded caching.

 -Anil.


 On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider <
 dschnei...@pivotal.io>
 wrote:

 I like the idea of servers failing to start if no locator exists.

> But does a use case for a server with no locator exist? What about ease
> of
> development?
>
> I could see that it would be easier to start just a single server
> process
> instead of two (locator and server). But for this use case couldn't the
> developer just configure a colocated locator in the same server
> process?
> This would have the benefit of the clients during development and
> production using a locator consistently.
>
> Is it true that the server with no locator will never have any peer
> members
> in its cluster?
> Clients can still connect to this singleton server by being configured
> with
> the server host and port instead of the locator.
>
>
> On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao 
> wrote:
>
> Without connecting to the server, I think you can still stop it by
>
>> specifying --pid or --dir in "stop server" command.
>>
>> On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer > >
>> wrote:
>>
>> Hey there,
>>
>>> Current Geode allows a user to start a server without being linked
>>> to a
>>> Locator. Which in itself is not incorrect, but once started there is
>>> no
>>>
>>> way
>>
>> to connect to that server to manage it.
>>>
>>> I know that we have taken an opinionated view that member discovery
>>> can
>>> only now happen through a locator and that multicast is an option
>>>
>>> anymore.
>>
>> Can we take the same opinionated view where we either state that
>>> unless
>>> your server is connecting to a locator, it cannot be started OR we
>>> fix
>>>
>>> the
>>
>> default behavior where we can start a server but cannot connect to it,
>>>
>>> and
>>
>> have to resort to "kill -9" commands to kill the server.
>>>
>>> --Udo
>>>
>>>
>>>
>>> --
>> Cheers
>>
>> Jinmei
>>
>>
>>
>

Review Request 58225: GEODE-2757: netsearch has a race that may return null object incorrectly

[Eric Shu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58225/
---

Review request for geode, anilkumar gingade and Darrel Schneider.


Bugs: GEODE-2757
https://issues.apache.org/jira/browse/GEODE-2757


Repository: geode


Description
---

Do not process netsearch reply from a departed node that membership listener 
already detected.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/internal/cache/DistributedRegion.java 
fa02574 
  
geode-core/src/main/java/org/apache/geode/internal/cache/SearchLoadAndWriteProcessor.java
 3d969f9 
  
geode-core/src/test/java/org/apache/geode/internal/cache/SearchLoadAndWriteProcessorTest.java
 bfe78b0 


Diff: https://reviews.apache.org/r/58225/diff/1/


Testing
---

precheckin.


Thanks,

Eric Shu

Re: Orphaned Server processes

[Swapnil Bawaskar]

+1 to add a "--start-locator=" option for starting an embedded locator.
However, I can easily see a user starting two servers and expecting to form
a distributed system, but if we start the embedded locator by default, they
won't.
So, I think we should prevent the server from starting up, but give an
error message to either start a locator or use the --start-locator option.

On Wed, Apr 5, 2017 at 2:50 PM Kirk Lund  wrote:

> You can still control a lone server with GFSH. And if you configure it up
> front, then you can still have Regions for a Client to use.
>
> $ start server --name=server1 --cache-xml-file=mycachefile.xml
>
> 
>
> $ stop server --dir=server1
>
> You could also start a JMX Manager in the server or an embedded Locator as
> others have mentioned. I'm not sure if it's possible to startup cluster
> config service in a server or if that comes for free when you start an
> embedded Locator.
>
> -Kirk
>
> On Wed, Apr 5, 2017 at 12:26 PM, Jianxia Chen  wrote:
>
> > Thanks Jinmei! You are right. I missed that.
> >
> > Thanks,
> > Jianxia
> >
> > On Wed, Apr 5, 2017 at 12:24 PM, Jinmei Liao  wrote:
> >
> > > for your #1, there is a --properties-file option when you do "start
> > > server".
> > >
> > > On Wed, Apr 5, 2017 at 12:20 PM, Jianxia Chen 
> wrote:
> > >
> > > > Thank you William!
> > > >
> > > > I tried with it. It works. But there is something tricky in order to
> > > start
> > > > the embedded locator.
> > > >
> > > > 1) the gemfire.properties file has to be in the right place, either
> in
> > > the
> > > > server directory or home directory. Looks like this is not
> documented.
> > > > I was trying to specify the properties file in gfsh when starting
> > server.
> > > > However, there is no such option for `start server` command. There is
> > an
> > > > `--security-properties-file` option though, for
> gfsecurity.properties.
> > > >
> > > > 2) jmx-manager has to be true. Otherwise the embedded locator won't
> > > start.
> > > > The server can be started successfully though.
> > > >
> > > > Thanks,
> > > > Jianxia
> > > >
> > > > On Wed, Apr 5, 2017 at 11:03 AM, William Markito Oliveira <
> > > > william.mark...@gmail.com> wrote:
> > > >
> > > > > Jianxia, you can set the property "start-locator" in
> > gemfire.properties
> > > > as
> > > > > below...  So the server then will have an embedded locator.
> > > > >
> > > > > http://geode.apache.org/docs/guide/11/reference/topics/
> > > > > gemfire_properties.html
> > > > > start-locator If set, automatically starts a locator in the current
> > > > process
> > > > > when the member connects to the distributed system and stops the
> > > locator
> > > > > when the member disconnects.
> > > > >
> > > > > To use, specify the locator with an optional address or host
> > > > specification
> > > > > and a required port number, in one of these formats:
> > > > >
> > > > > start-locator=address[port1]
> > > > >
> > > > > start-locator=port1
> > > > >
> > > > > If you only specify the port, the address assigned to the member is
> > > used
> > > > > for the locator.
> > > > >
> > > > > If not already there, this locator is automatically added to the
> list
> > > of
> > > > > locators in this set of gemfire properties.
> > > > > *not set*
> > > > >
> > > > > On Wed, Apr 5, 2017 at 12:50 PM, Jianxia Chen 
> > > wrote:
> > > > >
> > > > > > Hi Darrel,
> > > > > >
> > > > > > How to configure a colocated locator in the same server process?
> > Just
> > > > > > curious. What I understand is that the locator is in its own
> > process.
> > > > > >
> > > > > > Thanks,
> > > > > > Jianxia
> > > > > >
> > > > > > On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider <
> > > > dschnei...@pivotal.io
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > I like the idea of servers failing to start if no locator
> exists.
> > > > > > > But does a use case for a server with no locator exist? What
> > about
> > > > ease
> > > > > > of
> > > > > > > development?
> > > > > > >
> > > > > > > I could see that it would be easier to start just a single
> server
> > > > > process
> > > > > > > instead of two (locator and server). But for this use case
> > couldn't
> > > > the
> > > > > > > developer just configure a colocated locator in the same server
> > > > > process?
> > > > > > > This would have the benefit of the clients during development
> and
> > > > > > > production using a locator consistently.
> > > > > > >
> > > > > > > Is it true that the server with no locator will never have any
> > peer
> > > > > > members
> > > > > > > in its cluster?
> > > > > > > Clients can still connect to this singleton server by being
> > > > configured
> > > > > > with
> > > > > > > the server host and port instead of the locator.
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao <
> jil...@pivotal.io>
> > > > > wrote:
> > > > > > >
> > > > > > > > Without 

Re: Orphaned Server processes

[Udo Kohlmeyer]

Once again..

you missing the point... starting a server with "start server 
--name=server1" without a locator or cache.xml or jmx-manager 
you have created a useless server which you cannot interact with We 
need to avoid that...


All the other discussions of how we can start an embedded locator or add 
extra properties to the starting of the server... is just noise...


The problem is... we allow for the creation of a server that cannot be 
accessed other than through a client pool... Which as a matter of fact 
cannot do anything with the server, OTHER than confirming it could 
connect to the server



On 4/5/17 13:10, Anilkumar Gingade wrote:

One could create data model using cache.xml or embedded
application/api...The server/node could be used as front-end cache for
database to handle peek loads (or streamed data)Client application can
connect to the server and register interest, execute queries, function

-Anil.


On Wed, Apr 5, 2017 at 11:03 AM, Udo Kohlmeyer 
wrote:


@Anil,

I agree... quick start to evaluate the product... "start server
--name=server1" is the simplest way to start a server... BUT there are no
regions or anything ... So we really only have a GemFire process that does
not allow you to do anything with it... except connect to it from a client
and even the client cannot do anything with the server, because it has not
admin capability.

--Udo


On 4/5/17 10:53, Anilkumar Gingade wrote:


But does a use case for a server with no locator exist? What about ease

of development?
I could see that it would be easier to start just a single server
process instead of two (locator and server).

Agree with Darrel, for someone who is evaluating the product, it helps to
build quick application and play around, without getting too much into the
cluster setup. Also, it is needed/helpful for use cases where its used as
embedded caching.

-Anil.


On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider 
wrote:

I like the idea of servers failing to start if no locator exists.

But does a use case for a server with no locator exist? What about ease
of
development?

I could see that it would be easier to start just a single server process
instead of two (locator and server). But for this use case couldn't the
developer just configure a colocated locator in the same server process?
This would have the benefit of the clients during development and
production using a locator consistently.

Is it true that the server with no locator will never have any peer
members
in its cluster?
Clients can still connect to this singleton server by being configured
with
the server host and port instead of the locator.


On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao  wrote:

Without connecting to the server, I think you can still stop it by

specifying --pid or --dir in "stop server" command.

On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer 
wrote:

Hey there,

Current Geode allows a user to start a server without being linked to a
Locator. Which in itself is not incorrect, but once started there is no


way


to connect to that server to manage it.

I know that we have taken an opinionated view that member discovery can
only now happen through a locator and that multicast is an option


anymore.


Can we take the same opinionated view where we either state that unless
your server is connecting to a locator, it cannot be started OR we fix


the


default behavior where we can start a server but cannot connect to it,


and


have to resort to "kill -9" commands to kill the server.

--Udo




--
Cheers

Jinmei

[jira] [Assigned] (GEODE-2485) CacheTransactionManager suspend/resume can leak memory for 30 minutes

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider reassigned GEODE-2485:
---

Assignee: Darrel Schneider

> CacheTransactionManager suspend/resume can leak memory for 30 minutes
> -
>
> Key: GEODE-2485
> URL: https://issues.apache.org/jira/browse/GEODE-2485
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> Each time you suspend/resume a transaction it leaves about 80 bytes of heap 
> allocated for 30 minutes. If you are doing a high rate of suspend/resume 
> calls then this could cause you to run out of memory in that 30 minute window.
> As a workaround you can set -Dgemfire.suspendedTxTimeout to a value as small 
> as 1 (which would cause the memory to be freed up after 1 minute instead of 
> 30 minutes).
> One fix for this is to periodically call cache.getCCPTimer().timerPurge() 
> after a certain number of resume calls have been done (for example 1000). 
> Currently resume is calling cancel on the TimerTask but that leaves the task 
> in the SystemTimer queue until it expires. Calling timerPurge it addition to 
> cancel will fix this bug. Calling timerPurge for every cancel may cause the 
> resume method to take too long and keep in mind the getCCPTimer is used by 
> other things so the size of the SystemTimer queue that is being purged will 
> not only be the number of suspended txs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2757) Netsearch may return a null object when there are other replicates available in the cluster

[Eric Shu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Shu reassigned GEODE-2757:
---

Assignee: Eric Shu

> Netsearch may return a null object when there are other replicates available 
> in the cluster
> ---
>
> Key: GEODE-2757
> URL: https://issues.apache.org/jira/browse/GEODE-2757
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Eric Shu
>Assignee: Eric Shu
>
> There is a race that netsearch in SearchLoadAndWriteProcessor. Multiple 
> threads are processing netsearch replies if a member departed event woke up 
> the reply waiting thread.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2757) Netsearch may return a null object when there are other replicates available in the cluster

[Eric Shu (JIRA)]

Eric Shu created GEODE-2757:
---

 Summary: Netsearch may return a null object when there are other 
replicates available in the cluster
 Key: GEODE-2757
 URL: https://issues.apache.org/jira/browse/GEODE-2757
 Project: Geode
  Issue Type: Bug
  Components: regions
Reporter: Eric Shu


There is a race that netsearch in SearchLoadAndWriteProcessor. Multiple threads 
are processing netsearch replies if a member departed event woke up the reply 
waiting thread.





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Orphaned Server processes

[Kirk Lund]

You can still control a lone server with GFSH. And if you configure it up
front, then you can still have Regions for a Client to use.

$ start server --name=server1 --cache-xml-file=mycachefile.xml



$ stop server --dir=server1

You could also start a JMX Manager in the server or an embedded Locator as
others have mentioned. I'm not sure if it's possible to startup cluster
config service in a server or if that comes for free when you start an
embedded Locator.

-Kirk

On Wed, Apr 5, 2017 at 12:26 PM, Jianxia Chen  wrote:

> Thanks Jinmei! You are right. I missed that.
>
> Thanks,
> Jianxia
>
> On Wed, Apr 5, 2017 at 12:24 PM, Jinmei Liao  wrote:
>
> > for your #1, there is a --properties-file option when you do "start
> > server".
> >
> > On Wed, Apr 5, 2017 at 12:20 PM, Jianxia Chen  wrote:
> >
> > > Thank you William!
> > >
> > > I tried with it. It works. But there is something tricky in order to
> > start
> > > the embedded locator.
> > >
> > > 1) the gemfire.properties file has to be in the right place, either in
> > the
> > > server directory or home directory. Looks like this is not documented.
> > > I was trying to specify the properties file in gfsh when starting
> server.
> > > However, there is no such option for `start server` command. There is
> an
> > > `--security-properties-file` option though, for gfsecurity.properties.
> > >
> > > 2) jmx-manager has to be true. Otherwise the embedded locator won't
> > start.
> > > The server can be started successfully though.
> > >
> > > Thanks,
> > > Jianxia
> > >
> > > On Wed, Apr 5, 2017 at 11:03 AM, William Markito Oliveira <
> > > william.mark...@gmail.com> wrote:
> > >
> > > > Jianxia, you can set the property "start-locator" in
> gemfire.properties
> > > as
> > > > below...  So the server then will have an embedded locator.
> > > >
> > > > http://geode.apache.org/docs/guide/11/reference/topics/
> > > > gemfire_properties.html
> > > > start-locator If set, automatically starts a locator in the current
> > > process
> > > > when the member connects to the distributed system and stops the
> > locator
> > > > when the member disconnects.
> > > >
> > > > To use, specify the locator with an optional address or host
> > > specification
> > > > and a required port number, in one of these formats:
> > > >
> > > > start-locator=address[port1]
> > > >
> > > > start-locator=port1
> > > >
> > > > If you only specify the port, the address assigned to the member is
> > used
> > > > for the locator.
> > > >
> > > > If not already there, this locator is automatically added to the list
> > of
> > > > locators in this set of gemfire properties.
> > > > *not set*
> > > >
> > > > On Wed, Apr 5, 2017 at 12:50 PM, Jianxia Chen 
> > wrote:
> > > >
> > > > > Hi Darrel,
> > > > >
> > > > > How to configure a colocated locator in the same server process?
> Just
> > > > > curious. What I understand is that the locator is in its own
> process.
> > > > >
> > > > > Thanks,
> > > > > Jianxia
> > > > >
> > > > > On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider <
> > > dschnei...@pivotal.io
> > > > >
> > > > > wrote:
> > > > >
> > > > > > I like the idea of servers failing to start if no locator exists.
> > > > > > But does a use case for a server with no locator exist? What
> about
> > > ease
> > > > > of
> > > > > > development?
> > > > > >
> > > > > > I could see that it would be easier to start just a single server
> > > > process
> > > > > > instead of two (locator and server). But for this use case
> couldn't
> > > the
> > > > > > developer just configure a colocated locator in the same server
> > > > process?
> > > > > > This would have the benefit of the clients during development and
> > > > > > production using a locator consistently.
> > > > > >
> > > > > > Is it true that the server with no locator will never have any
> peer
> > > > > members
> > > > > > in its cluster?
> > > > > > Clients can still connect to this singleton server by being
> > > configured
> > > > > with
> > > > > > the server host and port instead of the locator.
> > > > > >
> > > > > >
> > > > > > On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao 
> > > > wrote:
> > > > > >
> > > > > > > Without connecting to the server, I think you can still stop it
> > by
> > > > > > > specifying --pid or --dir in "stop server" command.
> > > > > > >
> > > > > > > On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer <
> > > > ukohlme...@pivotal.io>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hey there,
> > > > > > > >
> > > > > > > > Current Geode allows a user to start a server without being
> > > linked
> > > > > to a
> > > > > > > > Locator. Which in itself is not incorrect, but once started
> > there
> > > > is
> > > > > no
> > > > > > > way
> > > > > > > > to connect to that server to manage it.
> > > > > > > >
> > > > > > > > I know that we have taken an opinionated view that member
> > > discovery
> > > > > can
> > > 

[jira] [Commented] (GEODE-2716) export logs should honor the log level set on the server

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15957605#comment-15957605
 ] 

ASF GitHub Bot commented on GEODE-2716:
---

GitHub user PurelyApplied opened a pull request:

https://github.com/apache/geode/pull/439

GEODE-2716: export logs default behavior changed from filtering at log 
level INFO to ALL.

Moved location of export default log level constant from LogService to 
ExportLogCommand.
Updated associated help strings.

Tests ran clean previously, new set running after latest merge to develop.  
Trivial merge conflicts expect these tests to return green as well.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/PurelyApplied/geode bugfix/GEODE-2716

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/439.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #439


commit c9a1b60ba9e97c22f3299b5d78e6ec782a422d7b
Author: Patrick Rhomberg 
Date:   2017-03-28T22:12:02Z

GEODE-2716: export logs default behavior changed from filtering at log 
level INFO to ALL.

Removed reliance on LogService.DEFAULT_LOG_LEVEL, added 
ExportLogCommand.DEFAULT_EXPORT_LOG_LEVEL.
Added DUnit test that fails under previous behavior.

commit 5de335d0640b263b1ac3e336ea9876b86aa3f07c
Author: Patrick Rhomberg 
Date:   2017-04-05T20:20:16Z

Merge branch 'develop' into bugfix/GEODE-2716




> export logs should honor the log level set on the server
> 
>
> Key: GEODE-2716
> URL: https://issues.apache.org/jira/browse/GEODE-2716
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Swapnil Bawaskar
>Assignee: Patrick Rhomberg
>
> When no log level is specified, {{export logs}} gets only the info level 
> logs. This is confusing; export logs should get the entire log file from the 
> server when log level is not specified.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #439: GEODE-2716: export logs default behavior changed fr...

[PurelyApplied]

GitHub user PurelyApplied opened a pull request:

https://github.com/apache/geode/pull/439

GEODE-2716: export logs default behavior changed from filtering at log 
level INFO to ALL.

Moved location of export default log level constant from LogService to 
ExportLogCommand.
Updated associated help strings.

Tests ran clean previously, new set running after latest merge to develop.  
Trivial merge conflicts expect these tests to return green as well.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/PurelyApplied/geode bugfix/GEODE-2716

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/439.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #439


commit c9a1b60ba9e97c22f3299b5d78e6ec782a422d7b
Author: Patrick Rhomberg 
Date:   2017-03-28T22:12:02Z

GEODE-2716: export logs default behavior changed from filtering at log 
level INFO to ALL.

Removed reliance on LogService.DEFAULT_LOG_LEVEL, added 
ExportLogCommand.DEFAULT_EXPORT_LOG_LEVEL.
Added DUnit test that fails under previous behavior.

commit 5de335d0640b263b1ac3e336ea9876b86aa3f07c
Author: Patrick Rhomberg 
Date:   2017-04-05T20:20:16Z

Merge branch 'develop' into bugfix/GEODE-2716




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Orphaned Server processes

[Anilkumar Gingade]

One could create data model using cache.xml or embedded
application/api...The server/node could be used as front-end cache for
database to handle peek loads (or streamed data)Client application can
connect to the server and register interest, execute queries, function

-Anil.


On Wed, Apr 5, 2017 at 11:03 AM, Udo Kohlmeyer 
wrote:

> @Anil,
>
> I agree... quick start to evaluate the product... "start server
> --name=server1" is the simplest way to start a server... BUT there are no
> regions or anything ... So we really only have a GemFire process that does
> not allow you to do anything with it... except connect to it from a client
> and even the client cannot do anything with the server, because it has not
> admin capability.
>
> --Udo
>
>
> On 4/5/17 10:53, Anilkumar Gingade wrote:
>
>> But does a use case for a server with no locator exist? What about ease

>>> of development?
>>
>>> I could see that it would be easier to start just a single server

>>> process instead of two (locator and server).
>>
>> Agree with Darrel, for someone who is evaluating the product, it helps to
>> build quick application and play around, without getting too much into the
>> cluster setup. Also, it is needed/helpful for use cases where its used as
>> embedded caching.
>>
>> -Anil.
>>
>>
>> On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider 
>> wrote:
>>
>> I like the idea of servers failing to start if no locator exists.
>>> But does a use case for a server with no locator exist? What about ease
>>> of
>>> development?
>>>
>>> I could see that it would be easier to start just a single server process
>>> instead of two (locator and server). But for this use case couldn't the
>>> developer just configure a colocated locator in the same server process?
>>> This would have the benefit of the clients during development and
>>> production using a locator consistently.
>>>
>>> Is it true that the server with no locator will never have any peer
>>> members
>>> in its cluster?
>>> Clients can still connect to this singleton server by being configured
>>> with
>>> the server host and port instead of the locator.
>>>
>>>
>>> On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao  wrote:
>>>
>>> Without connecting to the server, I think you can still stop it by
 specifying --pid or --dir in "stop server" command.

 On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer 
 wrote:

 Hey there,
>
> Current Geode allows a user to start a server without being linked to a
> Locator. Which in itself is not incorrect, but once started there is no
>
 way

> to connect to that server to manage it.
>
> I know that we have taken an opinionated view that member discovery can
> only now happen through a locator and that multicast is an option
>
 anymore.

> Can we take the same opinionated view where we either state that unless
> your server is connecting to a locator, it cannot be started OR we fix
>
 the

> default behavior where we can start a server but cannot connect to it,
>
 and

> have to resort to "kill -9" commands to kill the server.
>
> --Udo
>
>
>
 --
 Cheers

 Jinmei


>

[jira] [Commented] (GEODE-2749) git and rat should ignore out/ and bin/ directories created by IDEs

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15957526#comment-15957526
 ] 

ASF subversion and git services commented on GEODE-2749:


Commit 39c72b2046fcb3ed5c0cec280d52f9fdf6aaa794 in geode's branch 
refs/heads/develop from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=39c72b2 ]

GEODE-2749: don't ignore bin/ because we have bin/ in src


> git and rat should ignore out/ and bin/ directories created by IDEs
> ---
>
> Key: GEODE-2749
> URL: https://issues.apache.org/jira/browse/GEODE-2749
> Project: Geode
>  Issue Type: Wish
>  Components: build
>Reporter: Kirk Lund
>Assignee: Kirk Lund
> Fix For: 1.2.0
>
>
> Eclipse and IntelliJ default to creating out/ and bin/ directories. I'd like 
> to configure git and rat to ignore these directories.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2756) export logs integration with security

[Swapnil Bawaskar (JIRA)]

Swapnil Bawaskar created GEODE-2756:
---

 Summary: export logs integration with security
 Key: GEODE-2756
 URL: https://issues.apache.org/jira/browse/GEODE-2756
 Project: Geode
  Issue Type: Sub-task
  Components: logging
Reporter: Swapnil Bawaskar


We need to make sure that a user is able to export logs when a 
{{security-manager}} has been configured.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2755) Solaris images need Oracle support certificate/key

[Jacob S. Barrett (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacob S. Barrett resolved GEODE-2755.
-
Resolution: Fixed

> Solaris images need Oracle support certificate/key
> --
>
> Key: GEODE-2755
> URL: https://issues.apache.org/jira/browse/GEODE-2755
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>
> Solaris images need Oracle support certificate/key to download Solaris 
> Studio. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Orphaned Server processes

[Jianxia Chen]

Thanks Jinmei! You are right. I missed that.

Thanks,
Jianxia

On Wed, Apr 5, 2017 at 12:24 PM, Jinmei Liao  wrote:

> for your #1, there is a --properties-file option when you do "start
> server".
>
> On Wed, Apr 5, 2017 at 12:20 PM, Jianxia Chen  wrote:
>
> > Thank you William!
> >
> > I tried with it. It works. But there is something tricky in order to
> start
> > the embedded locator.
> >
> > 1) the gemfire.properties file has to be in the right place, either in
> the
> > server directory or home directory. Looks like this is not documented.
> > I was trying to specify the properties file in gfsh when starting server.
> > However, there is no such option for `start server` command. There is an
> > `--security-properties-file` option though, for gfsecurity.properties.
> >
> > 2) jmx-manager has to be true. Otherwise the embedded locator won't
> start.
> > The server can be started successfully though.
> >
> > Thanks,
> > Jianxia
> >
> > On Wed, Apr 5, 2017 at 11:03 AM, William Markito Oliveira <
> > william.mark...@gmail.com> wrote:
> >
> > > Jianxia, you can set the property "start-locator" in gemfire.properties
> > as
> > > below...  So the server then will have an embedded locator.
> > >
> > > http://geode.apache.org/docs/guide/11/reference/topics/
> > > gemfire_properties.html
> > > start-locator If set, automatically starts a locator in the current
> > process
> > > when the member connects to the distributed system and stops the
> locator
> > > when the member disconnects.
> > >
> > > To use, specify the locator with an optional address or host
> > specification
> > > and a required port number, in one of these formats:
> > >
> > > start-locator=address[port1]
> > >
> > > start-locator=port1
> > >
> > > If you only specify the port, the address assigned to the member is
> used
> > > for the locator.
> > >
> > > If not already there, this locator is automatically added to the list
> of
> > > locators in this set of gemfire properties.
> > > *not set*
> > >
> > > On Wed, Apr 5, 2017 at 12:50 PM, Jianxia Chen 
> wrote:
> > >
> > > > Hi Darrel,
> > > >
> > > > How to configure a colocated locator in the same server process? Just
> > > > curious. What I understand is that the locator is in its own process.
> > > >
> > > > Thanks,
> > > > Jianxia
> > > >
> > > > On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider <
> > dschnei...@pivotal.io
> > > >
> > > > wrote:
> > > >
> > > > > I like the idea of servers failing to start if no locator exists.
> > > > > But does a use case for a server with no locator exist? What about
> > ease
> > > > of
> > > > > development?
> > > > >
> > > > > I could see that it would be easier to start just a single server
> > > process
> > > > > instead of two (locator and server). But for this use case couldn't
> > the
> > > > > developer just configure a colocated locator in the same server
> > > process?
> > > > > This would have the benefit of the clients during development and
> > > > > production using a locator consistently.
> > > > >
> > > > > Is it true that the server with no locator will never have any peer
> > > > members
> > > > > in its cluster?
> > > > > Clients can still connect to this singleton server by being
> > configured
> > > > with
> > > > > the server host and port instead of the locator.
> > > > >
> > > > >
> > > > > On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao 
> > > wrote:
> > > > >
> > > > > > Without connecting to the server, I think you can still stop it
> by
> > > > > > specifying --pid or --dir in "stop server" command.
> > > > > >
> > > > > > On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer <
> > > ukohlme...@pivotal.io>
> > > > > > wrote:
> > > > > >
> > > > > > > Hey there,
> > > > > > >
> > > > > > > Current Geode allows a user to start a server without being
> > linked
> > > > to a
> > > > > > > Locator. Which in itself is not incorrect, but once started
> there
> > > is
> > > > no
> > > > > > way
> > > > > > > to connect to that server to manage it.
> > > > > > >
> > > > > > > I know that we have taken an opinionated view that member
> > discovery
> > > > can
> > > > > > > only now happen through a locator and that multicast is an
> option
> > > > > > anymore.
> > > > > > >
> > > > > > > Can we take the same opinionated view where we either state
> that
> > > > unless
> > > > > > > your server is connecting to a locator, it cannot be started OR
> > we
> > > > fix
> > > > > > the
> > > > > > > default behavior where we can start a server but cannot connect
> > to
> > > > it,
> > > > > > and
> > > > > > > have to resort to "kill -9" commands to kill the server.
> > > > > > >
> > > > > > > --Udo
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Cheers
> > > > > >
> > > > > > Jinmei
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > ~/William
> > >
> >
>
>
>
> --
> Cheers
>
> Jinmei
>

Re: Orphaned Server processes

[Jinmei Liao]

for your #1, there is a --properties-file option when you do "start server".

On Wed, Apr 5, 2017 at 12:20 PM, Jianxia Chen  wrote:

> Thank you William!
>
> I tried with it. It works. But there is something tricky in order to start
> the embedded locator.
>
> 1) the gemfire.properties file has to be in the right place, either in the
> server directory or home directory. Looks like this is not documented.
> I was trying to specify the properties file in gfsh when starting server.
> However, there is no such option for `start server` command. There is an
> `--security-properties-file` option though, for gfsecurity.properties.
>
> 2) jmx-manager has to be true. Otherwise the embedded locator won't start.
> The server can be started successfully though.
>
> Thanks,
> Jianxia
>
> On Wed, Apr 5, 2017 at 11:03 AM, William Markito Oliveira <
> william.mark...@gmail.com> wrote:
>
> > Jianxia, you can set the property "start-locator" in gemfire.properties
> as
> > below...  So the server then will have an embedded locator.
> >
> > http://geode.apache.org/docs/guide/11/reference/topics/
> > gemfire_properties.html
> > start-locator If set, automatically starts a locator in the current
> process
> > when the member connects to the distributed system and stops the locator
> > when the member disconnects.
> >
> > To use, specify the locator with an optional address or host
> specification
> > and a required port number, in one of these formats:
> >
> > start-locator=address[port1]
> >
> > start-locator=port1
> >
> > If you only specify the port, the address assigned to the member is used
> > for the locator.
> >
> > If not already there, this locator is automatically added to the list of
> > locators in this set of gemfire properties.
> > *not set*
> >
> > On Wed, Apr 5, 2017 at 12:50 PM, Jianxia Chen  wrote:
> >
> > > Hi Darrel,
> > >
> > > How to configure a colocated locator in the same server process? Just
> > > curious. What I understand is that the locator is in its own process.
> > >
> > > Thanks,
> > > Jianxia
> > >
> > > On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider <
> dschnei...@pivotal.io
> > >
> > > wrote:
> > >
> > > > I like the idea of servers failing to start if no locator exists.
> > > > But does a use case for a server with no locator exist? What about
> ease
> > > of
> > > > development?
> > > >
> > > > I could see that it would be easier to start just a single server
> > process
> > > > instead of two (locator and server). But for this use case couldn't
> the
> > > > developer just configure a colocated locator in the same server
> > process?
> > > > This would have the benefit of the clients during development and
> > > > production using a locator consistently.
> > > >
> > > > Is it true that the server with no locator will never have any peer
> > > members
> > > > in its cluster?
> > > > Clients can still connect to this singleton server by being
> configured
> > > with
> > > > the server host and port instead of the locator.
> > > >
> > > >
> > > > On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao 
> > wrote:
> > > >
> > > > > Without connecting to the server, I think you can still stop it by
> > > > > specifying --pid or --dir in "stop server" command.
> > > > >
> > > > > On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer <
> > ukohlme...@pivotal.io>
> > > > > wrote:
> > > > >
> > > > > > Hey there,
> > > > > >
> > > > > > Current Geode allows a user to start a server without being
> linked
> > > to a
> > > > > > Locator. Which in itself is not incorrect, but once started there
> > is
> > > no
> > > > > way
> > > > > > to connect to that server to manage it.
> > > > > >
> > > > > > I know that we have taken an opinionated view that member
> discovery
> > > can
> > > > > > only now happen through a locator and that multicast is an option
> > > > > anymore.
> > > > > >
> > > > > > Can we take the same opinionated view where we either state that
> > > unless
> > > > > > your server is connecting to a locator, it cannot be started OR
> we
> > > fix
> > > > > the
> > > > > > default behavior where we can start a server but cannot connect
> to
> > > it,
> > > > > and
> > > > > > have to resort to "kill -9" commands to kill the server.
> > > > > >
> > > > > > --Udo
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Cheers
> > > > >
> > > > > Jinmei
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > ~/William
> >
>



-- 
Cheers

Jinmei

[jira] [Commented] (GEODE-2755) Solaris images need Oracle support certificate/key

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15957485#comment-15957485
 ] 

ASF subversion and git services commented on GEODE-2755:


Commit 67e50b7598ff8678cc1eba93f4280ee5882fd4d5 in geode-native's branch 
refs/heads/develop from Jacob Barrett
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=67e50b7 ]

GEODE-2755: Parameterize path to Oracle Support cert/key.


> Solaris images need Oracle support certificate/key
> --
>
> Key: GEODE-2755
> URL: https://issues.apache.org/jira/browse/GEODE-2755
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>
> Solaris images need Oracle support certificate/key to download Solaris 
> Studio. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Orphaned Server processes

[Jianxia Chen]

Thank you William!

I tried with it. It works. But there is something tricky in order to start
the embedded locator.

1) the gemfire.properties file has to be in the right place, either in the
server directory or home directory. Looks like this is not documented.
I was trying to specify the properties file in gfsh when starting server.
However, there is no such option for `start server` command. There is an
`--security-properties-file` option though, for gfsecurity.properties.

2) jmx-manager has to be true. Otherwise the embedded locator won't start.
The server can be started successfully though.

Thanks,
Jianxia

On Wed, Apr 5, 2017 at 11:03 AM, William Markito Oliveira <
william.mark...@gmail.com> wrote:

> Jianxia, you can set the property "start-locator" in gemfire.properties as
> below...  So the server then will have an embedded locator.
>
> http://geode.apache.org/docs/guide/11/reference/topics/
> gemfire_properties.html
> start-locator If set, automatically starts a locator in the current process
> when the member connects to the distributed system and stops the locator
> when the member disconnects.
>
> To use, specify the locator with an optional address or host specification
> and a required port number, in one of these formats:
>
> start-locator=address[port1]
>
> start-locator=port1
>
> If you only specify the port, the address assigned to the member is used
> for the locator.
>
> If not already there, this locator is automatically added to the list of
> locators in this set of gemfire properties.
> *not set*
>
> On Wed, Apr 5, 2017 at 12:50 PM, Jianxia Chen  wrote:
>
> > Hi Darrel,
> >
> > How to configure a colocated locator in the same server process? Just
> > curious. What I understand is that the locator is in its own process.
> >
> > Thanks,
> > Jianxia
> >
> > On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider  >
> > wrote:
> >
> > > I like the idea of servers failing to start if no locator exists.
> > > But does a use case for a server with no locator exist? What about ease
> > of
> > > development?
> > >
> > > I could see that it would be easier to start just a single server
> process
> > > instead of two (locator and server). But for this use case couldn't the
> > > developer just configure a colocated locator in the same server
> process?
> > > This would have the benefit of the clients during development and
> > > production using a locator consistently.
> > >
> > > Is it true that the server with no locator will never have any peer
> > members
> > > in its cluster?
> > > Clients can still connect to this singleton server by being configured
> > with
> > > the server host and port instead of the locator.
> > >
> > >
> > > On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao 
> wrote:
> > >
> > > > Without connecting to the server, I think you can still stop it by
> > > > specifying --pid or --dir in "stop server" command.
> > > >
> > > > On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer <
> ukohlme...@pivotal.io>
> > > > wrote:
> > > >
> > > > > Hey there,
> > > > >
> > > > > Current Geode allows a user to start a server without being linked
> > to a
> > > > > Locator. Which in itself is not incorrect, but once started there
> is
> > no
> > > > way
> > > > > to connect to that server to manage it.
> > > > >
> > > > > I know that we have taken an opinionated view that member discovery
> > can
> > > > > only now happen through a locator and that multicast is an option
> > > > anymore.
> > > > >
> > > > > Can we take the same opinionated view where we either state that
> > unless
> > > > > your server is connecting to a locator, it cannot be started OR we
> > fix
> > > > the
> > > > > default behavior where we can start a server but cannot connect to
> > it,
> > > > and
> > > > > have to resort to "kill -9" commands to kill the server.
> > > > >
> > > > > --Udo
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Cheers
> > > >
> > > > Jinmei
> > > >
> > >
> >
>
>
>
> --
> ~/William
>

[jira] [Created] (GEODE-2755) Solaris images need Oracle support certificate/key

[Jacob S. Barrett (JIRA)]

Jacob S. Barrett created GEODE-2755:
---

 Summary: Solaris images need Oracle support certificate/key
 Key: GEODE-2755
 URL: https://issues.apache.org/jira/browse/GEODE-2755
 Project: Geode
  Issue Type: Task
  Components: native client
Reporter: Jacob S. Barrett


Solaris images need Oracle support certificate/key to download Solaris Studio. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Orphaned Server processes

[Udo Kohlmeyer]

That could be another option that could be pursued...


On 4/5/17 12:05, Michael Stolz wrote:

Actually, the server KNOWS it is all by itself, and since that puts into an
unusable state, why not just default to starting an embedded locator on the
default port? Instant single-node GemFire.

--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: +1-631-835-4771

On Wed, Apr 5, 2017 at 3:03 PM, Michael Stolz  wrote:


We should add a "--start-locator=" option to the gfsh start server command
with the same semantics as the start-locator property

--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: +1-631-835-4771 <(631)%20835-4771>

On Wed, Apr 5, 2017 at 2:03 PM, William Markito Oliveira <
william.mark...@gmail.com> wrote:


Jianxia, you can set the property "start-locator" in gemfire.properties as
below...  So the server then will have an embedded locator.

http://geode.apache.org/docs/guide/11/reference/topics/gemfi
re_properties.html
start-locator If set, automatically starts a locator in the current
process
when the member connects to the distributed system and stops the locator
when the member disconnects.

To use, specify the locator with an optional address or host specification
and a required port number, in one of these formats:

start-locator=address[port1]

start-locator=port1

If you only specify the port, the address assigned to the member is used
for the locator.

If not already there, this locator is automatically added to the list of
locators in this set of gemfire properties.
*not set*

On Wed, Apr 5, 2017 at 12:50 PM, Jianxia Chen  wrote:


Hi Darrel,

How to configure a colocated locator in the same server process? Just
curious. What I understand is that the locator is in its own process.

Thanks,
Jianxia

On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider <

dschnei...@pivotal.io>

wrote:


I like the idea of servers failing to start if no locator exists.
But does a use case for a server with no locator exist? What about

ease

of

development?

I could see that it would be easier to start just a single server

process

instead of two (locator and server). But for this use case couldn't

the

developer just configure a colocated locator in the same server

process?

This would have the benefit of the clients during development and
production using a locator consistently.

Is it true that the server with no locator will never have any peer

members

in its cluster?
Clients can still connect to this singleton server by being configured

with

the server host and port instead of the locator.


On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao 

wrote:

Without connecting to the server, I think you can still stop it by
specifying --pid or --dir in "stop server" command.

On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer <

ukohlme...@pivotal.io>

wrote:


Hey there,

Current Geode allows a user to start a server without being linked

to a

Locator. Which in itself is not incorrect, but once started there

is

no

way

to connect to that server to manage it.

I know that we have taken an opinionated view that member

discovery

can

only now happen through a locator and that multicast is an option

anymore.

Can we take the same opinionated view where we either state that

unless

your server is connecting to a locator, it cannot be started OR we

fix

the

default behavior where we can start a server but cannot connect to

it,

and

have to resort to "kill -9" commands to kill the server.

--Udo




--
Cheers

Jinmei




--
~/William

Re: Orphaned Server processes

[Michael Stolz]

Actually, the server KNOWS it is all by itself, and since that puts into an
unusable state, why not just default to starting an embedded locator on the
default port? Instant single-node GemFire.

--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: +1-631-835-4771

On Wed, Apr 5, 2017 at 3:03 PM, Michael Stolz  wrote:

> We should add a "--start-locator=" option to the gfsh start server command
> with the same semantics as the start-locator property
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771 <(631)%20835-4771>
>
> On Wed, Apr 5, 2017 at 2:03 PM, William Markito Oliveira <
> william.mark...@gmail.com> wrote:
>
>> Jianxia, you can set the property "start-locator" in gemfire.properties as
>> below...  So the server then will have an embedded locator.
>>
>> http://geode.apache.org/docs/guide/11/reference/topics/gemfi
>> re_properties.html
>> start-locator If set, automatically starts a locator in the current
>> process
>> when the member connects to the distributed system and stops the locator
>> when the member disconnects.
>>
>> To use, specify the locator with an optional address or host specification
>> and a required port number, in one of these formats:
>>
>> start-locator=address[port1]
>>
>> start-locator=port1
>>
>> If you only specify the port, the address assigned to the member is used
>> for the locator.
>>
>> If not already there, this locator is automatically added to the list of
>> locators in this set of gemfire properties.
>> *not set*
>>
>> On Wed, Apr 5, 2017 at 12:50 PM, Jianxia Chen  wrote:
>>
>> > Hi Darrel,
>> >
>> > How to configure a colocated locator in the same server process? Just
>> > curious. What I understand is that the locator is in its own process.
>> >
>> > Thanks,
>> > Jianxia
>> >
>> > On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider <
>> dschnei...@pivotal.io>
>> > wrote:
>> >
>> > > I like the idea of servers failing to start if no locator exists.
>> > > But does a use case for a server with no locator exist? What about
>> ease
>> > of
>> > > development?
>> > >
>> > > I could see that it would be easier to start just a single server
>> process
>> > > instead of two (locator and server). But for this use case couldn't
>> the
>> > > developer just configure a colocated locator in the same server
>> process?
>> > > This would have the benefit of the clients during development and
>> > > production using a locator consistently.
>> > >
>> > > Is it true that the server with no locator will never have any peer
>> > members
>> > > in its cluster?
>> > > Clients can still connect to this singleton server by being configured
>> > with
>> > > the server host and port instead of the locator.
>> > >
>> > >
>> > > On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao 
>> wrote:
>> > >
>> > > > Without connecting to the server, I think you can still stop it by
>> > > > specifying --pid or --dir in "stop server" command.
>> > > >
>> > > > On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer <
>> ukohlme...@pivotal.io>
>> > > > wrote:
>> > > >
>> > > > > Hey there,
>> > > > >
>> > > > > Current Geode allows a user to start a server without being linked
>> > to a
>> > > > > Locator. Which in itself is not incorrect, but once started there
>> is
>> > no
>> > > > way
>> > > > > to connect to that server to manage it.
>> > > > >
>> > > > > I know that we have taken an opinionated view that member
>> discovery
>> > can
>> > > > > only now happen through a locator and that multicast is an option
>> > > > anymore.
>> > > > >
>> > > > > Can we take the same opinionated view where we either state that
>> > unless
>> > > > > your server is connecting to a locator, it cannot be started OR we
>> > fix
>> > > > the
>> > > > > default behavior where we can start a server but cannot connect to
>> > it,
>> > > > and
>> > > > > have to resort to "kill -9" commands to kill the server.
>> > > > >
>> > > > > --Udo
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > > --
>> > > > Cheers
>> > > >
>> > > > Jinmei
>> > > >
>> > >
>> >
>>
>>
>>
>> --
>> ~/William
>>
>
>

Re: Orphaned Server processes

[Michael Stolz]

We should add a "--start-locator=" option to the gfsh start server command
with the same semantics as the start-locator property

--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: +1-631-835-4771

On Wed, Apr 5, 2017 at 2:03 PM, William Markito Oliveira <
william.mark...@gmail.com> wrote:

> Jianxia, you can set the property "start-locator" in gemfire.properties as
> below...  So the server then will have an embedded locator.
>
> http://geode.apache.org/docs/guide/11/reference/topics/
> gemfire_properties.html
> start-locator If set, automatically starts a locator in the current process
> when the member connects to the distributed system and stops the locator
> when the member disconnects.
>
> To use, specify the locator with an optional address or host specification
> and a required port number, in one of these formats:
>
> start-locator=address[port1]
>
> start-locator=port1
>
> If you only specify the port, the address assigned to the member is used
> for the locator.
>
> If not already there, this locator is automatically added to the list of
> locators in this set of gemfire properties.
> *not set*
>
> On Wed, Apr 5, 2017 at 12:50 PM, Jianxia Chen  wrote:
>
> > Hi Darrel,
> >
> > How to configure a colocated locator in the same server process? Just
> > curious. What I understand is that the locator is in its own process.
> >
> > Thanks,
> > Jianxia
> >
> > On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider  >
> > wrote:
> >
> > > I like the idea of servers failing to start if no locator exists.
> > > But does a use case for a server with no locator exist? What about ease
> > of
> > > development?
> > >
> > > I could see that it would be easier to start just a single server
> process
> > > instead of two (locator and server). But for this use case couldn't the
> > > developer just configure a colocated locator in the same server
> process?
> > > This would have the benefit of the clients during development and
> > > production using a locator consistently.
> > >
> > > Is it true that the server with no locator will never have any peer
> > members
> > > in its cluster?
> > > Clients can still connect to this singleton server by being configured
> > with
> > > the server host and port instead of the locator.
> > >
> > >
> > > On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao 
> wrote:
> > >
> > > > Without connecting to the server, I think you can still stop it by
> > > > specifying --pid or --dir in "stop server" command.
> > > >
> > > > On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer <
> ukohlme...@pivotal.io>
> > > > wrote:
> > > >
> > > > > Hey there,
> > > > >
> > > > > Current Geode allows a user to start a server without being linked
> > to a
> > > > > Locator. Which in itself is not incorrect, but once started there
> is
> > no
> > > > way
> > > > > to connect to that server to manage it.
> > > > >
> > > > > I know that we have taken an opinionated view that member discovery
> > can
> > > > > only now happen through a locator and that multicast is an option
> > > > anymore.
> > > > >
> > > > > Can we take the same opinionated view where we either state that
> > unless
> > > > > your server is connecting to a locator, it cannot be started OR we
> > fix
> > > > the
> > > > > default behavior where we can start a server but cannot connect to
> > it,
> > > > and
> > > > > have to resort to "kill -9" commands to kill the server.
> > > > >
> > > > > --Udo
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Cheers
> > > >
> > > > Jinmei
> > > >
> > >
> >
>
>
>
> --
> ~/William
>

Re: Review Request 58187: GEODE-2732 after auto-reconnect a server is restarted on the default port of 40404

[Hitesh Khamesra]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58187/#review171159
---


Ship it!




Ship It!

- Hitesh Khamesra


On April 4, 2017, 8:46 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58187/
> ---
> 
> (Updated April 4, 2017, 8:46 p.m.)
> 
> 
> Review request for geode, Galen O'Sullivan, Hitesh Khamesra, and Udo 
> Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Gfsh command line parameters were put into ThreadLocals to make them 
> available to the XML parser.  These are now held in non-thread-local 
> variables so that all threads, including the auto-reconnect thread, can see 
> them when building the cache.
> 
> This diff also includes some minor refactoring in 
> org.apache.geode.internal.tcp.  It primarily removes some 
> "this.owner.getConduit().doSomething" with "this.conduit.doSomething" and 
> removes dead code.
> 
> 
> Diffs
> -
> 
>   
> extensions/geode-modules-tomcat8/src/test/java/org/apache/geode/modules/session/Tomcat8SessionsClientServerDUnitTest.java
>  e475f40339e294ad48b403db1afa7aa624d5e80c 
>   geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java 
> 9435bd8178248c4fa34f6867d15a7cdfdec06d6b 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/CacheServerLauncher.java
>  760abd3d946281d474502a9af2e8fe823a011329 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/xmlcache/CacheCreation.java
>  1c3c93314841f5623c0e6387500af88f106328d9 
>   geode-core/src/main/java/org/apache/geode/internal/tcp/Connection.java 
> a0af24501a5081fe483160c5bf4fc7671545684e 
>   geode-core/src/main/java/org/apache/geode/internal/tcp/ConnectionTable.java 
> 08a90096c0cf0348c0fa34b7ff8e18806810ab68 
>   
> geode-core/src/main/java/org/apache/geode/internal/tcp/DirectReplySender.java 
> 3872ee98ec24fe95894c0def538e3752136b05c3 
>   geode-core/src/main/java/org/apache/geode/internal/tcp/MsgReader.java 
> fc5627112ac8dd456976139d3750fd951812879b 
>   geode-core/src/main/java/org/apache/geode/internal/tcp/NIOMsgReader.java 
> 50f5faedba056ec4f57124aefd56477dc11c1cf6 
>   
> geode-core/src/test/java/org/apache/geode/cache30/ReconnectWithCacheXMLDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/resources/org/apache/geode/cache30/ReconnectWithCacheXMLDUnitTest.xml
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/58187/diff/1/
> 
> 
> Testing
> ---
> 
> new test, precheckin
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

[jira] [Commented] (GEODE-2751) UniversalMembershipListenerAdapterDUnitTest.testSystemClientEventsInServer fails on Jenkins

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15957351#comment-15957351
 ] 

ASF subversion and git services commented on GEODE-2751:


Commit 534bb8f9ebbae8291687bb7fa1ea0fd9c17c7e7f in geode's branch 
refs/heads/develop from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=534bb8f ]

GEODE-2751 
UniversalMembershipListenerAdapterDUnitTest.testSystemClientEventsInServer

adding files not included in 02a31e22ad350a84ea2797562d13c6b16262481b


> UniversalMembershipListenerAdapterDUnitTest.testSystemClientEventsInServer 
> fails on Jenkins
> ---
>
> Key: GEODE-2751
> URL: https://issues.apache.org/jira/browse/GEODE-2751
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Hitesh Khamesra
>
> Error Message
> org.junit.ComparisonFailure: 
> expected:<[67.195.81.156](15619):32...> but 
> was:<[asf912](15619):32...>
> Stacktrace
> org.junit.ComparisonFailure: 
> expected:<[67.195.81.156](15619):32...> but 
> was:<[asf912](15619):32...>
>   at org.junit.Assert.assertEquals(Assert.java:115)
>   at org.junit.Assert.assertEquals(Assert.java:144)
>   at 
> org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest.doTestSystemClientEventsInServer(UniversalMembershipListenerAdapterDUnitTest.java:946)
>   at 
> org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest.testSystemClientEventsInServer(UniversalMembershipListenerAdapterDUnitTest.java:731)
>   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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.GeneratedMethodAccessor352.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.GeneratedMethodAccessor351.invoke(Unknown 

Re: Orphaned Server processes

[Udo Kohlmeyer]

@Anil,

I agree... quick start to evaluate the product... "start server 
--name=server1" is the simplest way to start a server... BUT there are 
no regions or anything ... So we really only have a GemFire process that 
does not allow you to do anything with it... except connect to it from a 
client and even the client cannot do anything with the server, because 
it has not admin capability.


--Udo


On 4/5/17 10:53, Anilkumar Gingade wrote:

But does a use case for a server with no locator exist? What about ease

of development?

I could see that it would be easier to start just a single server

process instead of two (locator and server).

Agree with Darrel, for someone who is evaluating the product, it helps to
build quick application and play around, without getting too much into the
cluster setup. Also, it is needed/helpful for use cases where its used as
embedded caching.

-Anil.


On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider 
wrote:


I like the idea of servers failing to start if no locator exists.
But does a use case for a server with no locator exist? What about ease of
development?

I could see that it would be easier to start just a single server process
instead of two (locator and server). But for this use case couldn't the
developer just configure a colocated locator in the same server process?
This would have the benefit of the clients during development and
production using a locator consistently.

Is it true that the server with no locator will never have any peer members
in its cluster?
Clients can still connect to this singleton server by being configured with
the server host and port instead of the locator.


On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao  wrote:


Without connecting to the server, I think you can still stop it by
specifying --pid or --dir in "stop server" command.

On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer 
wrote:


Hey there,

Current Geode allows a user to start a server without being linked to a
Locator. Which in itself is not incorrect, but once started there is no

way

to connect to that server to manage it.

I know that we have taken an opinionated view that member discovery can
only now happen through a locator and that multicast is an option

anymore.

Can we take the same opinionated view where we either state that unless
your server is connecting to a locator, it cannot be started OR we fix

the

default behavior where we can start a server but cannot connect to it,

and

have to resort to "kill -9" commands to kill the server.

--Udo




--
Cheers

Jinmei

Re: Orphaned Server processes

[William Markito Oliveira]

Jianxia, you can set the property "start-locator" in gemfire.properties as
below...  So the server then will have an embedded locator.

http://geode.apache.org/docs/guide/11/reference/topics/gemfire_properties.html
start-locator If set, automatically starts a locator in the current process
when the member connects to the distributed system and stops the locator
when the member disconnects.

To use, specify the locator with an optional address or host specification
and a required port number, in one of these formats:

start-locator=address[port1]

start-locator=port1

If you only specify the port, the address assigned to the member is used
for the locator.

If not already there, this locator is automatically added to the list of
locators in this set of gemfire properties.
*not set*

On Wed, Apr 5, 2017 at 12:50 PM, Jianxia Chen  wrote:

> Hi Darrel,
>
> How to configure a colocated locator in the same server process? Just
> curious. What I understand is that the locator is in its own process.
>
> Thanks,
> Jianxia
>
> On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider 
> wrote:
>
> > I like the idea of servers failing to start if no locator exists.
> > But does a use case for a server with no locator exist? What about ease
> of
> > development?
> >
> > I could see that it would be easier to start just a single server process
> > instead of two (locator and server). But for this use case couldn't the
> > developer just configure a colocated locator in the same server process?
> > This would have the benefit of the clients during development and
> > production using a locator consistently.
> >
> > Is it true that the server with no locator will never have any peer
> members
> > in its cluster?
> > Clients can still connect to this singleton server by being configured
> with
> > the server host and port instead of the locator.
> >
> >
> > On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao  wrote:
> >
> > > Without connecting to the server, I think you can still stop it by
> > > specifying --pid or --dir in "stop server" command.
> > >
> > > On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer 
> > > wrote:
> > >
> > > > Hey there,
> > > >
> > > > Current Geode allows a user to start a server without being linked
> to a
> > > > Locator. Which in itself is not incorrect, but once started there is
> no
> > > way
> > > > to connect to that server to manage it.
> > > >
> > > > I know that we have taken an opinionated view that member discovery
> can
> > > > only now happen through a locator and that multicast is an option
> > > anymore.
> > > >
> > > > Can we take the same opinionated view where we either state that
> unless
> > > > your server is connecting to a locator, it cannot be started OR we
> fix
> > > the
> > > > default behavior where we can start a server but cannot connect to
> it,
> > > and
> > > > have to resort to "kill -9" commands to kill the server.
> > > >
> > > > --Udo
> > > >
> > > >
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>



-- 
~/William

Re: Orphaned Server processes

[Udo Kohlmeyer]

I think an embedded server makes sense. No locator required, UNLESS you 
want to form a cluster and then I think you need a locator. (haven't 
tried this without multicast)


Shutting down a server with --pid or --dir works. BUT... One cannot 
connect to a default server "start server --name=server1". This is a 
server that can only be connected to directly from a client, BUT the 
client cannot do any admin (create region, etc)... So in essence when 
starting a server without locator or management interfaces (REST,JMX) 
enabled, just wastes space and cannot be managed...


I'd like to suggest that if we start an "orphan" server, it either does 
not allow it to be started, because it is really just sitting there 
without any management capability OR we detect that no management 
interfaces have been configured and start the JMX manager to allow for 
management.


--Udo
On 4/5/17 10:36, Darrel Schneider wrote:

I like the idea of servers failing to start if no locator exists.
But does a use case for a server with no locator exist? What about ease of
development?

I could see that it would be easier to start just a single server process
instead of two (locator and server). But for this use case couldn't the
developer just configure a colocated locator in the same server process?
This would have the benefit of the clients during development and
production using a locator consistently.

Is it true that the server with no locator will never have any peer members
in its cluster?
Clients can still connect to this singleton server by being configured with
the server host and port instead of the locator.


On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao  wrote:


Without connecting to the server, I think you can still stop it by
specifying --pid or --dir in "stop server" command.

On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer 
wrote:


Hey there,

Current Geode allows a user to start a server without being linked to a
Locator. Which in itself is not incorrect, but once started there is no

way

to connect to that server to manage it.

I know that we have taken an opinionated view that member discovery can
only now happen through a locator and that multicast is an option

anymore.

Can we take the same opinionated view where we either state that unless
your server is connecting to a locator, it cannot be started OR we fix

the

default behavior where we can start a server but cannot connect to it,

and

have to resort to "kill -9" commands to kill the server.

--Udo




--
Cheers

Jinmei

Re: Global PDX Types -> Move to Region Level?

[Hitesh Khamesra]

Well said, Mike. We should document that as best practices.

As Anthony mentioned, we should look for fuzzy type checking, atleast for 
numbers. I did consider this some time back. But It is tedious to support 
backward compability, unless we say pdx version 2.  


  From: Anthony Baker 
 To: dev@geode.apache.org 
 Sent: Wednesday, April 5, 2017 10:00 AM
 Subject: Re: Global PDX Types -> Move to Region Level?
   
Converting from schema-less (JSON) to schema-typed (PDX) is hard.  Perhaps we 
should explore fuzzy matching or type supersets to better JSON into Geode.

Anthony

> On Apr 5, 2017, at 9:42 AM, Michael Stolz  wrote:
> 
> There's nothing to prevent putting the same object into multiple regions.
> The type catalog for a database shouldn't be relative to a table.
> It should be database wide.
> 
> The real problem in this case is the proliferation of PDX Types caused by
> using JSON documents that have only some of their fields populated, and
> have their fields in arbitrary orders. The documents in the particular case
> studied really are intended to all be the same type, but it's difficult to
> tell because they are structurally mutated in so many ways.
> 
> It might be possible to make Geode figure out that they are all the same
> type, but the real best-practice here is make sure you structure your JSON
> documents consistently so that Geode can know that they are all of the same
> type. Don't leave fields empty, default them to null or zero. Don't change
> the order of the fields.
> 
> This behavioral change will make the JSON documents as structured as the
> Java Objects representing the same data would be. Geode doesn't have
> PDXtype explosion with Java Objects.
> 
> 
> 
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771
> 
> On Wed, Apr 5, 2017 at 5:51 AM, Olivier Mallassi > wrote:
> 
>> I do not know about the negative impact but could  you elaborate about the
>> DLock?
>> 
>> thx.
>> 
>> On Fri, Mar 31, 2017 at 7:48 PM, Real Wes  wrote:
>> 
>>> 
>>> Would there be a negative impact in moving PDXType’s to the region level
>>> instead of the cache level?  On the positive side, when there is an
>> object
>>> with a variable number of fields being stored in a partitioned region, we
>>> would get rid of the distributed lock.  As it is now at the cache level,
>> a
>>> DLock is made, slowing performance.  Another positive is that export
>> would
>>> go much, much, much faster in systems with a lot of PDXType’s because all
>>> PDXType’s are exported with every region.
>>> 
>>> Thanks,
>>> Wes
>>> 
>>> 
>> 


   

Re: Orphaned Server processes

[Anilkumar Gingade]

>> But does a use case for a server with no locator exist? What about ease
of development?
>> I could see that it would be easier to start just a single server
process instead of two (locator and server).

Agree with Darrel, for someone who is evaluating the product, it helps to
build quick application and play around, without getting too much into the
cluster setup. Also, it is needed/helpful for use cases where its used as
embedded caching.

-Anil.


On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider 
wrote:

> I like the idea of servers failing to start if no locator exists.
> But does a use case for a server with no locator exist? What about ease of
> development?
>
> I could see that it would be easier to start just a single server process
> instead of two (locator and server). But for this use case couldn't the
> developer just configure a colocated locator in the same server process?
> This would have the benefit of the clients during development and
> production using a locator consistently.
>
> Is it true that the server with no locator will never have any peer members
> in its cluster?
> Clients can still connect to this singleton server by being configured with
> the server host and port instead of the locator.
>
>
> On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao  wrote:
>
> > Without connecting to the server, I think you can still stop it by
> > specifying --pid or --dir in "stop server" command.
> >
> > On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer 
> > wrote:
> >
> > > Hey there,
> > >
> > > Current Geode allows a user to start a server without being linked to a
> > > Locator. Which in itself is not incorrect, but once started there is no
> > way
> > > to connect to that server to manage it.
> > >
> > > I know that we have taken an opinionated view that member discovery can
> > > only now happen through a locator and that multicast is an option
> > anymore.
> > >
> > > Can we take the same opinionated view where we either state that unless
> > > your server is connecting to a locator, it cannot be started OR we fix
> > the
> > > default behavior where we can start a server but cannot connect to it,
> > and
> > > have to resort to "kill -9" commands to kill the server.
> > >
> > > --Udo
> > >
> > >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>

Re: Orphaned Server processes

[Jianxia Chen]

Hi Darrel,

How to configure a colocated locator in the same server process? Just
curious. What I understand is that the locator is in its own process.

Thanks,
Jianxia

On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider 
wrote:

> I like the idea of servers failing to start if no locator exists.
> But does a use case for a server with no locator exist? What about ease of
> development?
>
> I could see that it would be easier to start just a single server process
> instead of two (locator and server). But for this use case couldn't the
> developer just configure a colocated locator in the same server process?
> This would have the benefit of the clients during development and
> production using a locator consistently.
>
> Is it true that the server with no locator will never have any peer members
> in its cluster?
> Clients can still connect to this singleton server by being configured with
> the server host and port instead of the locator.
>
>
> On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao  wrote:
>
> > Without connecting to the server, I think you can still stop it by
> > specifying --pid or --dir in "stop server" command.
> >
> > On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer 
> > wrote:
> >
> > > Hey there,
> > >
> > > Current Geode allows a user to start a server without being linked to a
> > > Locator. Which in itself is not incorrect, but once started there is no
> > way
> > > to connect to that server to manage it.
> > >
> > > I know that we have taken an opinionated view that member discovery can
> > > only now happen through a locator and that multicast is an option
> > anymore.
> > >
> > > Can we take the same opinionated view where we either state that unless
> > > your server is connecting to a locator, it cannot be started OR we fix
> > the
> > > default behavior where we can start a server but cannot connect to it,
> > and
> > > have to resort to "kill -9" commands to kill the server.
> > >
> > > --Udo
> > >
> > >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>

Re: Orphaned Server processes

[Michael Stolz]

I'd like the server to refuse to start from gfsh if it can't reach a
locator.
That seems like exactly the correct behavior.

If you want to run a single node system for development, embedding a
locator makes sense.
Funny thing is, I don't know how to do that. Probably want an example for
that somewhere.

--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: +1-631-835-4771

On Wed, Apr 5, 2017 at 1:36 PM, Darrel Schneider 
wrote:

> I like the idea of servers failing to start if no locator exists.
> But does a use case for a server with no locator exist? What about ease of
> development?
>
> I could see that it would be easier to start just a single server process
> instead of two (locator and server). But for this use case couldn't the
> developer just configure a colocated locator in the same server process?
> This would have the benefit of the clients during development and
> production using a locator consistently.
>
> Is it true that the server with no locator will never have any peer members
> in its cluster?
> Clients can still connect to this singleton server by being configured with
> the server host and port instead of the locator.
>
>
> On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao  wrote:
>
> > Without connecting to the server, I think you can still stop it by
> > specifying --pid or --dir in "stop server" command.
> >
> > On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer 
> > wrote:
> >
> > > Hey there,
> > >
> > > Current Geode allows a user to start a server without being linked to a
> > > Locator. Which in itself is not incorrect, but once started there is no
> > way
> > > to connect to that server to manage it.
> > >
> > > I know that we have taken an opinionated view that member discovery can
> > > only now happen through a locator and that multicast is an option
> > anymore.
> > >
> > > Can we take the same opinionated view where we either state that unless
> > > your server is connecting to a locator, it cannot be started OR we fix
> > the
> > > default behavior where we can start a server but cannot connect to it,
> > and
> > > have to resort to "kill -9" commands to kill the server.
> > >
> > > --Udo
> > >
> > >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>

Re: Orphaned Server processes

[Darrel Schneider]

I like the idea of servers failing to start if no locator exists.
But does a use case for a server with no locator exist? What about ease of
development?

I could see that it would be easier to start just a single server process
instead of two (locator and server). But for this use case couldn't the
developer just configure a colocated locator in the same server process?
This would have the benefit of the clients during development and
production using a locator consistently.

Is it true that the server with no locator will never have any peer members
in its cluster?
Clients can still connect to this singleton server by being configured with
the server host and port instead of the locator.


On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao  wrote:

> Without connecting to the server, I think you can still stop it by
> specifying --pid or --dir in "stop server" command.
>
> On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer 
> wrote:
>
> > Hey there,
> >
> > Current Geode allows a user to start a server without being linked to a
> > Locator. Which in itself is not incorrect, but once started there is no
> way
> > to connect to that server to manage it.
> >
> > I know that we have taken an opinionated view that member discovery can
> > only now happen through a locator and that multicast is an option
> anymore.
> >
> > Can we take the same opinionated view where we either state that unless
> > your server is connecting to a locator, it cannot be started OR we fix
> the
> > default behavior where we can start a server but cannot connect to it,
> and
> > have to resort to "kill -9" commands to kill the server.
> >
> > --Udo
> >
> >
>
>
> --
> Cheers
>
> Jinmei
>

[jira] [Commented] (GEODE-2713) Function execution can lead to passing the address of a stack variable

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15957288#comment-15957288
 ] 

ASF subversion and git services commented on GEODE-2713:


Commit aefb2eba5caf6ea7bb3650095adc5f1194a45f66 in geode-native's branch 
refs/heads/develop from Jacob Barrett
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=aefb2eb ]

GEODE-2713: Workaround for Solaris Studio C++11 shared_ptr bug.

- SS C++11 missing explicit bool cast operator.


> Function execution can lead to passing the address of a stack variable
> --
>
> Key: GEODE-2713
> URL: https://issues.apache.org/jira/browse/GEODE-2713
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>
> In ThinClientRegion::executeFunctionSH(), the address of a stack variable 
> (the result collector lock) is passed to the workers. If an exception occurs 
> with any of the workers, the function will return, causing the stack variable 
> to be destructed. Since the workers have the raw address, it is now a 
> dangling pointer situation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 58213: GEODE-2749: don't ignore bin/ because we have bin/ in src

[Mark Bretl]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58213/#review171148
---


Ship it!




I missed geode-assembly/src/main/dist/bin/ in my initial review. Thanks for the 
update Kirk.

- Mark Bretl


On April 5, 2017, 10:19 a.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58213/
> ---
> 
> (Updated April 5, 2017, 10:19 a.m.)
> 
> 
> Review request for geode, Anthony Baker, Avinash Dongre, Mark Bretl, and Udo 
> Kohlmeyer.
> 
> 
> Bugs: GEODE-2749
> https://issues.apache.org/jira/browse/GEODE-2749
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2749: don't ignore bin/ because we have bin/ in src
> 
> $ find . -name 'bin'
> ./extensions/geode-modules-assembly/release/session/bin <-- contains 
> modify_war script
> ./extensions/geode-modules-tomcat8/bin  <-- empty?
> ./geode-assembly/src/main/dist/bin  <-- contains our gfsh 
> scripts
> 
> 
> Diffs
> -
> 
>   .gitignore 31d5996b833bb3a32a0e2480e94335d5fa05a914 
>   gradle/rat.gradle 7bea470ae681492c61a76315ecad09a53c3f43fe 
> 
> 
> Diff: https://reviews.apache.org/r/58213/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Re: Review Request 58213: GEODE-2749: don't ignore bin/ because we have bin/ in src

[Anthony Baker]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58213/#review171146
---


Ship it!




Ship It!

- Anthony Baker


On April 5, 2017, 5:19 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58213/
> ---
> 
> (Updated April 5, 2017, 5:19 p.m.)
> 
> 
> Review request for geode, Anthony Baker, Avinash Dongre, Mark Bretl, and Udo 
> Kohlmeyer.
> 
> 
> Bugs: GEODE-2749
> https://issues.apache.org/jira/browse/GEODE-2749
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2749: don't ignore bin/ because we have bin/ in src
> 
> $ find . -name 'bin'
> ./extensions/geode-modules-assembly/release/session/bin <-- contains 
> modify_war script
> ./extensions/geode-modules-tomcat8/bin  <-- empty?
> ./geode-assembly/src/main/dist/bin  <-- contains our gfsh 
> scripts
> 
> 
> Diffs
> -
> 
>   .gitignore 31d5996b833bb3a32a0e2480e94335d5fa05a914 
>   gradle/rat.gradle 7bea470ae681492c61a76315ecad09a53c3f43fe 
> 
> 
> Diff: https://reviews.apache.org/r/58213/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Re: Orphaned Server processes

[Jinmei Liao]

Without connecting to the server, I think you can still stop it by
specifying --pid or --dir in "stop server" command.

On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer 
wrote:

> Hey there,
>
> Current Geode allows a user to start a server without being linked to a
> Locator. Which in itself is not incorrect, but once started there is no way
> to connect to that server to manage it.
>
> I know that we have taken an opinionated view that member discovery can
> only now happen through a locator and that multicast is an option anymore.
>
> Can we take the same opinionated view where we either state that unless
> your server is connecting to a locator, it cannot be started OR we fix the
> default behavior where we can start a server but cannot connect to it, and
> have to resort to "kill -9" commands to kill the server.
>
> --Udo
>
>


-- 
Cheers

Jinmei

Broken: apache/geode#2294 (develop - 02a31e2)

[Travis CI]

Build Update for apache/geode
-

Build: #2294
Status: Broken

Duration: 6 minutes and 14 seconds
Commit: 02a31e2 (develop)
Author: Bruce Schuchardt
Message: GEODE-2751 
UniversalMembershipListenerAdapterDUnitTest.testSystemClientEventsInServer

This forces the test to always use numeric host addresses

View the changeset: 
https://github.com/apache/geode/compare/edd018b971d9...02a31e22ad35

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/218948927

--

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

Re: Review Request 58158: GEODE-2749: ignore bin/ and out/ which are commonly created by IDEs

[Kirk Lund]

> On April 5, 2017, 2:31 p.m., Anthony Baker wrote:
> > -1 
> > 
> > There are several bin/ dirs with source files:
> > 
> > ```
> > ~/code/incubator-geode (develop)$ find . -name bin -type d
> > ./extensions/geode-modules-assembly/release/session/bin
> > ./geode-assembly/src/main/dist/bin
> > ```
> > 
> > This change will cause problems.

Changes were already committed. I have a partial revert ready and in review. 
Please see https://reviews.apache.org/r/58213/


- Kirk


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58158/#review171122
---


On April 3, 2017, 7:57 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58158/
> ---
> 
> (Updated April 3, 2017, 7:57 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Patrick 
> Rhomberg.
> 
> 
> Bugs: GEODE-2749
> https://issues.apache.org/jira/browse/GEODE-2749
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> I installed new versions of Eclipse and IntelliJ and created geode projects 
> in both using the defaults for IDE output of compiled classes. They created 
> bin/ and out/ which were then failing rat and also showing up as untracked 
> files by git.
> 
> I added both to .gitignore and the ignore list in gradle/rat.gradle and 
> tested with git status and ./gradlew rat.
> 
> 
> Diffs
> -
> 
>   .gitignore 38c813196f5 
>   gradle/rat.gradle c97a9e9dc78 
> 
> 
> Diff: https://reviews.apache.org/r/58158/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Review Request 58213: GEODE-2749: don't ignore bin/ because we have bin/ in src

[Kirk Lund]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58213/
---

Review request for geode, Anthony Baker, Avinash Dongre, Mark Bretl, and Udo 
Kohlmeyer.


Bugs: GEODE-2749
https://issues.apache.org/jira/browse/GEODE-2749


Repository: geode


Description
---

GEODE-2749: don't ignore bin/ because we have bin/ in src

$ find . -name 'bin'
./extensions/geode-modules-assembly/release/session/bin <-- contains modify_war 
script
./extensions/geode-modules-tomcat8/bin  <-- empty?
./geode-assembly/src/main/dist/bin  <-- contains our gfsh 
scripts


Diffs
-

  .gitignore 31d5996b833bb3a32a0e2480e94335d5fa05a914 
  gradle/rat.gradle 7bea470ae681492c61a76315ecad09a53c3f43fe 


Diff: https://reviews.apache.org/r/58213/diff/1/


Testing
---

precheckin in progress


Thanks,

Kirk Lund

Orphaned Server processes

[Udo Kohlmeyer]

Hey there,

Current Geode allows a user to start a server without being linked to a 
Locator. Which in itself is not incorrect, but once started there is no 
way to connect to that server to manage it.


I know that we have taken an opinionated view that member discovery can 
only now happen through a locator and that multicast is an option anymore.


Can we take the same opinionated view where we either state that unless 
your server is connecting to a locator, it cannot be started OR we fix 
the default behavior where we can start a server but cannot connect to 
it, and have to resort to "kill -9" commands to kill the server.


--Udo

Re: [DISCUSS] security threats (was Re: [CVE-2017-5649] Apache Geode information disclosure vulnerability)

[William Markito Oliveira]

Looks like a great wiki page to me. ;)

Cool summary Anthony! 

Sent from my iPhone

> On Apr 5, 2017, at 11:49 AM, Anthony Baker  wrote:
> 
> As a follow up to this CVE, I wanted to share the process for reporting and 
> responding to security issues:
> 
> https://www.apache.org/security/
> https://www.apache.org/security/committers.html
> 
> Here’s the short version:
> 
> - Report the vulnerability privately (secur...@apache.org | 
> priv...@geode.apache.org)
> - Fix the vulnerability
> - Release a new version(s) with the fix
> - Disclose the vulnerability
> 
> Secondly, I think it would be valuable to get the community’s perspective on 
> the kinds of security threats that a Geode deployment may encounter.  Here 
> are a few questions to spark the conversation:
> 
> - When is a bug a security bug?
> - When does a bug require a CVE and disclosure?
> - How do we know how severe a security issue is?
> - How soon do we need to respond to a security issue?
> 
> Anthony
> 
>> On Apr 4, 2017, at 7:31 AM, Anthony Baker  wrote:
>> 
>> CVE-2017-5649: Apache Geode information disclosure vulnerability
>> 
>> Severity:  Medium
>> Base score:  5.5 (CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:L)
>> 
>> Vendor:
>> The Apache Software Foundation
>> 
>> Versions Affected:
>> Geode 1.1.0
>> 
>> Description:
>> When a cluster has enabled security by setting the security-manager
>> property, a user should have DATA:READ permission to view data stored
>> in the cluster.  However, if an authenticated user has CLUSTER:READ
>> but not DATA:READ permission they can access the data
>> browser page in Pulse.  From there the user could execute an OQL query
>> that exposes data stored in the cluster.
>> 
>> Mitigation:
>> 1.1.0 users should upgrade to 1.1.1
>> 
>> Credit:
>> This issue was discovered by Jinmei Liao.
>> 
>> References:
>> https://www.apache.org/security/
> 

Re: Global PDX Types -> Move to Region Level?

[Anthony Baker]

Converting from schema-less (JSON) to schema-typed (PDX) is hard.  Perhaps we 
should explore fuzzy matching or type supersets to better JSON into Geode.

Anthony

> On Apr 5, 2017, at 9:42 AM, Michael Stolz  wrote:
> 
> There's nothing to prevent putting the same object into multiple regions.
> The type catalog for a database shouldn't be relative to a table.
> It should be database wide.
> 
> The real problem in this case is the proliferation of PDX Types caused by
> using JSON documents that have only some of their fields populated, and
> have their fields in arbitrary orders. The documents in the particular case
> studied really are intended to all be the same type, but it's difficult to
> tell because they are structurally mutated in so many ways.
> 
> It might be possible to make Geode figure out that they are all the same
> type, but the real best-practice here is make sure you structure your JSON
> documents consistently so that Geode can know that they are all of the same
> type. Don't leave fields empty, default them to null or zero. Don't change
> the order of the fields.
> 
> This behavioral change will make the JSON documents as structured as the
> Java Objects representing the same data would be. Geode doesn't have
> PDXtype explosion with Java Objects.
> 
> 
> 
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771
> 
> On Wed, Apr 5, 2017 at 5:51 AM, Olivier Mallassi > wrote:
> 
>> I do not know about the negative impact but could  you elaborate about the
>> DLock?
>> 
>> thx.
>> 
>> On Fri, Mar 31, 2017 at 7:48 PM, Real Wes  wrote:
>> 
>>> 
>>> Would there be a negative impact in moving PDXType’s to the region level
>>> instead of the cache level?  On the positive side, when there is an
>> object
>>> with a variable number of fields being stored in a partitioned region, we
>>> would get rid of the distributed lock.  As it is now at the cache level,
>> a
>>> DLock is made, slowing performance.  Another positive is that export
>> would
>>> go much, much, much faster in systems with a lot of PDXType’s because all
>>> PDXType’s are exported with every region.
>>> 
>>> Thanks,
>>> Wes
>>> 
>>> 
>> 

Build failed in Jenkins: Geode-nightly #798

[Apache Jenkins Server]

See 


Changes:

[klund] GEODE-2748: fix xmlns to specify javaee instead of j2ee

[klund] GEODE-2749: ignore bin/ and out/ which are commonly created by IDEs

[khowe] GEODE-2420: Add classes to estimated the size of exported logs

[khowe] GEODE-2420: Updates from review

[boglesby] GEODE-2750: The lucene index is now destroyed on remote members 
before

[jiliao] GEM-1351: Move a test to the open side and fix the other tests

--
[...truncated 103.37 KB...]
:geode-cq:compileTestJavaNote: 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-cq:processTestResources
:geode-cq:testClasses
:geode-cq:checkMissedTests
:geode-cq:spotlessJavaCheck
:geode-cq:spotlessCheck
:geode-cq:test
:geode-cq:check
:geode-cq:build
:geode-cq:distributedTest
:geode-cq:flakyTest
:geode-cq:integrationTest
:geode-json:assemble
:geode-json:compileTestJava UP-TO-DATE
:geode-json:processTestResources
:geode-json:testClasses
:geode-json:checkMissedTests UP-TO-DATE
:geode-json:spotlessJavaCheck
:geode-json:spotlessCheck
:geode-json:test UP-TO-DATE
:geode-json:check
:geode-json:build
:geode-json:distributedTest UP-TO-DATE
:geode-json:flakyTest UP-TO-DATE
:geode-json:integrationTest UP-TO-DATE
:geode-junit:javadoc
:geode-junit:javadocJar
:geode-junit:sourcesJar
:geode-junit:signArchives SKIPPED
:geode-junit:assemble
:geode-junit:compileTestJava
:geode-junit:processTestResources UP-TO-DATE
:geode-junit:testClasses
:geode-junit:checkMissedTests
:geode-junit:spotlessJavaCheck
:geode-junit:spotlessCheck
:geode-junit:test
:geode-junit:check
:geode-junit:build
:geode-junit:distributedTest
:geode-junit:flakyTest
:geode-junit:integrationTest
:geode-lucene:assemble
:geode-lucene:compileTestJavaNote: 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-lucene:processTestResources
:geode-lucene:testClasses
:geode-lucene:checkMissedTests
:geode-lucene:spotlessJavaCheck
:geode-lucene:spotlessCheck
:geode-lucene:test
:geode-lucene:check
:geode-lucene:build
:geode-lucene:distributedTest
:geode-lucene:flakyTest
:geode-lucene:integrationTest
:geode-old-client-support:assemble
:geode-old-client-support:compileTestJava
:geode-old-client-support:processTestResources UP-TO-DATE
:geode-old-client-support:testClasses
:geode-old-client-support:checkMissedTests
:geode-old-client-support:spotlessJavaCheck
:geode-old-client-support:spotlessCheck
:geode-old-client-support:test
:geode-old-client-support:check
:geode-old-client-support:build
:geode-old-client-support:distributedTest
:geode-old-client-support:flakyTest
:geode-old-client-support:integrationTest
:geode-old-versions:javadoc UP-TO-DATE
:geode-old-versions:javadocJar
:geode-old-versions:sourcesJar
:geode-old-versions:signArchives SKIPPED
:geode-old-versions:assemble
:geode-old-versions:compileTestJava UP-TO-DATE
:geode-old-versions:processTestResources UP-TO-DATE
:geode-old-versions:testClasses UP-TO-DATE
:geode-old-versions:checkMissedTests UP-TO-DATE
:geode-old-versions:spotlessJavaCheck
:geode-old-versions:spotlessCheck
:geode-old-versions:test UP-TO-DATE
:geode-old-versions:check
:geode-old-versions:build
:geode-old-versions:distributedTest UP-TO-DATE
:geode-old-versions:flakyTest UP-TO-DATE
:geode-old-versions:integrationTest UP-TO-DATE
:geode-pulse:assemble
:geode-pulse:compileTestJavaNote: 

 uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: 

 uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-pulse:processTestResources
:geode-pulse:testClasses
:geode-pulse:checkMissedTests
:geode-pulse:spotlessJavaCheck
:geode-pulse:spotlessCheck
:geode-pulse:test
:geode-pulse:check
:geode-pulse:build
:geode-pulse:distributedTest
:geode-pulse:flakyTest
:geode-pulse:integrationTest
:geode-rebalancer:assemble
:geode-rebalancer:compileTestJava
:geode-rebalancer:processTestResources UP-TO-DATE
:geode-rebalancer:testClasses
:geode-rebalancer:checkMissedTests
:geode-rebalancer:spotlessJavaCheck
:geode-rebalancer:spotlessCheck
:geode-rebalancer:test
:geode-rebalancer:check
:geode-rebalancer:build
:geode-rebalancer:distributedTest
:geode-rebalancer:flakyTest
:geode-rebalancer:integrationTest
:geode-wan:assemble
:geode-wan:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with 

[DISCUSS] security threats (was Re: [CVE-2017-5649] Apache Geode information disclosure vulnerability)

[Anthony Baker]

As a follow up to this CVE, I wanted to share the process for reporting and 
responding to security issues:

https://www.apache.org/security/
https://www.apache.org/security/committers.html

Here’s the short version:

- Report the vulnerability privately (secur...@apache.org | 
priv...@geode.apache.org)
- Fix the vulnerability
- Release a new version(s) with the fix
- Disclose the vulnerability

Secondly, I think it would be valuable to get the community’s perspective on 
the kinds of security threats that a Geode deployment may encounter.  Here are 
a few questions to spark the conversation:

- When is a bug a security bug?
- When does a bug require a CVE and disclosure?
- How do we know how severe a security issue is?
- How soon do we need to respond to a security issue?

Anthony

> On Apr 4, 2017, at 7:31 AM, Anthony Baker  wrote:
> 
> CVE-2017-5649: Apache Geode information disclosure vulnerability
> 
> Severity:  Medium
> Base score:  5.5 (CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:L)
> 
> Vendor:
> The Apache Software Foundation
> 
> Versions Affected:
> Geode 1.1.0
> 
> Description:
> When a cluster has enabled security by setting the security-manager
> property, a user should have DATA:READ permission to view data stored
> in the cluster.  However, if an authenticated user has CLUSTER:READ
> but not DATA:READ permission they can access the data
> browser page in Pulse.  From there the user could execute an OQL query
> that exposes data stored in the cluster.
> 
> Mitigation:
> 1.1.0 users should upgrade to 1.1.1
> 
> Credit:
> This issue was discovered by Jinmei Liao.
> 
> References:
> https://www.apache.org/security/

Re: Global PDX Types -> Move to Region Level?

[Michael Stolz]

There's nothing to prevent putting the same object into multiple regions.
The type catalog for a database shouldn't be relative to a table.
It should be database wide.

The real problem in this case is the proliferation of PDX Types caused by
using JSON documents that have only some of their fields populated, and
have their fields in arbitrary orders. The documents in the particular case
studied really are intended to all be the same type, but it's difficult to
tell because they are structurally mutated in so many ways.

It might be possible to make Geode figure out that they are all the same
type, but the real best-practice here is make sure you structure your JSON
documents consistently so that Geode can know that they are all of the same
type. Don't leave fields empty, default them to null or zero. Don't change
the order of the fields.

This behavioral change will make the JSON documents as structured as the
Java Objects representing the same data would be. Geode doesn't have
PDXtype explosion with Java Objects.



--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: +1-631-835-4771

On Wed, Apr 5, 2017 at 5:51 AM, Olivier Mallassi  wrote:

> I do not know about the negative impact but could  you elaborate about the
> DLock?
>
> thx.
>
> On Fri, Mar 31, 2017 at 7:48 PM, Real Wes  wrote:
>
> >
> > Would there be a negative impact in moving PDXType’s to the region level
> > instead of the cache level?  On the positive side, when there is an
> object
> > with a variable number of fields being stored in a partitioned region, we
> > would get rid of the distributed lock.  As it is now at the cache level,
> a
> > DLock is made, slowing performance.  Another positive is that export
> would
> > go much, much, much faster in systems with a lot of PDXType’s because all
> > PDXType’s are exported with every region.
> >
> > Thanks,
> > Wes
> >
> >
>

[jira] [Commented] (GEODE-2736) Native client thread pool get stuck sometimes during rolling restart

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15957192#comment-15957192
 ] 

ASF GitHub Bot commented on GEODE-2736:
---

Github user asfgit closed the pull request at:

https://github.com/apache/geode-native/pull/82


> Native client thread pool get stuck sometimes during rolling restart
> 
>
> Key: GEODE-2736
> URL: https://issues.apache.org/jira/browse/GEODE-2736
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Mark Hanson
>
> Users has a function which executes on all nodes hosting the region, during 
> rolling restart of the Geode servers, occasionally all the threads in the 
> Geode native client thread pool get stuck sometimes when certain exceptions 
> are thrown.
> The user thinks it is due to possible incorrect exception handling inside the 
> Geode native client code
> This leads to application threads getting stuck as the thread pool is not 
> available



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2736) Native client thread pool get stuck sometimes during rolling restart

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15957190#comment-15957190
 ] 

ASF subversion and git services commented on GEODE-2736:


Commit b0f00d044bfafcc4cfd457e83d2392c1d56d180f in geode-native's branch 
refs/heads/develop from [~mhansonp]
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=b0f00d0 ]

GEODE-2736: Fixed orphaned worker threads

- Force timeouts to be handled like no connection
- Added test

This closes #82.


> Native client thread pool get stuck sometimes during rolling restart
> 
>
> Key: GEODE-2736
> URL: https://issues.apache.org/jira/browse/GEODE-2736
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Mark Hanson
>
> Users has a function which executes on all nodes hosting the region, during 
> rolling restart of the Geode servers, occasionally all the threads in the 
> Geode native client thread pool get stuck sometimes when certain exceptions 
> are thrown.
> The user thinks it is due to possible incorrect exception handling inside the 
> Geode native client code
> This leads to application threads getting stuck as the thread pool is not 
> available



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #82: GEODE-2736: Fixed orphaned worker threads

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/geode-native/pull/82


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2713) Function execution can lead to passing the address of a stack variable

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15957178#comment-15957178
 ] 

ASF GitHub Bot commented on GEODE-2713:
---

Github user asfgit closed the pull request at:

https://github.com/apache/geode-native/pull/74


> Function execution can lead to passing the address of a stack variable
> --
>
> Key: GEODE-2713
> URL: https://issues.apache.org/jira/browse/GEODE-2713
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>
> In ThinClientRegion::executeFunctionSH(), the address of a stack variable 
> (the result collector lock) is passed to the workers. If an exception occurs 
> with any of the workers, the function will return, causing the stack variable 
> to be destructed. Since the workers have the raw address, it is now a 
> dangling pointer situation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2713) Function execution can lead to passing the address of a stack variable

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15957177#comment-15957177
 ] 

ASF subversion and git services commented on GEODE-2713:


Commit 4707a37a2016d07bb0451556b4f2edfc64911db3 in geode-native's branch 
refs/heads/develop from [~PivotalSarge]
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=4707a37 ]

GEODE-2713: Wrap result collector lock in shared_ptr.

- Ensure compliant formatting.
- Switch to std::make_shared.

This closes #74.


> Function execution can lead to passing the address of a stack variable
> --
>
> Key: GEODE-2713
> URL: https://issues.apache.org/jira/browse/GEODE-2713
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>
> In ThinClientRegion::executeFunctionSH(), the address of a stack variable 
> (the result collector lock) is passed to the workers. If an exception occurs 
> with any of the workers, the function will return, causing the stack variable 
> to be destructed. Since the workers have the raw address, it is now a 
> dangling pointer situation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #74: GEODE-2713: Wrap result collector lock in sha...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/geode-native/pull/74


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2751) UniversalMembershipListenerAdapterDUnitTest.testSystemClientEventsInServer fails on Jenkins

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15957176#comment-15957176
 ] 

ASF subversion and git services commented on GEODE-2751:


Commit 02a31e22ad350a84ea2797562d13c6b16262481b in geode's branch 
refs/heads/develop from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=02a31e2 ]

GEODE-2751 
UniversalMembershipListenerAdapterDUnitTest.testSystemClientEventsInServer

This forces the test to always use numeric host addresses


> UniversalMembershipListenerAdapterDUnitTest.testSystemClientEventsInServer 
> fails on Jenkins
> ---
>
> Key: GEODE-2751
> URL: https://issues.apache.org/jira/browse/GEODE-2751
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Hitesh Khamesra
>
> Error Message
> org.junit.ComparisonFailure: 
> expected:<[67.195.81.156](15619):32...> but 
> was:<[asf912](15619):32...>
> Stacktrace
> org.junit.ComparisonFailure: 
> expected:<[67.195.81.156](15619):32...> but 
> was:<[asf912](15619):32...>
>   at org.junit.Assert.assertEquals(Assert.java:115)
>   at org.junit.Assert.assertEquals(Assert.java:144)
>   at 
> org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest.doTestSystemClientEventsInServer(UniversalMembershipListenerAdapterDUnitTest.java:946)
>   at 
> org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest.testSystemClientEventsInServer(UniversalMembershipListenerAdapterDUnitTest.java:731)
>   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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.GeneratedMethodAccessor352.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.GeneratedMethodAccessor351.invoke(Unknown Source)
>   

[jira] [Created] (GEODE-2754) CI failure: WanAutoDiscoveryDUnitTest

[Bruce Schuchardt (JIRA)]

Bruce Schuchardt created GEODE-2754:
---

 Summary: CI failure: WanAutoDiscoveryDUnitTest
 Key: GEODE-2754
 URL: https://issues.apache.org/jira/browse/GEODE-2754
 Project: Geode
  Issue Type: Bug
  Components: wan
Reporter: Bruce Schuchardt


Two new tests in this class fail if the network happens to have a machine named 
"unknown".

{noformat}
:geode-wan:distributedTest

org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest > 
testValidAndInvalidHostRemoteLocators FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest$$Lambda$1538/701582275.run
 in VM 2 running on Host trout.gemstone.com with 8 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
at 
org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest.testRemoteLocators(WanAutoDiscoveryDUnitTest.java:645)
at 
org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest.testValidAndInvalidHostRemoteLocators(WanAutoDiscoveryDUnitTest.java:622)

Caused by:
java.lang.AssertionError: expected:<1> but was:<2>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at 
org.apache.geode.internal.cache.wan.WANTestBase.verifyPool(WANTestBase.java:3446)
at 
org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest.lambda$testRemoteLocators$1f02559b$1(WanAutoDiscoveryDUnitTest.java:645)

org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest > 
testInvalidHostRemoteLocators FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest$$Lambda$1538/701582275.run
 in VM 2 running on Host trout.gemstone.com with 8 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
at 
org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest.testRemoteLocators(WanAutoDiscoveryDUnitTest.java:645)
at 
org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest.testInvalidHostRemoteLocators(WanAutoDiscoveryDUnitTest.java:611)

Caused by:
java.lang.AssertionError: expected null, but was:
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotNull(Assert.java:755)
at org.junit.Assert.assertNull(Assert.java:737)
at org.junit.Assert.assertNull(Assert.java:747)
at 
org.apache.geode.internal.cache.wan.WANTestBase.verifyPool(WANTestBase.java:3448)
at 
org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest.lambda$testRemoteLocators$1f02559b$1(WanAutoDiscoveryDUnitTest.java:645)
{noformat}




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2736) Native client thread pool get stuck sometimes during rolling restart

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15957000#comment-15957000
 ] 

ASF GitHub Bot commented on GEODE-2736:
---

Github user echobravopapa commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/82#discussion_r109942702
  
--- Diff: 
src/cppcache/integration-test/testThinClientPoolExecuteFunctionThrowsException.cpp
 ---
@@ -303,6 +303,7 @@ DUNIT_TASK_DEFINITION(CLIENT1, Client1OpTest)
 LOGINFO("Executing the exception test it is expected to throw.");
 CacheableVectorPtr executeFunctionResult3 =
 
funcExec->withArgs(arrList)->withFilter(filter)->execute("ThinClientRegionExceptionTest",
 15)->getResult();
+FAIL("Failed to throw expected exception.");
--- End diff --

Perfect. @mhansonp may I ask you to please squash your commits as well...? 
TIA


> Native client thread pool get stuck sometimes during rolling restart
> 
>
> Key: GEODE-2736
> URL: https://issues.apache.org/jira/browse/GEODE-2736
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Mark Hanson
>
> Users has a function which executes on all nodes hosting the region, during 
> rolling restart of the Geode servers, occasionally all the threads in the 
> Geode native client thread pool get stuck sometimes when certain exceptions 
> are thrown.
> The user thinks it is due to possible incorrect exception handling inside the 
> Geode native client code
> This leads to application threads getting stuck as the thread pool is not 
> available



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #82: GEODE-2736: Fixed orphaned worker threads

[echobravopapa]

Github user echobravopapa commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/82#discussion_r109942702
  
--- Diff: 
src/cppcache/integration-test/testThinClientPoolExecuteFunctionThrowsException.cpp
 ---
@@ -303,6 +303,7 @@ DUNIT_TASK_DEFINITION(CLIENT1, Client1OpTest)
 LOGINFO("Executing the exception test it is expected to throw.");
 CacheableVectorPtr executeFunctionResult3 =
 
funcExec->withArgs(arrList)->withFilter(filter)->execute("ThinClientRegionExceptionTest",
 15)->getResult();
+FAIL("Failed to throw expected exception.");
--- End diff --

Perfect. @mhansonp may I ask you to please squash your commits as well...? 
TIA


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Review Request 58158: GEODE-2749: ignore bin/ and out/ which are commonly created by IDEs

[Anthony Baker]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58158/#review171122
---



-1 

There are several bin/ dirs with source files:

```
~/code/incubator-geode (develop)$ find . -name bin -type d
./extensions/geode-modules-assembly/release/session/bin
./geode-assembly/src/main/dist/bin
```

This change will cause problems.

- Anthony Baker


On April 3, 2017, 7:57 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58158/
> ---
> 
> (Updated April 3, 2017, 7:57 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Patrick 
> Rhomberg.
> 
> 
> Bugs: GEODE-2749
> https://issues.apache.org/jira/browse/GEODE-2749
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> I installed new versions of Eclipse and IntelliJ and created geode projects 
> in both using the defaults for IDE output of compiled classes. They created 
> bin/ and out/ which were then failing rat and also showing up as untracked 
> files by git.
> 
> I added both to .gitignore and the ignore list in gradle/rat.gradle and 
> tested with git status and ./gradlew rat.
> 
> 
> Diffs
> -
> 
>   .gitignore 38c813196f5 
>   gradle/rat.gradle c97a9e9dc78 
> 
> 
> Diff: https://reviews.apache.org/r/58158/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

[jira] [Commented] (GEODE-2726) Add Packer Build Files for VS 2017

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15956882#comment-15956882
 ] 

ASF GitHub Bot commented on GEODE-2726:
---

Github user mmartell closed the pull request at:

https://github.com/apache/geode-native/pull/76


> Add Packer Build Files for VS 2017
> --
>
> Key: GEODE-2726
> URL: https://issues.apache.org/jira/browse/GEODE-2726
> Project: Geode
>  Issue Type: New Feature
>  Components: native client
>Reporter: Michael Martell
>
> As a developer I want to setup an image to build nativeclient products using 
> Visual Studio 2017.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #76: GEODE-2726: Add Packer Build Files for VS 201...

[mmartell]

Github user mmartell closed the pull request at:

https://github.com/apache/geode-native/pull/76


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Global PDX Types -> Move to Region Level?

[Olivier Mallassi]

I do not know about the negative impact but could  you elaborate about the
DLock?

thx.

On Fri, Mar 31, 2017 at 7:48 PM, Real Wes  wrote:

>
> Would there be a negative impact in moving PDXType’s to the region level
> instead of the cache level?  On the positive side, when there is an object
> with a variable number of fields being stored in a partitioned region, we
> would get rid of the distributed lock.  As it is now at the cache level, a
> DLock is made, slowing performance.  Another positive is that export would
> go much, much, much faster in systems with a lot of PDXType’s because all
> PDXType’s are exported with every region.
>
> Thanks,
> Wes
>
>