Re: [Resin-interest] Resin cluster failure with a singlenoderunning out of heap space

[Mike Wynholds]

nope, no thread dump unfortunately.  the whole cluster had been
restarted by the IT department of my client before I came in to help
figure out what had happened.  I will tell them to get a thread dump if
it happens again.

I don't think the JVM itself was frozen.  but I am not sure.

in the meantime, I think we will try increasing the heap size and the
memory-free-min value.

..mike..

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson
Sent: Monday, March 10, 2008 4:42 PM
To: General Discussion for the Resin application server
Subject: Re: [Resin-interest] Resin cluster failure with a
singlenoderunning out of heap space


On Mar 10, 2008, at 3:57 PM, Mike Wynholds wrote:

> Hmmm... we do have a  setting of 1MB (Scott asked  
> about
> that just before this email).  So then how would Resin still get an  
> OOM
> error?  Is there a thread in the server that watches the heap space?
> Because we do a lot of in-JVM image manipulation, which takes up a LOT
> of memory and quite quickly.  So if it is a timing issue, it's  
> possible
> that the heap-watcher doesn't have a chance to act quickly enough.

It's the main thread and checked every 10 seconds.  So it's possible  
that using a lot of memory could run
by it.  Still, that thread should detect the problem after 10 seconds  
and force a restart.

Although, memory checking isn't exact.  It's even possible the  
original failure freed up memory between checks, but that's not likely.

Did you happen to get a thread dump or was the JVM itself frozen?  JVM  
freezes are hard to deal with.

-- Scott

>
>
> ..mike..
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Sam
> Sent: Monday, March 10, 2008 3:38 PM
> To: General Discussion for the Resin application server
> Subject: Re: [Resin-interest] Resin cluster failure with a single
> noderunning out of heap space
>
>> We are currently looking at our watchdog process config to see why it
>> did not auto-restart Resin.  I think we didn't give enough memory
> buffer
>> for the watchdog to detect a needed restart, and our app lost
>> responsiveness before the watchdog could restart it.  But that's just
> a
>> theory.
>
> The memory low detection happens within the server itself.  If the
> server itself detects that the memory is about to be exhausted, it
> exits.  The watchdog then notices that the server did not exit  
> cleanly,
> and starts a new server to replace it.
>
> -- Sam
>
>
>
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest
>
>
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Resin cluster failure with a single noderunning out of heap space

[Mike Wynholds]

Hmmm... we do have a  setting of 1MB (Scott asked about
that just before this email).  So then how would Resin still get an OOM
error?  Is there a thread in the server that watches the heap space?
Because we do a lot of in-JVM image manipulation, which takes up a LOT
of memory and quite quickly.  So if it is a timing issue, it's possible
that the heap-watcher doesn't have a chance to act quickly enough.

..mike..

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sam
Sent: Monday, March 10, 2008 3:38 PM
To: General Discussion for the Resin application server
Subject: Re: [Resin-interest] Resin cluster failure with a single
noderunning out of heap space

> We are currently looking at our watchdog process config to see why it
> did not auto-restart Resin.  I think we didn't give enough memory
buffer
> for the watchdog to detect a needed restart, and our app lost
> responsiveness before the watchdog could restart it.  But that's just
a
> theory.

The memory low detection happens within the server itself.  If the
server itself detects that the memory is about to be exhausted, it
exits.  The watchdog then notices that the server did not exit cleanly,
and starts a new server to replace it.

-- Sam



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] Resin cluster failure with a single node running out of heap space

[Mike Wynholds]

Scott and others-

 

My client has a five-node Resin Pro cluster, each running version 3.1.2.

 

Today one of the nodes experienced an OutOfMemoryException which did not
bring Resin down but seemed to have put it in a completely unresponsive
state.

 

With 10 minutes or so of that happening, the other four servers stop
responding as well.  Looking at their logs shows that they are
continuously getting socket timeouts while trying to communicate with
the first server for session clustering.  (Stack trace below).

 

To be fair, this is not the only exception being thrown.  We also see
our distributed EhCache system unsuccessfully trying to replicate
itself.  And we *also* see the occasional Hessian exception happening
(also below).  Ultimately the server just gets so bogged down, it seems,
that it needs to be restarted.

 

So my question is this:

Assuming a Resin node runs out of memory, is there a way for other Resin
nodes to detect that and take the same action as if the node was
actually down?  I'm not sure this is really a bug, but it is probably a
good super-edge-case scenario worth thinking about.

 

We are currently looking at our watchdog process config to see why it
did not auto-restart Resin.  I think we didn't give enough memory buffer
for the watchdog to detect a needed restart, and our app lost
responsiveness before the watchdog could restart it.  But that's just a
theory.

 

I am interested in feedback from Scott and other Caucho developers about
this issue, as well as other Resin users who may have experienced issues
like this before and have any thoughts or suggestions on the matter.

 

Thanks.

..mike..

 

--- Socket Timeout stack trace (partial) ---

[14:47:10.389] java.net.SocketTimeoutException: Read timed out

[14:47:10.389]  at java.net.SocketInputStream.socketRead0(Native Method)

[14:47:10.389]  at
java.net.SocketInputStream.read(SocketInputStream.java:129)

[14:47:10.389]  at com.caucho.vfs.TcpStream.read(TcpStream.java:163)

[14:47:10.389]  at
com.caucho.vfs.ReadStream.readBuffer(ReadStream.java:1001)

[14:47:10.389]  at com.caucho.vfs.ReadStream.read(ReadStream.java:306)

[14:47:10.389]  at
com.caucho.server.cluster.ClusterStore.updateAccess(ClusterStore.java:85
6)

[14:47:10.389]  at
com.caucho.server.cluster.ClusterStore.accessServer(ClusterStore.java:82
3)

[14:47:10.389]  at
com.caucho.server.cluster.ClusterStore.accessImpl(ClusterStore.java:804)

[14:47:10.389]  at
com.caucho.server.cluster.ClusterObject.access(ClusterObject.java:337)

[14:47:10.389]  at
com.caucho.server.session.SessionImpl.setAccess(SessionImpl.java:839)

[14:47:10.389]  at
com.caucho.server.session.SessionManager.load(SessionManager.java:1477)

[14:47:10.389]  at
com.caucho.server.session.SessionManager.getSession(SessionManager.java:
1335)

[14:47:10.389]  at
com.caucho.server.connection.AbstractHttpRequest.createSession(AbstractH
ttpRequest.java:1455)

[14:47:10.389]  at
com.caucho.server.connection.AbstractHttpRequest.getSession(AbstractHttp
Request.java:1270)

[14:47:10.389]  at
net.sf.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilte
r(HttpSessionContextIntegrationFilter.java:172)

[14:47:10.389]  at
net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(F
ilterChainProxy.java:303)

[14:47:10.389]  at
net.sf.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.jav
a:173)

[14:47:10.389]  at
net.sf.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.j
ava:125)

[14:47:10.389]  at
com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.
java:73)

 

--- Hessian failure stack trace ---

[14:15:00.065] Caused by:
org.springframework.web.util.NestedServletException: Hessian skeleton
invocation failed; nested exception is java.io.IOException: expected 'c'
in hessian input at -1

[14:15:00.065]  at
org.springframework.remoting.caucho.HessianServiceExporter.handleRequest
(HessianServiceExporter.java:150)

[14:15:00.065]  at
org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter.handle(Htt
pRequestHandlerAdapter.java:49)

[14:15:00.065]  at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherS
ervlet.java:857)

[14:15:00.065]  at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherSe
rvlet.java:792)

[14:15:00.065]  at
org.springframework.web.servlet.FrameworkServlet.processRequest(Framewor
kServlet.java:475)

[14:15:00.065]  at
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet
.java:440)

[14:15:00.065]  at
javax.servlet.http.HttpServlet.service(HttpServlet.java:153)

[14:15:00.065]  at
javax.servlet.http.HttpServlet.service(HttpServlet.java:91)

[14:15:00.065]  at
com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChai
n.java:103)

[14:15:00.065]  at
net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(F
ilterChainProxy.java:292)

[14:15:00.065]  at
taylor.tops.security.UserTrackerFilter.doFilter(UserTrackerFilter.java:2
7)

[14:15

Re: [Resin-interest] Forwarding rewrite path location

[Mike Wynholds]

Is /somepath actually the context path for the web app?  Or is it just
part of the path info?  If it is the web app context path, then you
cannot forward outside that context.  That request dispatcher would not
know anything about resources outside of its context.

 

You would probably have to send a browser redirect, which can be a
relative path too (I think).

 

Now... if /somepath is really just path info, then this seems to be a
bug.

 

..mike..

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ron Pitts
Sent: Thursday, January 24, 2008 2:43 AM
To: resin-interest@caucho.com
Subject: [Resin-interest] Forwarding rewrite path location

 

This has been bugging me for awhile so here it goes 

 

I'm currently displaying a jsp page located at /somepath/somefile.jsp 

 

I want to forward the request to a jsp file in the root directory, e.g.
/confirm.jsp, however after forwarding the path location is still
/somepath/, any ideas how to set the path location as well? 

 

HttpServletRequest request,
HttpServletResponse response,

RequestDispatcher disp;

 

  disp = request.getRequestDispatcher("/confirm.jsp");
  disp.forward(request, response);

 

 

thanks 

 

___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] General question to Resin

[Mike Wynholds]

this would still be considered a web application.  you would build your
services as java classes and expose them via Hessian.  the way that
happens internally is via a Hessian servlet.  that will probably be your
only servlet in the web application.

you can then tune Resin specifically for your web app.  for example, you
can turn off session handling completely (I think).

..mike..

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Timothy Marc
Sent: Saturday, November 17, 2007 1:41 PM
To: resin-interest@caucho.com
Subject: [Resin-interest] General question to Resin

Hi everybody,

i'm very new to application server behaviour, but i'm impressed of the 
combination from Resin and Hessian. This seems to be a quiet good idea 
of implementing web services.

My question is the following: I don't want to implement a 
Webapplication, but want offer a web service interface for my standalone

application. Therefore, i want to use hessian as web services protocoll 
and the resin app server. I didn't need session management or something 
else, and i want, that my application is only started one time for 
unbounded web service queries. Is this possible with resin app server?

Thanks for answering.
--Timothy


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] What are possible reasons for watchdog process to restart app server?

[Mike Wynholds]

Hi guys-

 

Does anyone know the (ideally exhaustive) list of the reasons why the
watchdog process would restart the app server?

The main one that I am aware of is the Java heap space hitting the high
water mark.

What are the others (if any)?

 

..mike..

 

.

Michael Wynholds

President

Carbon Five, Inc.

310 821 7125 x13

[EMAIL PROTECTED]

 

___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Unable to pass request parameter to custom taglibwith Resin 3.1.3

[Mike Wynholds]

I am not sure exactly why it stopped working, but I have noticed that
sometimes Resin, over time, becomes more and more spec-compliant.  this
often means things that "worked" in the past, even though they were
against the spec, stop working.

 

check your .tld file to make sure that the "moduleName" parameter is set
to rtexpr="true".

 

also, you use EL to get the request parameter instead of scriptlets,
like this:

 



 

(no need for the request.getParameter(...))

 

..mike..

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ambar Hegde
Sent: Tuesday, October 09, 2007 6:29 AM
To: General Discussion for the Resin application server
Subject: [Resin-interest] Unable to pass request parameter to custom
taglibwith Resin 3.1.3

 

I'm having trouble trying to pass a request parameter to a custom taglib
by setting an attribute.

 

The jsp looks like this:

 

<%

String moduleName =request.getParameter("moduleName");

%>

 



 

In the loadFav class, 

 

public void setModuleName(String moduleName) {
this.moduleName = moduleName;   

}

 

 public int doStartTag() throws JspException {
AppsLogger.debug("Entered LoadDefaultFavSearchTag.doStartTag():
"+getModuleName());

}

The getModuleName method is returning the literal string
"<%=moduleName%>" (minus quotes).

 

The moduleName parameter was being passed along fine when I was using
Resin 2.1.10. However I'm seeing this behaviour

in both Resin 3.1.2 and Resin 3.1.3. Is this a bug or am I doing
something wrong?

 

TIA,

 

-Ambar

 

 

 

___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Changing the default page encoding / characterset for JSP pages

[Mike Wynholds]

For the response your choices are:
1. Set it at the JSP level
2. Set it at the servlet level
3. Set it at the application level (via a Filter)

it all depends on your app, and at what granularity you know the content
type of the responses.  you can configure a filter easily via URL
mappings, which has identical power to the web.xml configuration (that
seems to not handle content types, just charsets).  or if you use ACEGI
for security, they have a more powerful matching engine for filters that
can accept Ant-style matches, or regular expressions.

I would think that often times the granularity of content type vs.
charset would be different.  however, once you get down to the JSP
level, since it's one response, you can set them together.

..mike..

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joe Dane
Sent: Wednesday, October 03, 2007 9:47 AM
To: General Discussion for the Resin application server
Subject: Re: [Resin-interest] Changing the default page encoding /
characterset for JSP pages

Beats me.  You're right that I was wrong in saying you could put the  
content type in that element, but it seems to me that the encoding  
should work.

So this might be a resin bug.  Encoding issues can be troublesome,  
though, since there're so many places from which it can be set.

I guess another solution might be to write a Filter which sets the  
content-type and encoding on all responses.


On Oct 3, 2007, at 5:20 AM, Keith Fetterman wrote:

> Hi Joe,
>
> Thanks for sending this.  I tried it and it didn't do what I need.  I
> discovered that you can only specify the character set in the
>  tag.  You can't specify the content type.  So I
> specified "UTF-8".  When I look at the response headers sent by Resin,
> the character set is not included.
>
> So far, the only way that I have discovered to communicate to the
> browser the character endcoding is by explicitly setting the content
> type via
>
>   <%@ page contentType="text/html; charset=UTF-8" %>
>
> Using the JSP directive:
>
> <%@ page pageEncoding="UTF-8" %>
>
> and the web.xml tags that you mentioned in your email do not cause  
> resin
> to modify any response headers to include the page encoding or  
> character
> set. I wonder what the purpose of the pageEncoding directives are for.
>
> Or is it that Resin isn't working correctly.
>
> What I need are tags similar to what you specified by will set the
> default content type for all JSP pages in a Web app.
>
> I had also tried the following tags in web.xml:
>
> 
>
>  en_US
>  UTF-8
>
> 
>
> But they didn't work either.
>
> Joe, any chance you see something that I have missed?
>
> Thanks a lot.
>
> Keith
>
>
>
>
>
>
>
> Joe Dane wrote:
>> you can do this in the deployment descriptor, or presumably in the
>> resin config file as well.  in the deployment descriptor, it'd look
>> something like
>>
>>   
>> 
>>   *.jsp
>>   text/html; charset=UTF-8
>> 
>>   
>>
>> that's from memory, but there's certainly something about this in the
>> JSP2.0 spec.
>>
>> On Oct 2, 2007, at 1:48 PM, Keith Fetterman wrote:
>>
>>> Hi,
>>>
>>> We want to convert the default page encoding for JSP pages to UTF-8.
>>>
>>> Is there a way to change the default page encoding for JSP pages in
>>> the
>>> resin.conf or web.xml files for a Web application?
>>>
>>> We have successfully done this for a specific page if we include the
>>> following directive in the JSP page:
>>>
>>> <%@ page contentType="text/html; charset=UTF-8" %>
>>>
>>> I was wondering if there is a way that can do this in the resin
>>> configuration so we don't have to do it for each JSP page.
>>>
>>> Thanks,
>>>
>>> Keith
>>>
>>>
>>> -- 
>>> -
>>> Keith Fetterman  206-780-5670
>>> Mariner Supply, Inc. [EMAIL PROTECTED]
>>> http://www.go2marine.com
>>>
>>>
>>> ___
>>> resin-interest mailing list
>>> resin-interest@caucho.com
>>> http://maillist.caucho.com/mailman/listinfo/resin-interest
>>
>
> -- 
> -
> Keith Fetterman  206-780-5670
> Mariner Supply, Inc. [EMAIL PROTECTED]
> http://www.go2marine.com
>
>
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest

-- 

joe





___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] server B in cluster validates against server A properties in resin.conf (3.1.2)

[Mike Wynholds]

I have the following config in my resin.conf:

 



  

  



  jks   

  c:/Documents and
Settings/mike/.keystore   

  password



  



 



  



 

I know it's weird to have one server with ssl enable and one without,
but it was really just a development thing.  anyway, the resin.conf
files are identical among app-a and app-b.  but.. when I start up app-b,
it errors out because it cannot find the .keystore file, even though
that is specific to app-a.

 

this is basically a bug report, and I should probably figure out how to
put it directly in to the bug tracker, but laziness takes over once
again...

 

..mike..

 

 

___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] auto reloading the class changed without reloadingthe context!

[Mike Wynholds]

that's not a Resin thing.  that has to do with the java debugger's
ability to reload classes.  you are right about the fact that it can
only reload classes where method bodies have changed, not method or
class structure.

 

I don't know what documentation is available, but if it exists you will
find it on Sun's java site, http://java.sun.com  

 

..mike..

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of ??
Sent: Wednesday, September 19, 2007 4:32 AM
To: resin-interest@caucho.com
Subject: [Resin-interest] auto reloading the class changed without
reloadingthe context!

 

I have just tried resin 3.2.10 and find a very interesting thing.

WhenI modify the java source code, resin will compile it and reload it
automatically.

and sometimes it reloads the web context and sometims not(not reloading
the context will speed up the development).

I just find one rule to avoid reloading context.It's keeping the class
structure and only changing the method content.

So are there any documents for this issue?

 

 

___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Runtime creation of database connections pools

[Mike Wynholds]

at lost of people like c3po - http://sourceforge.net/projects/c3p0
dbcp is also good - http://commons.apache.org/dbcp/

I think they both will let you pool things in code.
.m.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eric Kreiser
Sent: Friday, September 14, 2007 1:11 PM
To: Resin Group
Subject: [Resin-interest] Runtime creation of database connections pools

Does resin support this... and if so... can someone point me in the 
right direction.  If not... does anyone recommend another database 
connection pooling api which does support this?

I have found myself in a situation where I need to create my database 
connection pools in code at runtime not based on the resin.conf.  I want

to be able to pool my connections, but there are too many potential 
database/user combinations to manage configuring all of them in the 
resin.conf.

thanks in advance for any help you are able to supply.


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] code too large for try statement error!

[Mike Wynholds]

If you have a really big JSP file, and you get this problem, you can try
breaking the JSP file up in to several smaller .jsp or .tag files, and
creating a hierarchy of files.

This will not only fix your problem, but if done correctly will result
in a much better JSP page architecture.

We really like using jsp tagfiles to break up our jsps.  they are new to
JSP 2.0 (although that's not really very new anymore).  they essentially
allow you to create a custom jsp tag in JSP instead of in Java.

the alternative is just to break out chunks of your jsp code in to a
different .jsp file and use jsp:import to include it in the original jsp
file.  a less powerful approach, but it will fix your problem.

..mike..

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gary Zhu
Sent: Saturday, September 08, 2007 11:28 PM
To: General Discussion for the Resin application server
Subject: Re: [Resin-interest] code too large for try statement error!

To solve your problem, make sure that your JSP compiled/generated Java
files do not have try blocks and Java methods too large, for (rough)
example, exceeding 10,000 lines. It's just the limitation of try blocks
and java methods, the size of java file has no limit.

When a java file is compiled into .class file, there is a limitation in
"JVM spec" that try block represented in the java byte code cannot
exceed 64K. Since the largest try block could be the entire Java method
(a method throws exceptions),  this 64K limitation is also
(conveniently) imposed on each Java method.


From: [EMAIL PROTECTED]
[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
[EMAIL PROTECTED]
Sent: Saturday, September 08, 2007 9:43 AM
To: resin-interest@caucho.com
Subject: [Resin-interest] code too large for try statement error!

What should I do to fix the jsp page when resin server ran into the
following errors?

code too large for try statement

-Henry


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Resin / Apache load balancing withcustomResinserver weighting (for data segmentation purposes)

[Mike Wynholds]

yeah, I think that will be cool.
is there a timeline for 3.1.3 release?

..mike..

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson
Sent: Wednesday, August 29, 2007 4:32 PM
To: General Discussion for the Resin application server
Subject: Re: [Resin-interest] Resin / Apache load balancing 
withcustomResinserver weighting (for data segmentation purposes)


On Aug 29, 2007, at 3:29 PM, Mike Wynholds wrote:

> i think that I could solve my issue more elegantly with the code  
> you are suggesting.  it would allow me to essentially keep it ALL  
> on the server side, as long as I make sure my session's first hit  
> is light, by which I mean not loading up my caches (which is the  
> main reason I want to segment the data in the first place).
>
> the project selection can indeed happen before I have a session.
>
> does resin have this capability now, or are you proposing adding it?

I'm adding it to 3.1.3.  The attribute looks like:

   request.setAttribute("caucho.session-server-id", "app-a");

Or

   request.setAttribute("caucho.session-server-id", new Integer(0));

-- Scott

>
> ..mike..
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:resin-interest- 
> [EMAIL PROTECTED] On Behalf Of Scott Ferguson
> Sent: Wednesday, August 29, 2007 12:07 PM
> To: General Discussion for the Resin application server
> Subject: Re: [Resin-interest] Resin / Apache load balancing with  
> customResinserver weighting (for data segmentation purposes)
>
>
> On Jul 25, 2007, at 9:30 AM, Mike Wynholds wrote:
>
>> well, I did come up with a solution, however it is Resin-specific
>> and requires some client-side code at all login points (ie: there
>> is a customer login implemented in Flex as well as an
>> administrative login implemented in HTML).
>>
>> I set up apache for the web-tier and resin as the app-tier,
>> connected by mod_caucho.  I have an idea of the overall systems
>> architecture, but for this discussion we just assume that there is
>> some farm of apache servers that are available under a single URL.
>>
>> Resin offers a way to specify a preferred app-tier server in the
>> cluster by accessing the web-tier and passing in a pre-fab
>> jsessionid, utilizing the Resin-specific algorithm of starting it
>> with an "a", "b", "c", etc.  for example, if I wanted the second
>> server listed in the cluster in resin.conf, I request the following:
>>
>> http://www.myserver.com;jsessionid=b
>
> I'm finally getting a chance to look at this.
>
> Does the project selection occur before you have a session?
>
> In other words, would something like the following work?
>
>request.setAttribute("caucho.session-server", "b");
>
>session = request.getSession(true);
>
> If the session is new, then it will be assigned an ownership of
> server "b", even if that's a totally different machine than the
> current server.  The next request will be directed to server "b",
> which will be the same as the pinned data.
>
> -- Scott
>
>
>>
>> now, if there is no current session, mod_caucho will do its best to
>> point the web-tier to the second server in the app-tier cluster.
>> it will still, however, fall back to the other clustered servers if
>> B is down.  this is exactly what I want.
>>
>> the downside to this solution is that my client code has to do some
>> work to make this happen.  as a user logs in, the client must a)
>> clear the session, and b) figure out the appropriate URL (ie:
>> jsessionid prefix) to use and switcheroo it in as the user logs in,
>> based on the project number entered in to the login form.
>>
>> I actually have a server-side servlet that does the logic, so I
>> just need a way to call it easily.  basically, in Flex I just use
>> the standard Flash mx:HTTPService, which is easy, and in HTML I
>> just use AJAX.  so it's not too bad, but it would be nice if it was
>> even more "behind the scenes".  it can't be 100% behind the scenes,
>> tho.  I would at least need a convention of putting the project
>> number in the session or in the login URL under a specific name, or
>> something like that, even if I could do custom load balancing login
>> on a hardware load-balancer.
>>
>> anyway, so far so good.
>>
>> any suggestions for improvements would be definitely appreciated!
>>
>> ..mike..
>>
>> .
>> Michael Wynholds
>> President
>> Carbon Five, Inc.
>> 310 821 7125 x13
>> [EMAIL PROTECT

Re: [Resin-interest] Resin / Apache load balancing with customResinserver weighting (for data segmentation purposes)

[Mike Wynholds]

i think that I could solve my issue more elegantly with the code you are 
suggesting.  it would allow me to essentially keep it ALL on the server side, 
as long as I make sure my session's first hit is light, by which I mean not 
loading up my caches (which is the main reason I want to segment the data in 
the first place).

the project selection can indeed happen before I have a session.

does resin have this capability now, or are you proposing adding it?

..mike..

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson
Sent: Wednesday, August 29, 2007 12:07 PM
To: General Discussion for the Resin application server
Subject: Re: [Resin-interest] Resin / Apache load balancing with 
customResinserver weighting (for data segmentation purposes)


On Jul 25, 2007, at 9:30 AM, Mike Wynholds wrote:

> well, I did come up with a solution, however it is Resin-specific  
> and requires some client-side code at all login points (ie: there  
> is a customer login implemented in Flex as well as an  
> administrative login implemented in HTML).
>
> I set up apache for the web-tier and resin as the app-tier,  
> connected by mod_caucho.  I have an idea of the overall systems  
> architecture, but for this discussion we just assume that there is  
> some farm of apache servers that are available under a single URL.
>
> Resin offers a way to specify a preferred app-tier server in the  
> cluster by accessing the web-tier and passing in a pre-fab  
> jsessionid, utilizing the Resin-specific algorithm of starting it  
> with an "a", "b", "c", etc.  for example, if I wanted the second  
> server listed in the cluster in resin.conf, I request the following:
>
> http://www.myserver.com;jsessionid=b

I'm finally getting a chance to look at this.

Does the project selection occur before you have a session?

In other words, would something like the following work?

   request.setAttribute("caucho.session-server", "b");

   session = request.getSession(true);

If the session is new, then it will be assigned an ownership of  
server "b", even if that's a totally different machine than the  
current server.  The next request will be directed to server "b",  
which will be the same as the pinned data.

-- Scott


>
> now, if there is no current session, mod_caucho will do its best to  
> point the web-tier to the second server in the app-tier cluster.   
> it will still, however, fall back to the other clustered servers if  
> B is down.  this is exactly what I want.
>
> the downside to this solution is that my client code has to do some  
> work to make this happen.  as a user logs in, the client must a)  
> clear the session, and b) figure out the appropriate URL (ie:  
> jsessionid prefix) to use and switcheroo it in as the user logs in,  
> based on the project number entered in to the login form.
>
> I actually have a server-side servlet that does the logic, so I  
> just need a way to call it easily.  basically, in Flex I just use  
> the standard Flash mx:HTTPService, which is easy, and in HTML I  
> just use AJAX.  so it's not too bad, but it would be nice if it was  
> even more "behind the scenes".  it can't be 100% behind the scenes,  
> tho.  I would at least need a convention of putting the project  
> number in the session or in the login URL under a specific name, or  
> something like that, even if I could do custom load balancing login  
> on a hardware load-balancer.
>
> anyway, so far so good.
>
> any suggestions for improvements would be definitely appreciated!
>
> ..mike..
>
> .
> Michael Wynholds
> President
> Carbon Five, Inc.
> 310 821 7125 x13
> [EMAIL PROTECTED]
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:resin-interest- 
> [EMAIL PROTECTED] On Behalf Of Jay Ballinger
> Sent: Wednesday, July 25, 2007 8:43 AM
> To: General Discussion for the Resin application server
> Subject: Re: [Resin-interest] Resin / Apache load balancing with  
> customResin server weighting (for data segmentation purposes)
>
> Mike,
>
> This sounds like a perfect use for a hardware load-balancer. A
> hardware load-balancer can create the affinity for a particular server
> much like you describe - except for the choosing of a server based on
> your algorithm, that is.
>
> Most hardware solutions implement some sort of persistence feature
> where, once a load-balancing decision has been made by the device, it
> will try to persist that same 'user' to that same server for a
> configurable amount of time. We use this to keep a user's access and
> application log on one server versus having to hunt around all the
> servers to 

Re: [Resin-interest] Start up problem

[Mike Wynholds]

You can set the watchdog-port for each server you start up, whether you
use a single resin.conf for a cluster of servers on the same machine, or
multiple resin.confs.  6600 is just the default watchdog port.  that is
how you start up multiple resin instances on the same machine.

 

as for the bug, binding the watchdog process to the configured port
(6600 by default) of the localhost seems the right thing to do.  it's
just RedHat OSes with JDK 5 that have this bug.  JDK 6 is fixed I think,
and it has been back ported to JDK 1.4.  someone in the bug I posted
earlier asked about a back-port to JDK 5.  maybe 1.5.0_12 has it, I
dunno.  that bug was from a while ago.

 

so I would try upgrading to the latest JDK that you can, and if that
doesn't work, disable IPv6 if you can.  if you can't do any of those
things, than I don't know what to tell you.

 

..mike..

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eric Kreiser
Sent: Tuesday, August 28, 2007 10:50 AM
To: General Discussion for the Resin application server
Subject: Re: [Resin-interest] Start up problem

 



Scott Ferguson wrote: 

 

On Aug 28, 2007, at 9:45 AM, Eric Kreiser wrote:





That's interesting.  Thanks for finding this.
 
The Watchdog does bind to port localhost:6600.  That's how the
"stop"  
command works and how the Watchdog can manage multiple Resin
JVMs  
with a single watchdog process.
 
-- Scott
  

Is this a bug? or going to be considered a bug?

 

It's not a Resin bug.  Binding to a local port is a capability of the
JDK.  We're certainly not going to work around a JDK bug that
fundamental.

 

-- Scott

 

I don't follow.  Resin is binding the Watchdog process to 127.0.0.1:6600
right?  

And all that I am really concerned with is... how would/should I start
multiple Resin servers on the same machine?  How will this work if each
is going to try to bind to 127.0.0.1:6600?





I am wondering how this would work if I started multiple Resin
installations on the same machine?



  

..mike..
 
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Tony Zakula
Sent: Friday, August 24, 2007 9:26 PM
To: resin-interest@caucho.com
Subject: [Resin-interest] Start up problem
 
Hi,
 
I have been trying to install and run resin on a Centos
5 system.   
I run
 
it fine on Windows.  Everything installs fine on Centos,
but when I  
try
to run the resin.jar file with all of the default
configuration, I get
the following error:
 
Aug 24, 2007 11:26:39 AM com.caucho.boot.ResinWatchdog
run
INFO: java.net.BindException: Cannot assign requested
address
java.net.BindException: Cannot assign requested address
at java.net.PlainSocketImpl.socketBind(Native
Method)
at
java.net.PlainSocketImpl.bind(PlainSocketImpl.java:359)
at
java.net.ServerSocket.bind(ServerSocket.java:319)
at java.net.ServerSocket.(ServerSocket.java:185)
at
com.caucho.boot.ResinWatchdog.run(ResinWatchdog.java:496)
at java.lang.Thread.run(Thread.java:619)
 
The server is behind a firewall with an ip address of
192.168.1.3,  
but I
 
have an entry in the hosts file with the machine name
and the ip
address.  Any help would be appreciated.  Thanks!
 
Tony
 
 
___
resin-interest mailing list
resin-interest@caucho.com

http://maillist.caucho.com/mailman/listinfo/resin-interest
 
 
___
resin-interest mailing list
resin-interest@caucho.com

http://maillist.caucho.com/mailman/listinfo/resin-interest


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
 
  

___

resin-interest mailing list

resin-interest@caucho.com

http://maillist.caucho.com/mailman/listinfo/resin-interest



-- 
This message has been scanned for viruses and 
dangerous content by MailScanner 

Re: [Resin-interest] Start up problem

[Mike Wynholds]

This is an old bug report, but it sounds like it might be the cause:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6206527

Centos is sort of a redhat derivative, right?  anyway, assuming you are
using JDK 5, you could try either a) upgrading to JDK 6 or b) disable
IPv6.

" A workaround for RedHat-type users is to disable IPv6, by editing
/etc/sysconfig/network and changing NETWORKING_IPV6=no."

anyway, I have no idea if this is the actual issue.  I just did a quick
google search for " java.net.BindException: Cannot assign requested
address" and came across this.  It actually says it only happens when
binding to the local address, but maybe that's what the watchdog process
is doing??

..mike..

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tony Zakula
Sent: Friday, August 24, 2007 9:26 PM
To: resin-interest@caucho.com
Subject: [Resin-interest] Start up problem

Hi,

I have been trying to install and run resin on a Centos 5 system.  I run

it fine on Windows.  Everything installs fine on Centos, but when I try 
to run the resin.jar file with all of the default configuration, I get 
the following error:

Aug 24, 2007 11:26:39 AM com.caucho.boot.ResinWatchdog run
INFO: java.net.BindException: Cannot assign requested address
java.net.BindException: Cannot assign requested address
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:359)
at java.net.ServerSocket.bind(ServerSocket.java:319)
at java.net.ServerSocket.(ServerSocket.java:185)
at com.caucho.boot.ResinWatchdog.run(ResinWatchdog.java:496)
at java.lang.Thread.run(Thread.java:619)

The server is behind a firewall with an ip address of 192.168.1.3, but I

have an entry in the hosts file with the machine name and the ip 
address.  Any help would be appreciated.  Thanks!

Tony


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Debugging Resin Apps in/with Eclipse

[Mike Wynholds]

Just to be even more specific, the requirement for putting the cmd line args in 
resin.conf on windows actually kicked in at 3.1.2 (for some reason).  With 
3.1.1 I was able to debug by putting the cmd line args on the cmd line.  Dunno 
why.

 

As for getting debugging to work with windows and Resin 3.1.2, I am able to do 
so with IDEA (dunno about eclipse), but adding this to resin.conf:

 

  -Xdebug

  -Xnoagent

  -Djava.compiler=NONE

  
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005

 

and then having IDEA connect to any old remote server (nothing Resin specific).

 

what you are seeing when you put the cmd line args on the cmd line is the Resin 
watchdog process running in debug mode.  so you could debug the watchdog 
process, but not the Resin process.  not quite what you want.

 

..mike..

 



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Kreiser
Sent: Tuesday, August 14, 2007 8:58 AM
To: General Discussion for the Resin application server
Subject: Re: [Resin-interest] Debugging Resin Apps in/with Eclipse

 

I am on linux... but specifying the args in the resin.conf works great for me...

the main difference is that prior to the resin 3.1.x series... the watchdog 
parent process was not java... and simply passed any arguments passed to it 
down to the child java process which was actually your application server.

now in the 3.1.x series... the parent process is java as well as the child 
process... and the way to alter the child process is thru the resin.conf


MORAWETZ Martin wrote: 

I use Resin on a windows machine. I tried both specifying the

args in resin.conf and starting Resin with 'httpd.exe args'.

 

Specifiying them in resin.conf results in:

 

java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:518)
at java.net.Socket.connect(Socket.java:468)
at java.net.Socket.(Socket.java:365)
at java.net.Socket.(Socket.java:179)
at com.caucho.server.resin.Resin.parseCommandLine(Resin.java:934)
at com.caucho.server.resin.Resin.main(Resin.java:1341)
Can't connect to parent process through socket 1976
Resin needs to connect to its parent.
[Loaded java.util.IdentityHashMap$KeySet from C:\Programme\Java\jdk1.6.0_02\jre\
lib\rt.jar]
[Loaded java.util.IdentityHashMap$IdentityHashMapIterator from C:\Programme\Java
\jdk1.6.0_02\jre\lib\rt.jar]
[Loaded java.util.IdentityHashMap$KeyIterator from C:\Programme\Java\jdk1.6.0_02
\jre\lib\rt.jar]
[Loaded java.io.DeleteOnExitHook from C:\Programme\Java\jdk1.6.0_02\jre\lib\rt.j
ar]

 

Resin doesn't start up.

 

Starting httpd.exe with the args

C:\Programme\resin\httpd.exe -Xdebug -Xnoagent 
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=12345 -server a

causes Resin to start up correctly saying

 

"Listening for transport dt_socket at address: 12345
Resin Professional 3.1.2 (built Wed, 18 Jul 2007 11:30:06 PDT)
Copyright(c) 1998-2007 Caucho Technology.  All rights reserved.

:

:

"

 

As I wrote before, partly it works, because I can see the Resin Threads in

the Eclipse Debug perspective.

 

Interesting thow that specifying the arguments in the resin.conf and with

httpd.exe behaves that different.

 

Regards Martin

 

 

 

-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Shane Cruz
Gesendet: Dienstag, 14. August 2007 14:36
An: General Discussion for the Resin application server
Betreff: Re: [Resin-interest] Debugging Resin Apps in/with Eclipse

How are you passing the arguments to the JVM?  In Resin 3.0, that was 
done with specifying "args" in httpd.sh.  In Resin 3.1 you need to specify the 
arguments in resin.conf as shown here:

 

http://www.caucho.com/resin-3.1/doc/server-tags.xtp#jvm-arg

 

Shane

 





From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MORAWETZ 
Martin
Sent: Tuesday, August 14, 2007 7:09 AM
To: General Discussion for the Resin application server
Subject: [Resin-interest] Debugging Resin Apps in/with Eclipse

 

Hi, 

I had two approaches to debug Resin Apps within Eclipse 
which worked for me perfectly with Resin 3.0.x. However 
with Resin 3.1.2 I can't get them to work. 

The first approach was to start Resin with the arguments 
-Xdebug -Xnoagent 
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=12345 
and have in Eclipse Res

Re: [Resin-interest] 3.1.2 - Problems with multiple instances on samemachine

[Mike Wynholds]

The default port for the Resin watchdog process is 6600.  If you run
multiple instances on one JVM you need to set the watchdog port on all
(but one) of them:


  


..mike..

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jason
Chodakowski
Sent: Saturday, August 11, 2007 7:02 AM
To: General Discussion for the Resin application server
Subject: [Resin-interest] 3.1.2 - Problems with multiple instances on
samemachine

Because we need JVM isolation between web application, we run  
multiple instances of resin - we're getting this error on system  
startup (everything coming up from scratch)

[2007/08/11 06:49:59.690] java.net.BindException: Address already in use
[2007/08/11 06:49:59.690] Can't bind to /127.0.0.1:6600.
[2007/08/11 06:49:59.690] Check for another server listening to that  
port.
[2007/08/11 06:49:59.690]   at  
com.caucho.vfs.QJniServerSocket.create(QJniServerSocket.java:103)
[2007/08/11 06:49:59.690]   at com.caucho.server.port.Port.bind 
(Port.java:804)
[2007/08/11 06:49:59.690]   at  
com.caucho.server.cluster.Server.bindPorts(Server.java:1155)
[2007/08/11 06:49:59.690]   at  
com.caucho.server.cluster.Server.start(Server.java:1105)
[2007/08/11 06:49:59.690]   at  
com.caucho.boot.ResinWatchdogManager.(ResinWatchdogManager.java: 
138)
[2007/08/11 06:49:59.690]   at  
com.caucho.boot.ResinWatchdogManager.main(ResinWatchdogManager.java:262)
java.lang.NullPointerException
 at com.caucho.boot.ResinWatchdogManager. 
(ResinWatchdogManager.java:146)
 at com.caucho.boot.ResinWatchdogManager.main 
(ResinWatchdogManager.java:262)

Once the system is up, we can manually start the additional servers.  
The upshot is that only the first server in line starts, and then  
things are hosed.

Hope this is useful, or... if someone has seen this and has a fix/ 
workaround, please let me know.

Cheers,

J --


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Servlet exception using c:out with EL

[Mike Wynholds]

I *think* that with JSP 2.0 you want your taglib declaration to look
like this:

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"; %>

the old way was this:

<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core"; %>

the different is the "/jsp" in there that is added.

I am not 100% sure about the specifics either, but looking in some of my
recent projects, we are using the one with "/jsp" and things are working
fine.

..mike..

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Serge Knystautas
Sent: Thursday, August 09, 2007 7:26 AM
To: General Discussion for the Resin application server
Subject: Re: [Resin-interest] Servlet exception using c:out with EL

Hans Loeblich wrote:
> Am I the only one that has this problem?

You might want to Google upgrading from JSP 1.1 to JSP 2.0.  The 
rtexprvalue to true was the older way of doing things in JSP 1.1 when 
the JSP itself did not handle EL.  With JSP 2.0 (which Resin 3 
implements) you would want rtexprvalue set to false to pass an attribute

using EL.  There were two versions of the JSTL (which includes your 
c:out tag) to handle this, so you might need to change your taglib 
declarations.  It was messy and it's been too long since I've done it to

remember the specifics.

There should be some articles about making this transition.

-- 
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Resin / Apache load balancing with customResin server weighting (for data segmentation purposes)

[Mike Wynholds]

well, I did come up with a solution, however it is Resin-specific and requires 
some client-side code at all login points (ie: there is a customer login 
implemented in Flex as well as an administrative login implemented in HTML).

I set up apache for the web-tier and resin as the app-tier, connected by 
mod_caucho.  I have an idea of the overall systems architecture, but for this 
discussion we just assume that there is some farm of apache servers that are 
available under a single URL.

Resin offers a way to specify a preferred app-tier server in the cluster by 
accessing the web-tier and passing in a pre-fab jsessionid, utilizing the 
Resin-specific algorithm of starting it with an "a", "b", "c", etc.  for 
example, if I wanted the second server listed in the cluster in resin.conf, I 
request the following:

http://www.myserver.com;jsessionid=b

now, if there is no current session, mod_caucho will do its best to point the 
web-tier to the second server in the app-tier cluster.  it will still, however, 
fall back to the other clustered servers if B is down.  this is exactly what I 
want.

the downside to this solution is that my client code has to do some work to 
make this happen.  as a user logs in, the client must a) clear the session, and 
b) figure out the appropriate URL (ie: jsessionid prefix) to use and switcheroo 
it in as the user logs in, based on the project number entered in to the login 
form.

I actually have a server-side servlet that does the logic, so I just need a way 
to call it easily.  basically, in Flex I just use the standard Flash 
mx:HTTPService, which is easy, and in HTML I just use AJAX.  so it's not too 
bad, but it would be nice if it was even more "behind the scenes".  it can't be 
100% behind the scenes, tho.  I would at least need a convention of putting the 
project number in the session or in the login URL under a specific name, or 
something like that, even if I could do custom load balancing login on a 
hardware load-balancer.

anyway, so far so good.

any suggestions for improvements would be definitely appreciated!

..mike..

.
Michael Wynholds
President
Carbon Five, Inc.
310 821 7125 x13
[EMAIL PROTECTED]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jay Ballinger
Sent: Wednesday, July 25, 2007 8:43 AM
To: General Discussion for the Resin application server
Subject: Re: [Resin-interest] Resin / Apache load balancing with customResin 
server weighting (for data segmentation purposes)

Mike,

This sounds like a perfect use for a hardware load-balancer. A
hardware load-balancer can create the affinity for a particular server
much like you describe - except for the choosing of a server based on
your algorithm, that is.

Most hardware solutions implement some sort of persistence feature
where, once a load-balancing decision has been made by the device, it
will try to persist that same 'user' to that same server for a
configurable amount of time. We use this to keep a user's access and
application log on one server versus having to hunt around all the
servers to piece their session together.

If you are trying to create logic that says, "All project 'A' users go
on server 'X'," I see that as a big challenge for the chicken-egg
scenario you describe - the user already has an affinity to a server
before you know the user or the project. However, there are some
pretty slick hardware load-balancers out there that can use
cookie-driven values. Check out the lineup from F5 - specifically
their Big-IP Local Traffic Managers.

Of course, you could have a farm of login servers that simply takes
the login info and then redirects the user to a different farm of
servers based on the project info.

Good luck, and let us know what you come up with.

+ jay

On 7/11/07, Mike Wynholds <[EMAIL PROTECTED]> wrote:
>
>
>
>
> I have a somewhat complex load balancing scenario that I wish to accomplish.
>  From my investigation it seems that it's *probably* possible but I haven't
> gotten it to work yet.  Here is the scenario:
>
>
>
> I have a web app running on Resin 3.1.1 with Apache 2.2 in front of it.  I
> want to have multiple Resin servers in a cluster.  I may have multiple
> Apache servers as well, but I don't think that's important.  If I do I will
> have a hardware load-balancer in front of that.
>
>
>
> I want to achieve both failover and server scalability with my systems
> architecture.  I think I can utilize a clustering solution to handle this.
> I will need to cluster both Resin sessions as well as a number of
> memory/disk caches using the distributed mode of EhCache (or possible
> JBossCache).  So far the Resin session clustering is working fine.  However,
> for efficiency I really also want to segment my data between users, in order
> to 

[Resin-interest] Resin 3.1.1 JMX / cluster issue

[Mike Wynholds]

I am running a cluster of Resin servers on 3.1.1.  I have two servers in
my app-tier cluster, app-a and app-b.  When I access the following JMX
object:

resin:type=Cluster,name=app-tier

 

using jconsole, the "Servers" attribute has an array of ObjectNames of
length 1.  It only contains app-b.

 

However, both of the following objects are directly available in JMX:

resin:type=ServerConnector,name=app-a

resin:type=ServerConnector,name=app-b

 

and when I hit /caucho-status they are both up.

 

so why does the app-tier cluster report only a single server?  I am
connected to the JMX server on app-a.  does it not include itself in the
Servers attribute, or is this a bug, or am I doing something wrong?  I
assume it's not an order of operations thing, ie: I bring app-a up, then
app-b.  when I then access app-a via JMX, that cluster mxbean should be
updated, right?

 

..mike..

 

___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] Resin / Apache load balancing with custom Resin server weighting (for data segmentation purposes)

[Mike Wynholds]

I have a somewhat complex load balancing scenario that I wish to
accomplish.  From my investigation it seems that it's *probably*
possible but I haven't gotten it to work yet.  Here is the scenario:

 

I have a web app running on Resin 3.1.1 with Apache 2.2 in front of it.
I want to have multiple Resin servers in a cluster.  I may have multiple
Apache servers as well, but I don't think that's important.  If I do I
will have a hardware load-balancer in front of that.

 

I want to achieve both failover and server scalability with my systems
architecture.  I think I can utilize a clustering solution to handle
this.  I will need to cluster both Resin sessions as well as a number of
memory/disk caches using the distributed mode of EhCache (or possible
JBossCache).  So far the Resin session clustering is working fine.
However, for efficiency I really also want to segment my data between
users, in order to reduce either a) the amount of cache replication (if
I use cache replication) or b) the amount of cache misses (if I use
cache invalidation) in EhCache.

 

When people come to the site, they are given a login page immediately.
There are two entry points: one is HTML-based and one is
Flash/Flex-based.  Either way the user is prompted to log in with a
username, password and a project number.  I want to pin all users logged
in to a particular project to the same backend server so that the
EhCache can be used as efficiently as possible.

 

But while I say I want to "pin" specific users to specific backend
servers, I really also want the failover capability built in to
load-balancers.  So what I *really* want is a way to suggest to the load
balancer which server to prefer, but allow it to fall back in the case
of a server being down.  My algorithm for choosing a server to suggest
is simple: I just hash the project number, mod by the amount of servers,
and choose that one.  Not smart, but for now that's fine.

 

I feel like I will want to use the Resin load balancing features
(although I am open to other suggestions).  From the docs it seems like
there may be a way to do it.  I have spent a few hours on this and am
not seeing a very clear solution.  My main theoretical issue is that
when the user hits the login page a session is created.  There is no way
to know which project number the user will then enter, and therefore
which server to try to pin him too.  But then if he enters a project
number, Resin already has him pinned to a server by the jssesionid.  

 

Is there a way to tell Resin to keep the session but now house it on a
different server?  

 

I think the logic of project number --> server needs to be in the app
somewhere (ideally the server side, not the Flash side).  Can I set a
cookie or something that can be sniffed by Resin's load balancing
capabilities that will determine the suggested server to pin to?

 

I can kind of see the light at the end of the tunnel but haven't been
able to come up with even a best theoretical approach to this problem.
There is just too much about Resin load balancing, mod_caucho, hardware
load balancers and the such that I am not intimately familiar with, and
I don't want to reinvent anything that already exists and works well.

 

Thanks for any suggestions.

..mike..

 

.

Michael Wynholds

President

Carbon Five, Inc.

310 821 7125 x13

[EMAIL PROTECTED]

 

___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Workaround for Resin bug 1788 - JSPprecompiled and functions

[Mike Wynholds]

Great.  I can probably wait out 3.1.2.

 

but just for now, I am still seeing this error when setting
precompile='false'.  I have multiple web-apps running, but this is how I
am configuring the one of interest:

 



   

  



 

does 'fast-jstl' interfere with 'precompile'?

..mike..

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson
Sent: Tuesday, July 10, 2007 11:20 AM
To: General Discussion for the Resin application server
Subject: Re: [Resin-interest] Workaround for Resin bug 1788 -
JSPprecompiled and functions

 

 

On Jul 10, 2007, at 11:02 AM, Mike Wynholds wrote:





The following bug exists in Resin 3.1.1 and is reported fixed in 3.1.2:

http://bugs.caucho.com/view.php?id=1788

 

It appears that this bug essentially makes it impossible to use JSP EL
functions (such as the JSTL functions) in JSP pages in Resin 3.1.1.  The
bugs says only precompiled JSPs are affected, but out of the box
(config-wise), that includes all JSP tagfiles (*.tag) every time they
are used, as far as I can tell.

 

Is there any workaround for this?  

 

Only by setting .



This makes Resin 3.1.1 almost unusable for me.

It's a major bug.



Also, Scott- do you have a release date planned for Resin 3.1.2?

It's planned for this week.  We're doing the final stress testing and
compatibility QA now.

 

There is a new snapshot today by the way.  Unless we find something in
the QA this week, it will essentially be the 3.1.2 release.

 

-- Scott



 

..mike..

 

.

Michael Wynholds

President

Carbon Five, Inc.

310 821 7125 x13

[EMAIL PROTECTED]

 

___

resin-interest mailing list

resin-interest@caucho.com

http://maillist.caucho.com/mailman/listinfo/resin-interest

 

___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] Workaround for Resin bug 1788 - JSP precompiled and functions

[Mike Wynholds]

The following bug exists in Resin 3.1.1 and is reported fixed in 3.1.2:

http://bugs.caucho.com/view.php?id=1788

 

It appears that this bug essentially makes it impossible to use JSP EL
functions (such as the JSTL functions) in JSP pages in Resin 3.1.1.  The
bugs says only precompiled JSPs are affected, but out of the box
(config-wise), that includes all JSP tagfiles (*.tag) every time they
are used, as far as I can tell.

 

Is there any workaround for this?  This makes Resin 3.1.1 almost
unusable for me.

Also, Scott- do you have a release date planned for Resin 3.1.2?

 

..mike..

 

.

Michael Wynholds

President

Carbon Five, Inc.

310 821 7125 x13

[EMAIL PROTECTED]

 

___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest