Hi Andrés
responses inlined below.
glassfish_at_javadesktop.org wrote:
> Hi, Shreedhar
>
> Thanks for your reply. Yeah, I am mostly interested about the increased heap space of a 64-bit process. I'm not sure that the expected load will require a heap of more than the effective maximum of ~2.5-3 GB for a 32-bit JVM, but because of a messed up hardware sizing process, the production machine has 16 GB of RAM and it's difficult to justify the mismatch between used and available resources.
Lets see here : With a 4 GB process size limit per 32 bit JVM you could
have about 3 (to be safe) or 4 (to be valiant ;-) ) instances on this
machine. Assuming that the load would justify the use of 3-4 instances
on this machine, you could go for a clustered approach. While that would
not provide you with the horizontal scalability (given instances will be
on the same machine) - it does give you vertical scalability to ensure
machine resources are used optimally while process redundancy is achieved.
> We would also like to use GlassFish clustering to replicate live session data and for 1-stop application deployment between two nodes in an Active/Passive hot-standby cluster, but that is something we could skip for now.
>
Without knowing much about the app characteristics and number of users
to be supported by the app, I'd suggest the following.
While our LB-plugin does not support Active/Passive configuration (btw,
our LB plugin is not supported on AIX - another OS will have to be used
to front the AIX cluster with the LB plugin), we also do not recommend
going for that approach as that would make suboptimal use of clustered
processes that have to run in standby mode waiting for a failure to
occur doing nothing but taking away system memory and some small amounts
of CPU cycles. You are better off using an Active/Active approach that
makes use of LB policies such as round robin to ensure load is evenly
balanced and provides for rapid failover on occurence of a failure.
> Do you think we are on the safe side if we don't make use of clustering features or that ORB issue will hit us anyway?
Not sure about that - I would be very concerned to go into production
with an unsupported JDK level and with no help to have on hand to help
address issues at a time when services are expected to run smoothly. I
mean - that one day when things should not go wrong and do go wrong :-)
> The application is a regular J2EE 1.4 enterprise app with heavy use of JMS and GlassFish MQ, Web Services and a couple of Web applications.
>
> I am afraid we are not a supported customer. I'm not sure we if could apply since we are not the final customer but a software provider and as far as I know budget is not reserved for this within the project.
>
I am sure something can be worked out to your/your customer's
satisfaction - if you are interested, I can certainly put you in touch
with our Volume Sales team. It sure would not hurt to talk and then you
can decide on whether you like it and when you/your customer would like
to go for it.
hth
Shreedhar
> Thanks,
>
> -- Andrés
> [Message sent by forum member 'aromanos_avalon' ]
>
> http://forums.java.net/jive/thread.jspa?messageID=373462
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>