FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Java

 
 
LinkBack Thread Tools
 
Old 03-21-2012, 01:31 PM
Charles Plessy
 
Default New work on java-package

Le Tue, Mar 20, 2012 at 09:28:12PM +0100, Cédric Pineau a écrit :
> 2012/3/20 Barry Hawkins <barry@alltc.com>
>
> > I'll clone your github repo and take a look; is the original pkg-java SVN
> > repo available still? Getting an idea of the delta will help me calibrate.
> >
>
> I'm afraid no. It has been deleted :-/

Not completely

http://anonscm.debian.org/viewvc/pkg-java/trunk/java-package/?pathrev=15728

Have a nice day,

--
Charles Plessy
Tsurumi, Kanagawa, Japan


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120321143150.GA30848@falafel.plessy.net">http://lists.debian.org/20120321143150.GA30848@falafel.plessy.net
 
Old 03-21-2012, 01:59 PM
Barry Hawkins
 
Default New work on java-package

On 3/21/12 10:31 AM, Charles Plessy wrote:

Le Tue, Mar 20, 2012 at 09:28:12PM +0100, Cédric Pineau a écrit :

2012/3/20 Barry Hawkins<barry@alltc.com>


I'll clone your github repo and take a look; is the original pkg-java SVN
repo available still? Getting an idea of the delta will help me calibrate.



I'm afraid no. It has been deleted :-/


Not completely

http://anonscm.debian.org/viewvc/pkg-java/trunk/java-package/?pathrev=15728

Have a nice day,


Oh, sweet! Thanks man.

--
Barry Hawkins
All Things Computed
email: barry@alltc.com
twitter: barryhawkins
blog: http://barryhawkins.com/blog
site: http://alltc.com


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F69ECD3.2000006@alltc.com">http://lists.debian.org/4F69ECD3.2000006@alltc.com
 
Old 03-27-2012, 09:12 AM
Emmanuel Bourg
 
Default New work on java-package

Le 20/03/2012 12:41, Andrew Haley a écrit :

Comments like this are infuriating. I want to make OpenJDK
competitive, but I can't do anything with this because I don't know
what you're talking about. I can't reproduce the problem, so I can't
fix it. Is there anything more frustrating than being told there's
a problem, but not what it is? It's like something out of Kafka.


There are indeed issues with OpenJDK that do not exist with the Oracle
JRE. Here is an issue I reported recently:


Tomcat with authbind on OpenVZ throws "SocketException: Cannot allocate
memory" (works with sun-java6)

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659293

That's the only hurdle that prevents me from migrating my production
servers to OpenJDK (and the reason why I contributed some changes to
java-package).


Emmanuel Bourg
 
Old 03-28-2012, 05:38 PM
Andrew Haley
 
Default New work on java-package

On 03/27/2012 10:12 AM, Emmanuel Bourg wrote:
> Le 20/03/2012 12:41, Andrew Haley a écrit :
>> Comments like this are infuriating. I want to make OpenJDK
>> competitive, but I can't do anything with this because I don't know
>> what you're talking about. I can't reproduce the problem, so I can't
>> fix it. Is there anything more frustrating than being told there's
>> a problem, but not what it is? It's like something out of Kafka.
>
> There are indeed issues with OpenJDK that do not exist with the Oracle
> JRE. Here is an issue I reported recently:
>
> Tomcat with authbind on OpenVZ throws "SocketException: Cannot allocate
> memory" (works with sun-java6)
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659293
>
> That's the only hurdle that prevents me from migrating my production
> servers to OpenJDK (and the reason why I contributed some changes to
> java-package).

Right, that's an example of a comment that is actually useful.

That's going to be tricky to find. I presume that the message is
deceptive, and it's actually a permissions problem. If you run

strace -f -etrace=net java ...

you'll be able to see the bind call that fails, and we can take it
from there.

Andrew.


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F734C8F.80701@redhat.com">http://lists.debian.org/4F734C8F.80701@redhat.com
 
Old 03-28-2012, 10:50 PM
Emmanuel Bourg
 
Default New work on java-package

Le 28/03/2012 19:38, Andrew Haley a écrit :

If you run

strace -f -etrace=net java ...

you'll be able to see the bind call that fails, and we can take it
from there.


Thank you for the tip, I'll give it a try. I'm not familiar with strace,
"-etrace=net" seems to be rejected. The syntax bellow is accepted, is it
the right one?


strace -f -e trace=network java ...


Emmanuel Bourg


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F7395BA.3090808@apache.org">http://lists.debian.org/4F7395BA.3090808@apache.org
 
Old 03-29-2012, 09:50 AM
Andrew Haley
 
Default New work on java-package

On 03/28/2012 11:50 PM, Emmanuel Bourg wrote:
> Le 28/03/2012 19:38, Andrew Haley a écrit :
>> If you run
>>
>> strace -f -etrace=net java ...
>>
>> you'll be able to see the bind call that fails, and we can take it
>> from there.
>
> Thank you for the tip, I'll give it a try. I'm not familiar with strace,
> "-etrace=net" seems to be rejected. The syntax bellow is accepted, is it
> the right one?
>
> strace -f -e trace=network java ...

Yes.

Andrew.


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F743058.6060301@redhat.com">http://lists.debian.org/4F743058.6060301@redhat.com
 
Old 03-29-2012, 12:58 PM
Andrew Haley
 
Default New work on java-package

On 03/27/2012 10:12 AM, Emmanuel Bourg wrote:
> Le 20/03/2012 12:41, Andrew Haley a écrit :
>> Comments like this are infuriating. I want to make OpenJDK
>> competitive, but I can't do anything with this because I don't know
>> what you're talking about. I can't reproduce the problem, so I can't
>> fix it. Is there anything more frustrating than being told there's
>> a problem, but not what it is? It's like something out of Kafka.
>
> There are indeed issues with OpenJDK that do not exist with the Oracle
> JRE. Here is an issue I reported recently:
>
> Tomcat with authbind on OpenVZ throws "SocketException: Cannot allocate
> memory" (works with sun-java6)
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659293
>
> That's the only hurdle that prevents me from migrating my production
> servers to OpenJDK (and the reason why I contributed some changes to
> java-package).

I think the problem is in authbind: it only supports IPv4.

Try this:

$ authbind --depth 2 java -Djava.net.preferIPv4Stack=true ListenTest
ServerSocket[addr=localhost/127.0.0.1,port=0,localport=80]

Andrew.

import java.net.*;

public class ListenTest {
public static void main(String[] args)
throws Throwable {
ServerSocket s = new ServerSocket(80, 0, InetAddress.getByName("localhost"));
System.out.println(s);
}
}


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F745C75.1020705@redhat.com">http://lists.debian.org/4F745C75.1020705@redhat.com
 
Old 03-31-2012, 07:46 AM
Emmanuel Bourg
 
Default New work on java-package

Le 29/03/2012 14:58, Andrew Haley a écrit :

I think the problem is in authbind: it only supports IPv4.


OpenVZ comes into the equation too. The bind operation fails with the
message "Cannot allocate memory". This may be related to the way
authbind forks the process.


OpenVZ has the unpleasant behavior to assume that the memory allocated
to a process a totally used. When Tomcat is started with -Xmx512M, htop
displays a java process using around 500-600M. If the system had less
than 500M of memory available, the JVM would fail to start with a memory
allocation error. This doesn't happen outside an OpenVZ container.


While reading the authbind documentation I saw it was doing some fork
tricks behind the scene. Maybe the forked process can't allocate its
memory due to OpenVZ and quits?





Try this:

$ authbind --depth 2 java -Djava.net.preferIPv4Stack=true ListenTest
ServerSocket[addr=localhost/127.0.0.1,port=0,localport=80]


I tried this example and it failed with sun-java and openjdk. The
following error is returned:


Exception in thread "main" java.net.SocketException: No such file or
directory

at java.net.PlainSocketImpl.socketBind(Native Method)
at
java.net.AbstractPlainSocketImpl.bind(AbstractPlai nSocketImpl.java:353)

at java.net.ServerSocket.bind(ServerSocket.java:336)
at java.net.ServerSocket.<init>(ServerSocket.java:202 )
at ListenTest.main(ListenTest.java:6)


I changed your class to bind to any local address (with new
ServerSocket(80)) and this time it worked fine with sun-java and openjdk.


Since I suspect a memory allocation issue I played a bit with the
maximum heap size. With -Xmx1700M it worked with sun-java but failed
with openjdk. But at 1800M it also failed with sun-java. I refined the
thresholds and found the upper limit for sun-java (1707M) and openjdk
(1640M). At this time the system had about 3650M of free memory. That
seems to indicate that the program needs twice the maximum heap size to
start properly.


Without authbind the thresholds are higher, the program runs up to 2678M
with sun-java and 2616M with openjdk.


So this issue might be simply due to a different memory usage of the
OpenJDK JVM vs the Sun JVM. When I adjusted the heap size of Tomcat to
the maximum possible I didn't realize it was about half of the available
memory on the system. And when I switched to OpenJDK I've been bitten by
the slightly increased memory usage.


That's probably one more good reason to replace authbind with iptable in
my case. The other reason being the lack of IPv6 support.



Emmanuel Bourg
 
Old 04-02-2012, 11:29 PM
Emmanuel Bourg
 
Default New work on java-package

Le 31/03/2012 21:10, Andrew Haley a écrit :


While reading the authbind documentation I saw it was doing some fork
tricks behind the scene. Maybe the forked process can't allocate its
memory due to OpenVZ and quits?


Hold on, do you see this problem outside OpenVZ? I know that there is
a virtualization container that doesn't support memory overcommit, but
I can't remember its name. If so, that's a big problem; Java's GC
strategy really needs overcommit to work.


This problem doesn't happen outside the OpenVZ container.

OpenVZ has a setting to fiddle with memory overcommit (the privvmpages
parameter), but I'm not sure it'll work with a 32 bits container and 4GB
assigned, the limit can't be extended.


If the JVM could allocate gradually the memory as the heap grows that
would help, but I guess that's not possible.




That's probably one more good reason to replace authbind with iptable in
my case. The other reason being the lack of IPv6 support.


Right. I expect that every Java VM will move to IPv6, so authbind
would stop working everywhere.


The sad thing is there is no good alternative yet. I realized today that
ip6table doesn't support port redirection (because it works with NAT and
NAT is discouraged with IPv6). The only solution left is to put a
reverse proxy in front of Tomcat.


Emmanuel Bourg
 
Old 04-03-2012, 09:25 AM
Andrew Haley
 
Default New work on java-package

On 04/03/2012 12:29 AM, Emmanuel Bourg wrote:
> Le 31/03/2012 21:10, Andrew Haley a écrit :
>
>>> While reading the authbind documentation I saw it was doing some fork
>>> tricks behind the scene. Maybe the forked process can't allocate its
>>> memory due to OpenVZ and quits?
>>
>> Hold on, do you see this problem outside OpenVZ? I know that there is
>> a virtualization container that doesn't support memory overcommit, but
>> I can't remember its name. If so, that's a big problem; Java's GC
>> strategy really needs overcommit to work.
>
> This problem doesn't happen outside the OpenVZ container.
>
> OpenVZ has a setting to fiddle with memory overcommit (the privvmpages
> parameter), but I'm not sure it'll work with a 32 bits container and 4GB
> assigned, the limit can't be extended.
>
> If the JVM could allocate gradually the memory as the heap grows that
> would help, but I guess that's not possible.

Not really. To be frank, overcommit is such a basic Linux feature that
any container which doesn't fully support it is just broken.

>>> That's probably one more good reason to replace authbind with iptable in
>>> my case. The other reason being the lack of IPv6 support.
>>
>> Right. I expect that every Java VM will move to IPv6, so authbind
>> would stop working everywhere.
>
> The sad thing is there is no good alternative yet. I realized today that
> ip6table doesn't support port redirection (because it works with NAT and
> NAT is discouraged with IPv6). The only solution left is to put a
> reverse proxy in front of Tomcat.

It doesn't look difficult to make authbind work with IPv6. I don't know
why no-one has yet done it.

Andrew.


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F7AC21D.6030008@redhat.com">http://lists.debian.org/4F7AC21D.6030008@redhat.com
 

Thread Tools




All times are GMT. The time now is 03:51 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org