To address this we have two Jiras tracking the issue:
GEODE-4370 - jar deployment should not require additional ports to be opened
GEODE-4379 - gfsh deploy should push jars not have the server pull them
Essentially these will result in no new RMI ports being used/opened.
Code for 4370 is already
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, 2
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 either
server/server a
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
> server/server and gfsh/jmMana
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 whatever port that was port
>
> 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 w
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
the
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 socket
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
- th
