Menu
▾
▴
Re: [Wrapper-user] Wrapper behavior on Solaris 10 zone
|
From: Leif M. <lei...@ta...> - 2009-05-16 04:25:27
|
Santo, Sorry for this trouble with the Java Service Wrapper. We have designed it to work automatically when more than one copy of the Wrapper is run on the same machine. It does not intentionally allocate all 1000 ports. Rather it starts by attempting to allocate the first port, then moving on to the next if that first one is already allocated. Once it finds an open port it should never even attempt to access the rest of the range. How exactly are you determining that all 1000 ports are being reserved? allocated? when I run net stat on our test system with one copy of the Wrapper running I get this: --- # netstat TCP: IPv4 Local Address Remote Address Swind Send-Q Rwind Recv-Q State -------------------- -------------------- ----- ------ ----- ------ ----------- solx86.ssh 10.24.115.41.63503 49640 47 49640 0 ESTABLISHED localhost.63651 localhost.63650 49152 0 49152 0 TIME_WAIT localhost.31000 localhost.32000 49152 0 49152 0 ESTABLISHED localhost.32000 localhost.31000 49152 0 49170 0 ESTABLISHED Active UNIX domain sockets Address Type Vnode Conn Local Addr Remote Addr fffffe853d5cdac0 stream-ord fffffe855a118a80 00000000 /var/run/.inetd.uds --- Leaving the first wrapper up, I ran a couple other tests and then started a second wrapper. In that state here is what I get from netstat: --- # netstat TCP: IPv4 Local Address Remote Address Swind Send-Q Rwind Recv-Q State -------------------- -------------------- ----- ------ ----- ------ ----------- localhost.63661 localhost.63660 49152 0 49152 0 TIME_WAIT localhost.31001 localhost.32001 49170 0 49152 0 TIME_WAIT localhost.63667 localhost.63666 49152 0 49152 0 TIME_WAIT localhost.31002 localhost.32001 49170 0 49152 0 TIME_WAIT localhost.63670 localhost.63669 49152 0 49152 0 TIME_WAIT localhost.31003 localhost.32001 49152 0 49152 0 ESTABLISHED localhost.32001 localhost.31003 49152 0 49170 0 ESTABLISHED solx86.ssh 10.24.115.41.63503 49640 47 49640 0 ESTABLISHED localhost.31000 localhost.32000 49152 0 49152 0 ESTABLISHED localhost.32000 localhost.31000 49152 0 49170 0 ESTABLISHED Active UNIX domain sockets Address Type Vnode Conn Local Addr Remote Addr fffffe853d5cdac0 stream-ord fffffe855a118a80 00000000 /var/run/.inetd.uds --- The first Wrapper is using the socket 31000 -> 32000 (JVM to Wrapper) and the reverse of the socket. The second Wrapper is using the socket 31003 -> 32001 (JVM to Wrapper) and the reverse of the socket. Neither of those are ranges, they each use 2 halves of the socket as expected. The TIME_WAIT ports are from the other tests I mentioned and will remain in that state for 2 minutes until the system decides that no more data could come in and closes the ports. netstat then reports this: --- # netstat TCP: IPv4 Local Address Remote Address Swind Send-Q Rwind Recv-Q State -------------------- -------------------- ----- ------ ----- ------ ----------- localhost.31003 localhost.32001 49152 0 49152 0 ESTABLISHED localhost.32001 localhost.31003 49152 0 49170 0 ESTABLISHED solx86.ssh 10.24.115.41.63503 49640 47 49640 0 ESTABLISHED localhost.31000 localhost.32000 49152 0 49152 0 ESTABLISHED localhost.32000 localhost.31000 49152 0 49170 0 ESTABLISHED Active UNIX domain sockets Address Type Vnode Conn Local Addr Remote Addr fffffe853d5cdac0 stream-ord fffffe855a118a80 00000000 /var/run/.inetd.uds --- This is all worked as I expected but is also within a single Zone. When I stop the two wrappers and immediately run netstat again, I see: --- # netstat TCP: IPv4 Local Address Remote Address Swind Send-Q Rwind Recv-Q State -------------------- -------------------- ----- ------ ----- ------ ----------- localhost.31003 localhost.32001 49170 0 49152 0 TIME_WAIT solx86.ssh 10.24.115.41.63503 49640 47 49640 0 ESTABLISHED localhost.31000 localhost.32000 49170 0 49152 0 TIME_WAIT Active UNIX domain sockets Address Type Vnode Conn Local Addr Remote Addr fffffe853d5cdac0 stream-ord fffffe855a118a80 00000000 /var/run/.inetd.uds --- So the JVM to Wrapper half of the socket remains in a locked state for the TIME_WAIT period. This is expected because the JVM was the connecting process and the Wrapper was the listener. I admit that I have little experience with Solaris Zones but will definitely look into this further. Any additional information you could provide would be helpful in getting this resolved. Cheers, Leif On Sat, May 16, 2009 at 4:10 AM, Santo74 <gds...@de...> wrote: > > First of all I want to apologise for waking up an old thread, but actually > the problem described in this thread still applies. > I say this because I am experiencing exactly the same behaviour as ahmadk72 > with our own java application, which uses the java service wrapper. > > These are the remarkable things that I experienced: > > 1) the service wrapper is reserving all ports between 31000 and 32000 by > default > -> I would expect that it looks for the first free port in this range and > allocate / reserve that one, but apparently it reserves the whole range !! > > 2) On most systems it's not a huge problem in that this port range is > probably available (most of the time) and therefore doesn't cause much > trouble. > However, a lot of companies don't like it that a single application is > occupying a range of 1000 ports > > 3) On Solaris 10 zones it's even worse because the port range appears to be > in use on ALL zones as soon as ONE zone is running a service wrapper based > application > (cfr the explanation of ahmadk72 below) > > The strangest part is that we can run multiple instances of other > applications that use a particular port on multiple zones without any > trouble at all. > E.g. a solaris host with 5 zones, all 5 running an IBM Tivoli Policy Server > instance using the same ports on all those zones is not a problem. > So why can other applications allocate a particular port for that particular > zone (i.e. independant), > while the service wrapper is allocating (reserving) its ports on all zones > at once (i.e. global) ?? > > 4) I know it's possible to make the port range smaller AND letting each > server or zone use another port range, > but this makes it very hard to package an application for deployment > > We are using java service wrapper v3.2.3 > Can someone please look into this and take the necessary actions where > required ? > > Thanks in advance, > > gds > > > ahmadk72 wrote: >> >> I have a problem that is perplexed me to no end. Even our UNIX admin is >> stumped, so this mailing list is a last resort. >> >> We have a third-party application that uses the Java Service Wrapper >> (v3.2.1). The application is installed on two different Zones in Solaris >> 10. One zone is called rhdam-dev and the other is called rhdam-tst. >> >> If i startup the rhdam-dev (DEV box) application, the Java service wrapper >> uses ports 31000 and 32000 for communicating to and listening from the >> JVM. Everything works fine, and I have no problems running the application >> as expected. >> >> Then recently we installed the application on the dam-tst (TEST box) >> application on another Solaris zone. When the wrapper starts up, I see >> the following error (logging output is set to DEBUG level) in the attached >> log file. >> >> From what I have been able to deciper, it is complaining about port 32000 >> already being in use. However, the port is not in use on the rhdam-tst >> zone. I can run a netstat -an command and see that there is nothing >> running on port 32000. >> >> The really weird part is that is I stop the wrapper service on the >> rhdam-dev zone, and try to startup the rhdam-tst instance, then the >> wrapper service starts successfully. >> >> For now I have been able to start both up by changing adding the >> wrapper.port.min and wrappper.port.max settings so the ports don't >> conflict between rhdam-dev and rhdam-tst. >> >> However, I need to know why this is happening. Has anyone seen this >> behavior? The ports are suppose to be independent on Solaris zone. Why >> is the Java Service wrapper socket complaining about the port being used >> in another zone. >> >> If anyone can help me solve this mystery that would be just great. >> >> Thanks >> >> Kashif http://www.nabble.com/file/p12904287/artesia-service-wrapper.log >> artesia-service-wrapper.log |
