Re: Addition of rmi-io library

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

Re: Addition of rmi-io library

Mike, ?? I think you meant 1.4.0 ?? Let’s keep the release discussion on the VOTE thread. IMO, adding another port has implications for security, firewalls, containers, bind addresses, etc. I haven’t cast my release vote yet since I’m still considering these things. Anthony > On Jan 24,

Re: Addition of rmi-io library

There is going to be a 9.3.1 shortly after 9.3.0. Lets not hold 9.3.0 for this. -- Mike Stolz Principal Engineer - Gemfire Product Manager Mobile: 631-835-4771 On Jan 24, 2018 10:58 AM, "Jinmei Liao" wrote: yeah, Jens just found that out too. It's opening up a new port in

Re: Addition of rmi-io library

Right - it needs to piggy-back on the existing JMX/RMI port in which case no new ports will be required. We're testing this now. --Jens On Wed, Jan 24, 2018 at 9:58 AM, Jinmei Liao wrote: > yeah, Jens just found that out too. It's opening up a new port in either >

Re: Addition of rmi-io library

yeah, Jens just found that out too. It's opening up a new port in either server/server and gfsh/jmManager cases. I think he has a solution to it and we will get it in soon. On Wed, Jan 24, 2018 at 9:47 AM, Dan Smith wrote: > > > > the content is going over the wire on

Re: Addition of rmi-io library

> > the content is going over the wire on whatever port that was port before. >From what I see, DownloadJarFunction is calling SimpleRemoteInputStream.export() which will call UnicastRemoteObject.exportObject. That's an RMI call to start a tcp server socket listening for connections to interact

Re: Addition of rmi-io library

As far as I can see, we are utilizing the streaming capability provided by the rmi-io, the content is going over the wire on whatever port that was port before. When streaming content from the gfsh to the jmxManager, it's using the jmx port; when getting jars between locator/servers, it's using

Re: Addition of rmi-io library

I don't have an issue with the dependency. But if we are opening up new ports for RMI connections, that seems like a potential security risk. If someone has enabled cluster SSL we shouldn't be opening up an insecure port for RMI connections. We should also make sure this is not leaking open

Addition of rmi-io library

Apologies that this was not raised earlier in discussion but I'm happy to describe it now. *Background:* When deploying jars into Geode they are moved through the system as simple byte[] blobs. This obviously consumes memory. The various affected areas are: - gfsh reads the jars into memory -