> We made a test, and in fact we can confirm, that after a download of 45 MB,
> Glassfish
>
> cracks up. We do not know why.
So what technology/API is involved in this download process ?.
On 22-Aug-2011, at 11:56 PM, forums_at_java.net wrote:
> Hi @all,
>
> first of all, thank you for your answers and kindly accept my apologies for
> having failed to find the right "sound".
>
> This was not to blame the Glassfish developer or to disgrace the Glassfish
> itself, it was in fact deep frustration
>
> coupled with the fact, that I have asked here a few months ago several
> questions in a very polite and friendly
>
> manner and they left unreplied.
>
>
>
> But lets go to the heart of the matter:
>
>
>
> As mentioned in my previous post, we use jFastCGI and found out, that
> incorporating environment variables from
>
> lighthttpd, jFastCGI can run with 1 process but with hundreds of child
> processes:
>
> export PHP_FCGI_CHILDREN="5"
> export PHP_FCGI_MAX_REQUESTS="1000"
>
> /opt/php-5.3.5-suhosin/bin/php-cgi -b 127.0.0.1:7777
>
>
>
> I did not made the jFastCGI available separately for each virtual host, but
> made it available globally.
>
> the jFastCGI libs reside in the ${glassfish_root}/libs and the parameters
> then set in default-web.xml
>
>
>
> the speed is tremendous and we could improve our speed serving php apps 2
> times comparing to apache2,
>
> even if apache, php and all what belongs to it was compiled with optimization
> for UltraSparc-IIIi architectures.
>
> With this implemtation we can host Drupal CMS, WordPress, xt/os Commerce and
> many other apps, but without
>
> rewrite engine.
>
> jFastCGI would be a big improvement, if the connection to php-cgi does not go
> over the localhost ip stack but
>
> could deal with a socket.
>
>
>
> anyway, I trust, that jFastCGI is not that what causes the problem as I could
> see the same behaviour if no cgi extension is enabled.
>
> Glassfish runs out of memory after a certain time, and this is an issue that
> should receive attention. The garbage collector and
>
> the heap should release memory after a certain time to keep the service up
> and running.
>
> The problem that Glassfish suddenly dies occurs when downloads are made.
>
> We are hosting and sponsoring the sunfreepacks.com repository and our
> visitors complain,
>
> that they are unable to download the solaris 11 nevada b130 DVD iso.
>
> We made a test, and in fact we can confirm, that after a download of 45 MB,
> Glassfish
>
> cracks up. We do not know why.
>
> With regards to the web administration panal, I am personally disappointed,
> that we have
>
> raised an issue more than 2 years ago, that on Sun Sparc architectures the
> webui-jsf-4.0.2.6.jar file is corrupt and
>
> after a start of the glassfish service the console can not be loaded. the
> workaround I utilized was to copy the particular
>
> file from an x86 architecture and it was then operational.
>
> we have the following in use:
>
> Java:
>
> Java(TM) SE Runtime Environment (build 1.6.0_25-b06)
> Java HotSpot(TM) Server VM (build 20.0-b11, mixed mode)
>
> GlassFish:
>
> Glassfish 3.2 b6
>
> I went deep into the matter with my investigation and I tried several
> original advises from Sun how to deal with java heap space
>
> and after long tries, the following parameters from domain.xml delayed the
> glassfish death for 2 days, but on peak times it still runs out
>
> of memory at least once per day:
>
> <jvm-options>-Xmn2g</jvm-options>
> <jvm-options>-Xss128k</jvm-options>
> <jvm-options>-XX:ParallelGCThreads=20</jvm-options>
> <jvm-options>-XX:+UseConcMarkSweepGC</jvm-options>
> <jvm-options>-XX:+UseParNewGC</jvm-options>
> <jvm-options>-XX:SurvivorRatio=8</jvm-options>
> <jvm-options>-XX:TargetSurvivorRatio=90</jvm-options>
> <jvm-options>-XX:MaxTenuringThreshold=31</jvm-options>
> <jvm-options>-XX:+AggressiveOpts</jvm-options>
> <jvm-options>-XX:PermSize=192m</jvm-options>
> <jvm-options>-XX:MaxPermSize=512m</jvm-options>
>
> this is the top command output for the particular java process:
>
> 20264 gfwebsrv 766 59 0 2381M 2176M sleep 94:24
> 0.40% java
> The behavior described is independend from the platform. it occurs on Sparc
> and x86 plattforms
>
> with Java 6 (version see above) or latest Java 7.
>
> I want to point out, that we would like to continue with hosting on Glassfish
> not only because of the speed.
>
> again my apologies for my rough words on my previous post, but I am sure,
> that you understand,
>
> that it is no fun if you get suddenly overrun with costumer complaints.
>
> Thank you,
>
> Best Regards.
>
>
>
>
> --
>
> [Message sent by forum member 'seagate']
>
> View Post: http://forums.java.net/node/835908
>
>