Re: [Resin-interest] Multiple web-app-deploy tags

[Scott Ferguson]

On 4/10/18 12:24 PM, matt wrote:
> Does anyone know if it's possible to use multiple web-app-deploy tags in the 
> same host? I want to have my local dev server pick up whichever apps I've 
> built from a set of projects, where the built output will be in exploded war 
> format. I could tag each app, but it's nice just putting my target dir as a 
> deploy dir.
>
> When I put two of them now, it seems like only the last one works. The JMX 
> shows two WebAppDeploy beans, but the first one listed in resin.xml shows the 
> "Names" as empty.

Skimming the code, it looks as if Resin should merge the web-app 
configuration if the root-directory matches. So as long as the two 
web-app-deploy tags expand to the same directory, the web-app-default in 
the web-app-deploy will be applied.

But if the two web-app-deploy expand to different directories, only one 
would be configured.

-- Scott

>
> Sent from my iPhone
>
>
> ___
> 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] Logrotation and NFS

[Scott Ferguson]

On 2/8/16 5:01 AM, Jens Dueholm Christensen wrote:


Hi

Resin license #1016608

Recently we’ve migrated to a ceph-based storage setup where we use NFS 
to allow our multiple Resin instances to write their logs directly to 
Ceph over NFS.




The logging did change between Resin 3 and Resin 4 mostly to improve 
threading, but the log rotation is essentially the same. (As I 
remember.) So if NFS stalls during log rotation, it's still going to be 
a problem. The log is written assuming the rotation might be slow (and 
avoids blocking other threads while it's happening), but it does assume 
the rotation will complete and not freeze.


-- Scott

However, on 2 of our client-machines we see NFS stalls and 
retransmissions a few minutes past midnight for some files.


So far I’ve managed to write off posibility after posibility and right 
now I’m stuck a few last possibilities, and the next one in line is 
the way Resin does logrotation.


A poll of open files each second (via lsof output) shows this where 
out stdout logfile gets rotated:


COMMAND PID  USER   FD  TYPE   DEVICE   
SIZE/OFF   NODE NAME


Sun Feb  7 23:59:58 CET 2016

java  30865   results  238w REG   0,25 1215099201 
1073774597 
/nfsdata-web11nfs/results/logs/web9_results_backend1/resin-web-stdout.log


Sun Feb  7 23:59:59 CET 2016

java  30865   results  238w REG   0,25 1215100254 
1073774597 
/nfsdata-web11nfs/results/logs/web9_results_backend1/resin-web-stdout.log


Mon Feb  8 00:00:00 CET 2016

java  30865   results  107w  REG   0,25  
233381888 1073774632 
/nfsdata-web11nfs/results/logs/web9_results_backend1/resin-web-stdout.log.20160207


java  30865   results  118r REG   0,25 1215103872 
1073774597 
/nfsdata-web11nfs/results/logs/web9_results_backend1/resin-web-stdout.log


Mon Feb  8 00:00:04 CET 2016

java  30865   results  107w REG   0,25  929890304 
1073774632 
/nfsdata-web11nfs/results/logs/web9_results_backend1/resin-web-stdout.log.20160207


java  30865   results  118r REG   0,25 1215103872 
1073774597 
/nfsdata-web11nfs/results/logs/web9_results_backend1/resin-web-stdout.log


Mon Feb  8 00:00:55 CET 2016

java  30865   results  161r REG   0,251439432 
1073774597 
/nfsdata-web11nfs/results/logs/web9_results_backend1/resin-web-stdout.log


All day on the 7^th the logfile is opened on filehandle 238 with write 
access (238w in the FD column)


Then around midnight a new file is created named 
resin-web-stdout.log.20160207 on filehandle 107 with write permission 
(107w in the FD column).


At the same time it seems resin-web-stdout.log is opened with a new 
filehandle and only with read permission (118r).


Then over time data is copied from the file with handle 118r to 107w – 
the size/offset numbers increase between 00:00:00 and 00:00:04.


The stall I experience happens between 00:00:04 and 00:00:55 where 
lsof output stalls (the man-page mentions that lstat(2), readlink(2), 
and stat(2) calls are blocked if the NFS server is unresponsive).


Other open files in other Resin instances /running on the same server/ 
does not see these stalls – nor does other client-machines, so I am 
confident that our NFS-server is alive and answering requests.


Now for the real questions:

Since we are running an ancient version of Resin (3.1.13 and 3.1.14), 
have the way of rotating logfiles changed in Resin 4.0 or later?


Are the stalls I’m seeing (I assume it could just as well happen 
locally if a disksubsystem was slow enough) a known issue that has 
been fixed in Resin 4.0 or later?


Right now the best way of solving this is to change to syslog logging, 
but since we already have a roadmap for Resin 4 planned for later this 
year (yeay – finally!) this might just be enough for us to move it up 
to the top of our list.


Regards,

*Jens Dueholm Christensen
*Survey IT

P +45 5161 7879

j...@ramboll.com 



Rambøll

Olof Palmes Allé 20

DK-8200 Aarhus N

Denmark

www.ramboll.dk 



___
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] Simplest way to get resin (4.0.47) to serve *.html as if it were *.jsp?

[Scott Ferguson]

On 12/28/15 1:15 PM, Carl Whalley wrote:
> I'm learning Polymer and want to use Resin as its server. I find if I
> rename all *.html files to *.jsp all is well, after I add the
> pageContentType and taglib prefix xml element to the top of each page.
> I'd really like to do it the other way round though, i.e. tell resin to
> treat each *.html file as if it was a *.jsp. I added this to
> app-default.xml
>
>   servlet-name="resin-jsp"
>  default="true"/>
>
> But it had no effect -it just dumps the jsp code to the browser rather
> than execute it. Whats the best way to do this please? Also, it would be
> better aimed at just one particular web-app. Thanks.

Try removing the "default". Also, you should be able to add it to the 
web.xml.

The "default" is for Resin to make its defaults a lower priority than 
any other definition.

-- Scott


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

Re: [Resin-interest] Resin 4.0.44 killing itself?

[Scott Ferguson]

On 6/1/15 2:19 PM, Rick Mann wrote:
 Something is killing my resin process. The watchdog log shows this when it 
 happens:

 [2015/06/01 21:13:45.624] {watchdog-app-0} Watchdog detected close of 
 Resin[app-0,pid=3728]
   exit reason: SIGKILL (signal=9)
 [2015/06/01 21:13:45.628] {watchdog-app-0} WatchdogChild[app-0] starting
 [2015/06/01 21:13:45.677] {watchdog-app-0} Watchdog starting Resin[app-0]

 This seems to correlate with invoking an action that spawns some threaded 
 activity. Note that this is a webapp I've been running for years on an older 
 VM, and a few days ago I moved it to a new VM. ps shows this:
Is there anything in the resin log?

The only 'kill' is in the watchdog, and it doesn't use a sigkill. It 
just calls the JVM's process.close().

I checked the JNI and there's no kill there.

Anything in /var/log possibly?

-- Scott


   4985 ?Sl 0:25 /usr/lib/jvm/java-8-oracle/bin/java -Xmx2048m 
 -XX:MaxPermSize=256m -Dresin.server=app-0 
 -Djava.util.logging.manager=com.caucho.log.LogManagerImpl 
 -Djava.system.class.loader=com.caucho.loader.SystemClassLoader 
 -Djava.endorsed.dirs=/usr/lib/jvm/java-8-oracle/jre/lib/endorsed:/lz/usr/resin/current//endorsed:/lz/var/www/endorsed
  -Djavax.management.builder.initial=com.caucho.jmx.MBeanServerBuilderImpl 
 -Djava.awt.headless=true -Djava.awt.headlesslib=true 
 -Dresin.home=/lz/usr/resin/current/ -Xss1m -d64 -server 
 com.caucho.server.resin.Resin --root-directory /lz/var/www -conf 
 /lz/etc/resin/resin.xml -server app-0 -socketwait 50229 -root-directory 
 /lz/var/www -log-directory /logs/resin restart
 21256 ?Sl11:12 /usr/lib/jvm/java-8-oracle/bin/java 
 -Dresin.watchdog=app-0 
 -Djava.util.logging.manager=com.caucho.log.LogManagerImpl 
 -Djavax.management.builder.initial=com.caucho.jmx.MBeanServerBuilderImpl 
 -Djava.awt.headless=true -Djava.awt.headlesslib=true 
 -Dresin.home=/lz/usr/resin/current/ -Dresin.root=/lz/var/www -Xrs -Xss256k 
 -Xmx32m -d64 -server com.caucho.boot.WatchdogManager -root-directory 
 /lz/var/www -conf /lz/etc/resin/resin.xml -log-directory /logs/resin start 
 --log-directory /logs/resin

 I started resin as root with resinctl start.

 I'm not sure what else to look at. Any suggestions?

 Thanks!



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

Re: [Resin-interest] Websockets - difference when using mod_caucho?

[Scott Ferguson]

On 4/5/15 5:23 AM, c.whalley wrote:
 On 02/04/2015 16:28, c.whalley wrote:
 I've got pretty much the example from:
 http://wiki4.caucho.com/Resin_4_Java_EE_Basic_Servlet,_Comet,_and_WebSocket_Tutorial#Hello.2C_World_WebSocket_in_Resin
 snip
 I've just proven this is caused by the mod_caucho config by tweaking the
 setup so it uses port 8080 throughout, i.e. with the same deployed app
 but pure resin we're good to go.
 I've seen there is an apache mod_proxy_wstunnel which can upgrade the
 incoming connection to a websocket connection but so far still haven't
 been able to get this going, in any case why is this needed? I thought
 all incoming traffic on port 80 was forwarded to 8080 once a virtual
 server had the appropriate entries to do so for the servets etc in its
 config?

Because HTTP and websockets are very different, a HTTP proxy isn't 
powerful enough to tunnel websockets messages. Basically, a websocket 
proxy needs two threads, one to listen for server messages and a second 
thread to listen for client messages. But HTTP only needs a single 
thread to listen for server messages, because once the client POST is 
done, there are no more messages for HTTP.

mod_caucho is designed around HTTP only (and Apache itself was designed 
around HTTP only).

-- Scott


 This runs fine in my local env with resin on 8080 and Apache on 80
 (Win), same config on a Fedora 21 QA server but when deployed to
 production, which uses mod_caucho, I see


 ___
 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] 4.0.44 release

[Scott Ferguson]

On 3/31/15 12:36 PM, Mathias Lagerwall wrote:
Thanks Ferg for looking into my 0005865 bug-report. We are in great 
need of this. Would it be possible to do the 4.0.44 release really 
soon? Or is it possible to take 4.0.43 and patch it with this specific 
fix in 4.0.44?


Fairly soon (as in a week or two). There are a few more bugs before 
starting the release QA. They don't look too complicated.


- Scott



Best regards
Mathias Lagerwall



___
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] How to change SMTP config for health:PdfReport in Resin-Pro-4.0?

[Scott Ferguson]

On 10/17/14, 6:59 AM, BUSCH Steffen wrote:


In health.xml I am able to specify a mail reference for example

health:SendMail mail=${healthMailer}

toad...@yourdomain.com/to

health:OnStop/

health:SendMail

where ${healthMailer} can be configured in resin.xml like this

mail name=healthMailer

smtp-hostmail.yourdomain.com/smtp-host

smtp-port25/smtp-port

fromre...@yourdomain.com/from

/mail



Setting the system property mail.smtp.host should work.

It looks like we can add the smtp-host/smtp-port into the PdfReport, but 
it's not configurable currently.


-- Scott

èBut in health.xml there is also health:PdfReport configured to 
retrieve a PDF as attachment. But how do I refer to my configured the 
${healthMailer} there? It seems that it is always trying to connect to 
localhost:25 in the logfiles?


health:PdfReport

path${resin.root}/doc/admin/pdf-gen.php/path

reportRestart/report

period2h/period

mail-to${email}/mail-to

mail-from${email_from}/mail-from

health:OnRestart/

/health:PdfReport

-- Steffen



___
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] How to change SMTP config for health:PdfReport in Resin-Pro-4.0?

[Scott Ferguson]

On 10/17/14, 9:37 AM, BUSCH Steffen wrote:


Thanks Scott, I'm going to try the system-property, but I would prefer 
to just add a reference to the already configured javax.mail resource 
like this just to have a single place of SMTP configuration:


health:PdfReport mail=${healthMailer}



Ok. I can add that.

-- Scott


-- Steffen

On 10/17/14, 6:59 AM, BUSCH Steffen wrote:

In health.xml I am able to specify a mail reference for example

  health:SendMail mail=${healthMailer}

toad...@yourdomain.com mailto:ad...@yourdomain.com/to

health:OnStop/

  health:SendMail

where ${healthMailer} can be configured in resin.xml like this

  mail name=healthMailer

smtp-hostmail.yourdomain.com/smtp-host

smtp-port25/smtp-port

fromre...@yourdomain.com mailto:re...@yourdomain.com/from

  /mail


Setting the system property mail.smtp.host should work.

It looks like we can add the smtp-host/smtp-port into the PdfReport, 
but it's not configurable currently.


-- Scott


èBut in health.xml there is also health:PdfReport configured to 
retrieve a PDF as attachment. But how do I refer to my configured the 
${healthMailer} there? It seems that it is always trying to connect to 
localhost:25 in the logfiles?


health:PdfReport

path${resin.root}/doc/admin/pdf-gen.php/path

reportRestart/report

period2h/period

mail-to${email}/mail-to

mail-from${email_from}/mail-from

health:OnRestart/

/health:PdfReport

-- Steffen




___
resin-interest mailing list
resin-interest@caucho.com  mailto: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-Pro-4.0.40: Support for password-digest old-encoding=true algorithm=MD5/ ?

[Scott Ferguson]

On 9/26/14, 2:28 AM, BUSCH Steffen wrote:


Hi Scott,

finally I'm preparing to move from Resin 3.1 to 4.0 and wondering if 
it would be possible if you could add legacy-support for the 
*old-encoding* feature to the XmlAuthenticator. I've been using it in 
many quite old 3.1 files like this:


  authenticator type=com.caucho.server.security.XmlAuthenticator

init

  password-digest old-encoding=true algorithm=MD5 /

password-digest-realmnone/password-digest-realm

  pathpasswords.xml/path

/init

  /authenticator

Any chance?



Would a conversion program work for you? The old-encoding was an old bug 
where base64 wasn't implemented properly. I'd prefer to keep that code 
out of the main authentication code.


-- Scott


Thanks,

Steffen



___
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] ETA 4.0.41

[Scott Ferguson]

On 9/12/14, 12:37 AM, Mathias Lagerwall wrote:

Hi

Is there an ETA of the 4.0.41 release? We are in great need of the 
0005733 fix.


It's day to day, so early next week.

We were planning for the release this week, but decided to fit some more 
bug fixes in the release.


-- Scott



Best regards
Mathias



___
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 4 Session Clustering - restart of triad servers

[Scott Ferguson]

On 6/6/14, 2:51 PM, Burke, Brian wrote:
 Hi Paul,
Thanks for the response.  I did some more testing of my setup, and it 
 appears things are working as expected.   I believe the source of my 
 confusion was the resin-admin UI: resin-admin/index.php?q=sessionss=0  It 
 appears that after a restart, it doesn't show the count and session IDs of 
 the sessions that it has persisted to disk, and actually has available.  When 
 I tested my scenarios in an actual app though, I can see session state is 
 maintained.

That makes sense.

The resin-admin tracks the in-memory sessions. It doesn't try to load 
them from disk.

So there really are no cases where session data can be lost, as long as at 
 least one of the triad servers is running?  And for a cluster of just 2 
 servers, same situation, just need to make sure one server is always running 
 and things should be fine?

In normal operation, it wouldn't be lost.

When a triad server starts, it asks any other live triad servers for 
updates since the time it was down. It then saves the updates to disk.

-- Scott



 Thanks,
 -Brian

 
 From: resin-interest-boun...@caucho.com [resin-interest-boun...@caucho.com] 
 On Behalf Of Paul Cowan [co...@caucho.com]
 Sent: Thursday, June 05, 2014 9:53 AM
 To: General Discussion for the Resin application server
 Subject: Re: [Resin-interest] Resin 4 Session Clustering - restart of triad   
   servers

 On Jun 4, 2014, at 5:56 PM, Burke, Brian bbu...@techtarget.com wrote:

 A question related to session replication in resin 4.0   I’m using a cluster 
 of 3 servers, therefore all three are triad servers.  After a server is 
 restarted, I see that the session objects that exist on the other two 
 servers don’t get replicated to the restarted server until there is a 
 request made for that session.  With this behavior, I can’t restart these 3 
 servers in a rolling fashion, unless I wait at least ‘session-timeout’ 
 between the restarts.
 Hi Brian,

 The restarted triad server does keep a local copy on disk, but you are 
 partially correct - it will need to contact another triad server to verify it 
 has the most up-to-date version of the session data.

 I’m trying to understand why you think you need to wait session-time between 
 server restarts.  I’m don’t think that is the case but if you are seeing 
 adverse behavior please supply details and that would help me determine if 
 it’s a bug or something else.  As long as 1 triad server is up at any time 
 the triad state should be maintained properly.

 Thanks,
 Paul


 Is there a way to force a restarting triad server to re-populate it’s store 
 of sessions on restart?  Or another way to handling planned rolling restarts 
 of the triad servers in a more efficient manner?

 This is the current config in resin.xml, under the cluster tag:

 web-app-default
 session-config
 use-persistent-store/
 always-save-session/
 /session-config
 /web-app-default

 Thanks,
 -Brian



 ___
 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] Problem with session storage becoming corrupt

[Scott Ferguson]

On 5/20/14, 12:38 AM, Mathias Lagerwall wrote:
 Hi Scott and thanks for the fast answer.0

 Is there anything we can do here to help fixing this issue?

You could try disabling JNI, assuming you're not using openssl.
 Do you think this will be fixed in 4.0.40 or should I start preparing
 for a transition to Linux on all the servers involved?

Well, 4.0.40 just went out, so it would be in 4.0.41. It would certainly 
be included in any 4.0.41 fixes. Changing to Linux would also fix the issue.

-- Scott

 Best regards
 Mathias Lagerwall



 ---
 CTO - Mathias Lagerwall
 Netset AB, Adelgatan 9, 211 22 Malmö
 Tel +46 (0)40 208800
 Mobile +46 (0)733 919103


 2014-05-20 0:45 GMT+02:00 Scott Ferguson f...@caucho.com:
 On 5/19/14, 6:16 AM, Mathias Lagerwall wrote:
 Hi
 We are running several clusters with resin-pro and have problems with
 the sessions.

 We have tried several versions of Resin / Java but the current setup is:
 Win Server 2008 R2 SP1
 Java 1.7.0_55 from Oracle
 Resin-Pro 4.0.39

 JniRandomAccessFile[/D:/resin-pro-4.0.39/resin-data/fi_b/distcache/data.db]:class
 com.caucho.vfs.JniRandomAccessFile
 [2014/05/17 09:33:56.342] {resin-30} Watchdog received warning from
 Resin[fi_b,pid=0]:

 java.lang.IllegalStateException: block at 0xb1be6000 is invalid for
 file /D:/resin-pro-4.0.39/resin-data/fi_b/distcache/data.db (length
 0x8000)

 JniRandomAccessFile[/D:/resin-pro-4.0.39/resin-data/fi_b/distcache/data.db]:class
 com.caucho.vfs.JniRandomAccessFile
 .
 The log can become many GB during a day of operation. The sites are
 quite busy and a lot of sessions are created. Ferg indicated to me in
 an earlier conversation that the length 0x8000 looked strange.
 Does this mean that the session storage is too big? Are we somehow
 running 32-bit things when we shouldn't?

 I have tried to recreate the problem locally on my Linux machine but I
 am not able to trigger the error. I am not sure if this has to do with
 me running Linux or that my simulated load isn't triggering the error.
 It's a windows specific issue, so Linux definitely makes a difference.

 Basically, the stat() call on windows returns a 32-bit file length. The
 earlier fix calls a separate windows stat call to get the 64-bit file
 length. But it looks like there might be another call that wasn't changed.

 -- Scott
 What can I do to the track this down?

 Best regards
 Mathias Lagerwall

 ___
 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] Problem with session storage becoming corrupt

[Scott Ferguson]

On 5/19/14, 6:16 AM, Mathias Lagerwall wrote:
 Hi
 We are running several clusters with resin-pro and have problems with
 the sessions.

 We have tried several versions of Resin / Java but the current setup is:
 Win Server 2008 R2 SP1
 Java 1.7.0_55 from Oracle
 Resin-Pro 4.0.39

 JniRandomAccessFile[/D:/resin-pro-4.0.39/resin-data/fi_b/distcache/data.db]:class
 com.caucho.vfs.JniRandomAccessFile
 [2014/05/17 09:33:56.342] {resin-30} Watchdog received warning from
 Resin[fi_b,pid=0]:

 java.lang.IllegalStateException: block at 0xb1be6000 is invalid for
 file /D:/resin-pro-4.0.39/resin-data/fi_b/distcache/data.db (length
 0x8000)

 JniRandomAccessFile[/D:/resin-pro-4.0.39/resin-data/fi_b/distcache/data.db]:class
 com.caucho.vfs.JniRandomAccessFile
 .
 The log can become many GB during a day of operation. The sites are
 quite busy and a lot of sessions are created. Ferg indicated to me in
 an earlier conversation that the length 0x8000 looked strange.
 Does this mean that the session storage is too big? Are we somehow
 running 32-bit things when we shouldn't?

 I have tried to recreate the problem locally on my Linux machine but I
 am not able to trigger the error. I am not sure if this has to do with
 me running Linux or that my simulated load isn't triggering the error.

It's a windows specific issue, so Linux definitely makes a difference.

Basically, the stat() call on windows returns a 32-bit file length. The 
earlier fix calls a separate windows stat call to get the 64-bit file 
length. But it looks like there might be another call that wasn't changed.

-- Scott

 What can I do to the track this down?

 Best regards
 Mathias Lagerwall

 ___
 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] XML parser changes in Resin 4

[Scott Ferguson]

On 4/28/14, 4:31 PM, Jay H. Hartley wrote:
I see in the source code for Resin 4, a new package called 
com.caucho.xml2. Among other things, the XmlParseException there now 
extends SAXException, rather than a RuntimeException, as was the case 
in com.caucho.xml.XmlParseException. That's excellent.


However, when I look at 
com.caucho.xml2.parsers.XmlDocumentBuilderFactory, it appears to use 
the com.caucho.xml.Xml class from the old package, which ultimately 
uses the old parser logic.


Am I missing something? What is the default parser for Resin 4, and 
which xml package is actually used?


xml2 is a discontinued experiment (so, actually, we should delete it.)

The default Xml for everything but Resin's own config parsing is the 
JDK's parser.


When I was working on the xml2, it had a slight performance benefit over 
the JDK, but not enough to justify maintaining it.


-- Scott



Jay


___
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] Character encoding in root vs included JSP

[Scott Ferguson]

On 2/28/14, 4:47 AM, Rick Mann wrote:

Hmm. Seems like if I %@ include a file that contains

%@ page contentType=text/html; charset=UTF-8%

Then it doesn't work. If I include that @ page line directly, it gets the 
encoding right.


I believe that's correct, though. The top page is responsible for 
deciding encoding.


-- Scott



On Feb 28, 2014, at 04:45 , Rick Mann rm...@latencyzero.com wrote:


I thought I had UTF-8 set throughout my app; source files are encoded in it, I 
set it everywhere I can think of (requests, responses, JVM, HTML and JSP tags).

I we re-doing the HTML for my site, fancifying it with bootstrap and all that 
goodness, when I noticed that the copyright symbol I typed wasn't rendering 
correctly. It used to with the old HTML, so I investigated.

Turns out, it only renders correctly if I jsp:include the HTML snippet that 
contains the symbol. If it's typed directly into the page, it doesn't work.

Any ideas? Thanks!

--
Rick



___
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 in AIX -On restart RESIN_HOME is taken from bin folder

[Scott Ferguson]

On 2/21/14, 8:24 AM, radha wrote:
 Dear All

 Resin-4-0-33  runs on a AIX box and one issues that we face is incase of
 watch dog triggers restart of resin then RESIN_HOME is take as
 $RESIN_HOME/bin.

 In fact wachdog has -Dresin.home parameter and it is showing the
 correctly the $RESIN_HOME/bin.

Any inputs will be helpful.

 Also how can I configured disabling of watchdog restarting resin and
 associated application?
 Any configuration that can be done?

In what way is $RESIN_HOME not being used correctly? Normally, 
applications shouldn't care about resin.home as long as the right 
version is found.

And you can't disable watchdog restarting resin. It's job is to start 
Resin if it crashes.

Why would you want to disable this?

-- Scott


 Please help me on this.



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

Re: [Resin-interest] specify data source for ejb manager

[Scott Ferguson]

On 1/3/14, 5:15 AM, Riccardo Cohen wrote:
 Hello
 I will soon have more than one mysql server. I want to use one server
 for read requests of static data, the other for read/write requests of
 dynamic data. It works for sql requests through datasource, but I cannot
 find how to do it with ejb manager.

 In my resin.xml I have this :

   database jndi-name=jdbc/adlresintest
 ...
   /database
   ejb-server data-source=jdbc/adlresintest
 create-database-schema=false
 jndi-name=ejb/
   database jndi-name=jdbc/adlresintest2
 ...
   /database
   ejb-server data-source=jdbc/adlresintest2
 create-database-schema=false
 jndi-name=ejb2/

 In persistence.xml  :

 persistence xmlns=http://java.sun.com/xml/ns/persistence; version=1.0
 persistence-unit name=adlresintestunit
   providerorg.eclipse.persistence.jpa.PersistenceProvider/provider
   classadlresintest.Adluser/class
   exclude-unlisted-classes /
   properties
 property name=eclipselink.ddl-generation.output-mode
 value=database /
 property name=eclipselink.weaving.fetchgroups value=false/
   /properties
 /persistence-unit
 /persistence

 In my java code I have this :

 @Inject @Named(jdbc/adlresintest) public DataSource
 m_datasource1;// public site
 @Inject @Named(jdbc/adlresintest2) public DataSource
 m_datasource2;// not used for the moment
 @PersistenceUnit(name=adlresintestunit) @Named(ejb)
 EntityManagerFactory ejbfactory1;
 @PersistenceUnit(name=adlresintestunit) @Named(ejb2)
 EntityManagerFactory ejbfactory2;


 When using datasource1 or 2 I access the correct database. But when
 using ejbfactory1 or 2, only the second database is accessed. The
 association created with jndi-name and @Named() works for
 DataSource/database but not for EntityManagerFactory/ejb-server.

 I also tried to use composite persistence unit as written here :
 http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Advanced_JPA_Development/Composite_Persistence_Units
 but I could not find the good configuration to do it, the tag
 jta-data-source was not accepted. I could not find in
 http://eclipse.org/eclipselink/documentation/2.4/jpa/extensions/persistenceproperties_ref.htm
 which property to set for the datasource.

The configuration should be jta-data-source and non-jta-data-source 
in the persistence-unit:

persistence ...
   persistence-unit name=test ...
 jta-data-sourcejdbc/adlresintest/jta-data-source
 ...
   /persistence-unit
   persistence-unit name=test2 ...
jta-data-sourcejdbc/adlresintest2/jta-data-source
   ...

Since the jta-data-source tag is part of the JPA spec, it should be 
recognized by eclipse-link.

-- Scott


 Thanks a lot.



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

Re: [Resin-interest] Getting java.lang.IllegalStateException....'0' is an unknown constant pool type when using hibernate and webbean in resin-pro-3.1.11 and resin-pro-3.1.12

[Scott Ferguson]

On 12/12/13, 3:31 PM, Jack Wang wrote:

Hello Scott,

This is Jack from Veeva system. We are licensed Resin application 
server user. I've posted this to the resin-interest mailing group a 
couple of days ago. The post is not approved yet, so I'm thinking of 
contacting you directly to see if I can get any help on the issue.


Hi Jack,

Since Resin 3.1.x is frozen, you should be working with Resin 4.0.x. The 
issue looks like an issue with class file changes since 1.5 (I'm not 
sure that the skip changes would affect that.)


If you're working with Resin 3.1, you may need to ignore the warning. It 
won't affect the actual operation of Resin.


-- Scott



We are developing an application using Resin-pro-3.1.12 server, the 
application starts to generate the following exception at server start 
after we begin to use hibernate/JPA and webbean in the application by 
adding the persistence.xml and web-beans.xml


The issue only happens when using Resin-pro-3.1.11 and 3.1.12. The 
application works fine in Resin-pro-3.1.10.


After digging and comparing the differences between resin-pro-3.1.10 
and resin-pro-3.1.11, I narrowed down the cause of the issue to be the 
following two extra lines added to the skip method in ReadStream.java 
in  resin-util.jar since version 3.1.11:


if (n = 0)
  return n;

Here is an sample exception caused by the above changes and it is 
happenning to almost every class and the constant pool type value in 
those exceptions are '0' and some negative values:


[2013-12-08 11:41:36.346] main failed scanning class 
/projects/proj1/path1/projname/target/projname/WEB-INF/classes/com/companyname/projname/module1/ClassModule$1.class
[2013-12-08 11:41:36.346] main 
java.lang.IllegalStateException: /projects/proj1/path1/projname/target/projname/WEB-INF/classes/com/companyname/projname/module1/ClassModule$1.class: 
'0' is an unknown constant pool type.
[2013-12-08 11:41:36.346] main 
java.lang.IllegalStateException: /projects/proj1/path1/projname/target/projname/WEB-INF/classes/com/companyname/projname/module1/ClassModule$1.class: 
'0' is an unknown constant pool type.
[2013-12-08 11:41:36.346] main at 
com.caucho.bytecode.ByteCodeClassScanner.error(ByteCodeClassScanner.java:274)
[2013-12-08 11:41:36.346] main at 
com.caucho.bytecode.ByteCodeClassScanner.parseConstantPool(ByteCodeClassScanner.java:175)
[2013-12-08 11:41:36.346] main at 
com.caucho.bytecode.ByteCodeClassScanner.scan(ByteCodeClassScanner.java:78)
[2013-12-08 11:41:36.346] main at 
com.caucho.loader.enhancer.ScanManager.scanForClasses(ScanManager.java:118)
[2013-12-08 11:41:36.346] main at 
com.caucho.loader.enhancer.ScanManager.scanForClasses(ScanManager.java:102)
[2013-12-08 11:41:36.346] main at 
com.caucho.loader.enhancer.ScanManager.scanForClasses(ScanManager.java:102)
[2013-12-08 11:41:36.346] main at 
com.caucho.loader.enhancer.ScanManager.scanForClasses(ScanManager.java:102)
[2013-12-08 11:41:36.346] main at 
com.caucho.loader.enhancer.ScanManager.scanForClasses(ScanManager.java:102)
[2013-12-08 11:41:36.346] main at 
com.caucho.loader.enhancer.ScanManager.scanForClasses(ScanManager.java:102)
[2013-12-08 11:41:36.346] main at 
com.caucho.loader.enhancer.ScanManager.scan(ScanManager.java:91)
[2013-12-08 11:41:36.346] main at 
com.caucho.loader.enhancer.ScanManager.scan(ScanManager.java:62)
[2013-12-08 11:41:36.346] main at 
com.caucho.loader.EnvironmentClassLoader.addScanListener(EnvironmentClassLoader.java:504)
[2013-12-08 11:41:36.346] main at 
com.caucho.amber.manager.AmberContainer.init(AmberContainer.java:160)
[2013-12-08 11:41:36.346] main at 
com.caucho.amber.manager.AmberContainer.create(AmberContainer.java:191)
[2013-12-08 11:41:36.346] main at 
com.caucho.amber.manager.AmberContainer.create(AmberContainer.java:179)
[2013-12-08 11:41:36.346] main at 
com.caucho.ejb.manager.EjbContainer.start(EjbContainer.java:473)
[2013-12-08 11:41:36.346] main at 
com.caucho.ejb.manager.EjbContainer.environmentStart(EjbContainer.java:548)
[2013-12-08 11:41:36.346] main at 
com.caucho.loader.EnvironmentClassLoader.start(EnvironmentClassLoader.java:588)
[2013-12-08 11:41:36.346] main at 
com.caucho.server.webapp.WebApp.start(WebApp.java:1837)
[2013-12-08 11:41:36.346] main at 
com.caucho.server.deploy.DeployController.startImpl(DeployController.java:667)
[2013-12-08 11:41:36.346] main at 
com.caucho.server.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.java:72)
[2013-12-08 11:41:36.346] main at 
com.caucho.server.deploy.DeployController.startOnInit(DeployController.java:549)
[2013-12-08 11:41:36.346] main at 
com.caucho.server.deploy.DeployContainer.start(DeployContainer.java:160)
[2013-12-08 11:41:36.346] main at 
com.caucho.server.webapp.WebAppContainer.start(WebAppContainer.java:659)
[2013-12-08 11:41:36.346] main at 
com.caucho.server.host.Host.start(Host.java:450)
[2013-12-08 11:41:36.346] main at 
com.caucho.server.deploy.DeployController.startImpl(DeployController.java:667)

Re: [Resin-interest] Can't use host-name in host?

[Scott Ferguson]

On 12/9/13, 2:57 PM, Rick Mann wrote:

I have Resin set up on my local machine to support development of a handful of 
web sites. In order to shorten startup times, I have the main resin.xml file 
include other config files:


Try host-alias instead.

I've added a bug report. I think what's happening is that the 
resin:import isn't getting evaluated when you expect. It's being saved 
until the Host is configured.


So it's evaluated too late to set the host-name, which is an early 
identifier like the id.


-- Scott



___
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] BAM/hmtp errors?

[Scott Ferguson]

On 12/9/13, 7:49 PM, Rick Mann wrote:

I'm trying to upgrade to 4.0.37, and transition all my old config over to the new thing. I 
only run a single instance of resin, so it's confusing, but I took the default files and 
just inserted my hostweb-app block into resin.xml. It seems to run, but I 
get a lot of the following. Is it something to worry about?


If you start while logging at the finer level, you'll see the 
command-line program try to connect to an existing watchdog and fail, 
before launching a new watchdog instance.


-- Scott



-

Dec 9, 2013 7:46:08 PM com.caucho.bam.client.OutboundMessageStream query
FINER: com.caucho.bam.RemoteConnectionFailedException: Cannot connect to 
http://127.0.0.1:6600/hmtp
   java.net.ConnectException: Connection refused
com.caucho.bam.RemoteConnectionFailedException: Cannot connect to 
http://127.0.0.1:6600/hmtp
   java.net.ConnectException: Connection refused
at com.caucho.hmtp.HmtpLinkFactory.open(HmtpLinkFactory.java:146)
at 
com.caucho.bam.client.OutboundMessageStream.getLink(OutboundMessageStream.java:165)
at 
com.caucho.bam.client.OutboundMessageStream.query(OutboundMessageStream.java:120)
at com.caucho.bam.packet.Query.dispatch(Query.java:86)
at 
com.caucho.bam.mailbox.MultiworkerMailbox$PacketProcessor.process(MultiworkerMailbox.java:408)
at 
com.caucho.bam.mailbox.MultiworkerMailbox$PacketProcessor.process(MultiworkerMailbox.java:394)
at 
com.caucho.env.actor.ValueActorQueue$ValueItemProcessor.process(ValueActorQueue.java:183)
at 
com.caucho.env.actor.ValueActorQueue$ValueItemProcessor.process(ValueActorQueue.java:161)
at 
com.caucho.env.actor.ActorQueue$ActorConsumer.doConsume(ActorQueue.java:453)
at 
com.caucho.env.actor.ActorQueue$ActorConsumer.consumeAll(ActorQueue.java:406)
at 
com.caucho.env.actor.ActorQueue$ActorConsumer.access$300(ActorQueue.java:340)
at 
com.caucho.env.actor.ActorQueue$ActorWorker.runTask(ActorQueue.java:555)
at 
com.caucho.env.thread2.AbstractTaskWorker2.run(AbstractTaskWorker2.java:240)
at com.caucho.env.thread2.ResinThread2.runTasks(ResinThread2.java:173)
at com.caucho.env.thread2.ResinThread2.run(ResinThread2.java:118)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at 
com.caucho.remote.websocket.WebSocketClient.connectImpl(WebSocketClient.java:180)
at 
com.caucho.remote.websocket.WebSocketClient.connect(WebSocketClient.java:130)
at 
com.caucho.remote.websocket.WebSocketClient.connect(WebSocketClient.java:121)
at com.caucho.hmtp.HmtpLinkFactory.open(HmtpLinkFactory.java:138)
... 14 more
Dec 9, 2013 7:46:08 PM com.caucho.bam.BamError create
FINER: com.caucho.bam.RemoteConnectionFailedException: Cannot connect to 
http://127.0.0.1:6600/hmtp
   java.net.ConnectException: Connection refused
com.caucho.bam.RemoteConnectionFailedException: Cannot connect to 
http://127.0.0.1:6600/hmtp
   java.net.ConnectException: Connection refused
at com.caucho.hmtp.HmtpLinkFactory.open(HmtpLinkFactory.java:146)
at 
com.caucho.bam.client.OutboundMessageStream.getLink(OutboundMessageStream.java:165)
at 
com.caucho.bam.client.OutboundMessageStream.query(OutboundMessageStream.java:120)
at com.caucho.bam.packet.Query.dispatch(Query.java:86)
at 
com.caucho.bam.mailbox.MultiworkerMailbox$PacketProcessor.process(MultiworkerMailbox.java:408)
at 
com.caucho.bam.mailbox.MultiworkerMailbox$PacketProcessor.process(MultiworkerMailbox.java:394)
at 
com.caucho.env.actor.ValueActorQueue$ValueItemProcessor.process(ValueActorQueue.java:183)
at 
com.caucho.env.actor.ValueActorQueue$ValueItemProcessor.process(ValueActorQueue.java:161)
at 
com.caucho.env.actor.ActorQueue$ActorConsumer.doConsume(ActorQueue.java:453)
at 
com.caucho.env.actor.ActorQueue$ActorConsumer.consumeAll(ActorQueue.java:406)
at 
com.caucho.env.actor.ActorQueue$ActorConsumer.access$300(ActorQueue.java:340)
at 
com.caucho.env.actor.ActorQueue$ActorWorker.runTask(ActorQueue.java:555)
at 
com.caucho.env.thread2.AbstractTaskWorker2.run(AbstractTaskWorker2.java:240)
at com.caucho.env.thread2.ResinThread2.runTasks(ResinThread2.java:173)
at com.caucho.env.thread2.ResinThread2.run(ResinThread2.java:118)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at 

Re: [Resin-interest] Hot Deploy

[Scott Ferguson]

On 11/6/13 1:37 PM, Aaron Freeman wrote:
 Is there a very current set of the documentation found here:
 http://blog.caucho.com/2009/01/29/remote-deploy-in-resin-part-2/

 I don't know anything about hot deploying, let alone Resin or Eclipse's
 capabilities for doing so, and I just want to make sure I am using the
 absolute latest documentation while I try to chug through it.   I am using
 the latest Eclipse, the latest resin plugin, and the latest Resin 4.0
 version.
It should be the same. Internally, we have updated the deployment 
protocol, but I believe the eclipse plugin uses the Resin command-line 
for the actual interface, so it should update to protocol changes 
automatically.

-- Scott

 Thanks,

 Aaron


 ___
 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] CpuHealthCheck cpu1=99% while top shows 72% idle

[Scott Ferguson]

On 10/22/13 1:06 AM, Riccardo Cohen wrote:
 Hello

 I run some process on a server (debian 6.0.7 - 64b - 4 cores), that read
 files and insert data into db. When running top tool I have 60% to 90%
 processor idle. The rest is mainly iowait which seems natural since the
 disk is working a lot in this process (through file read and mysql write).

 Resin Pro 4.0.13 is running and answering http requests in the same
 time. During this process, Resin shows some warnings in the log :

 CpuHealthCheck: WARNING:  cpu1=99%

 I don't understand, since top show that processor is mainly idle.
 Can someone help me explain this please ?  Is there another way to
 control CPU, more precise than top ?

top and Resin should be measuring the same thing. Both are looking at 
the /proc filesystem for CPU counts. Resin averages over its 60s 
interval, so a cpu showing 99% over 60s is a busy cpu.

Normally, I believe top reports the average across all the CPUs. So if 
you had a single CPU that was very busy, Resin might report that 
warning, even though it's expected.

-- Scott


 Thanks a lot.



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

Re: [Resin-interest] pdf snapshot with 4.0.37

[Scott Ferguson]

On 9/26/13 9:58 AM, Riccardo Cohen wrote:
 Hi
 I'm migrating testing 4.0.37 and begin a serie of tests.

 I noticed that at each restart, it generates a 500kb pdf in
 resinpath/log folder. I tried to modify health.xml and looked at many
 pages of the doc, but could not find how to stop this

It's in the health.xml. It's the PdfReport command at the bottom with 
the health:OnRestart/ qualifier. You can comment out that command.

In production, it's a very handy report, because it will contain the 
graphs plus any thread dump/heap dump on a failure.

-- Scott


 Thanks for any help.



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

Re: [Resin-interest] JSF classloader leak triggered by Resin EL

[Scott Ferguson]

On 7/18/13 2:32 AM, Mattias Jiderhamn wrote:
 It seems that a classloader leak in the JSF API as of
 https://java.net/jira/browse/JAVASERVERFACES-2746 is triggered much more
 easily by the Caucho EL implementation than with the Sun/Glassfish one.
 At least from my point of view the bug still is with JSF and not Resin,
 but somene might find this information useful.


Hmm. I'm not sure why Resin's EL would make a difference. From that 
description, it's
a JSF bug.

Do you happen to know what classes are being held?

(The issue is a static WeakHashMap in the JSF implementation, with a 
strong reference to a web-app class in the value.)

-- Scott


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

Re: [Resin-interest] JSF classloader leak triggered by Resin EL

[Scott Ferguson]

On 7/18/13 10:29 AM, Mattias Jiderhamn wrote:
 On Thu, 18 Jul 2013 09:42:23 -0700 Scott wrote:
 On 7/18/13 2:32 AM, Mattias Jiderhamn wrote:
 It seems that a classloader leak in the JSF API as of
 https://java.net/jira/browse/JAVASERVERFACES-2746 is triggered much
 more
 easily by the Caucho EL implementation than with the Sun/Glassfish one.
 At least from my point of view the bug still is with JSF and not Resin,
 but somene might find this information useful.
 Hmm. I'm not sure why Resin's EL would make a difference. From that
 description, it's a JSF bug.

 Do you happen to know what classes are being held?
 Yes. The bug is triggered when there are additional attributes added to
 the cached PropertyDescriptors, that implies a strong reference to the
 classloader. The cases I've seen involves having the
 javax.el.ELResolver.TYPE (=type) attribute having a class loaded
 within the webapp as it's value (i.e. a custom JSF component with a
 custom attribute). Resin adds this attribute in BeanELResolver.java line
 520 (Resin 4.0.33), reached from the
 javax.el.BeanELResolver.BeanProperty constructors in turn called from
 the javax.el.BeanELResolver.BeanProperties constructor which in the
 Resin case is used in all five BeanELResolver methods mentioned in my
 latest comment.

 In the case of Sun/Glasfish EL, this attribute is (AFAI can see) only
 added by getFeatureDescriptors().

 Nevertheless, I agree that it is JSF that needs fixing, not Resin.

Gotcha.

I can make that initialization lazy. That will only initialize the 
reference for getFeatureDescriptors().

-- Scott





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

Re: [Resin-interest] already a root application context present

[Scott Ferguson]

On 7/8/13 12:38 PM, Rick Mann wrote:
 On Jul 8, 2013, at 09:43 , Scott Ferguson f...@caucho.com wrote:

 On 7/6/13 4:54 PM, Rick Mann wrote:
 I'm still getting this error with resin-4.0-36. It seems benign, in that 
 the app continues to run, but I'd like to know what I'm doing wrong.
 I've added a bug report. I'll see if there's some double scanning or
 double initializing.

 It's behaving as if there were two spring jars in the WEB-INF/lib. (I'm
 sure there's not, but the behavior seems to be the same as if that was
 happening.)
 It's entirely possible I did something wrong. I don't have a web.xml any 
 more, but I might have some annotation wrong. I still don't fully understand 
 how that's all supposed to work. Here's every *spring* file in my WEB-INF/lib 
 dir:

Thanks. Unless you had two copies of the jars, I don't think it would be 
a problem on your end.

-- Scott


 ./WEB-INF/lib/org/springframework/security/spring-security-core/3.1.3.RELEASE/spring-security-core-3.1.3.RELEASE.jar
 ./WEB-INF/lib/org/springframework/spring-aop/3.2.0.RC2/spring-aop-3.2.0.RC2.jar
 ./WEB-INF/lib/org/springframework/spring-beans/3.2.0.RC2/spring-beans-3.2.0.RC2.jar
 ./WEB-INF/lib/org/springframework/spring-context/3.2.0.RC2/spring-context-3.2.0.RC2.jar
 ./WEB-INF/lib/org/springframework/spring-core/3.2.0.RC2/spring-core-3.2.0.RC2.jar
 ./WEB-INF/lib/org/springframework/spring-expression/3.2.0.RC2/spring-expression-3.2.0.RC2.jar
 ./WEB-INF/lib/org/springframework/spring-jdbc/3.2.0.RC2/spring-jdbc-3.2.0.RC2.jar
 ./WEB-INF/lib/org/springframework/spring-orm/3.2.0.RC2/spring-orm-3.2.0.RC2.jar
 ./WEB-INF/lib/org/springframework/spring-test/3.2.0.RC2/spring-test-3.2.0.RC2.jar
 ./WEB-INF/lib/org/springframework/spring-tx/3.2.0.RC2/spring-tx-3.2.0.RC2.jar
 ./WEB-INF/lib/org/springframework/spring-web/3.2.0.RC2/spring-web-3.2.0.RC2.jar
 ./WEB-INF/lib/org/springframework/spring-webmvc/3.2.0.RC2/spring-webmvc-3.2.0.RC2.jar

 The Resin installation is fresh; no extra libs in there.

 -- Scott

 [13-07-06 16:52:02.422] INFO com.caucho.server.webapp.WebApp log: 
 WebApp[production/webapp/default/ROOT,STARTING] Spring 
 WebApplicationInitializers detected on classpath: 
 [com.latencyzero.gamecenter.web.WebappInitializer@7c739ebd]
 [13-07-06 16:52:02.456] INFO com.caucho.server.webapp.WebApp log: 
 WebApp[production/webapp/default/ROOT,STARTING] Initializing Spring root 
 WebApplicationContext
 [13-07-06 16:52:03.931] WARNING com.caucho.server.webapp.WebApp startImpl: 
 java.lang.IllegalStateException: Cannot initialize context because there is 
 already a root application context present - check whether you have 
 multiple ContextLoader* definitions in your web.xml!
 at 
 org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:264)
 at 
 org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:112)
 at 
 com.caucho.server.webapp.WebApp.startImpl(WebApp.java:3677)
 at 
 com.caucho.server.webapp.WebApp$StartupTask.run(WebApp.java:5196)
 at 
 com.caucho.env.thread2.ResinThread2.runTasks(ResinThread2.java:173)
 at 
 com.caucho.env.thread2.ResinThread2.run(ResinThread2.java:118)


 ___
 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] already a root application context present

[Scott Ferguson]

On 7/6/13 4:54 PM, Rick Mann wrote:
 I'm still getting this error with resin-4.0-36. It seems benign, in that the 
 app continues to run, but I'd like to know what I'm doing wrong.

I've added a bug report. I'll see if there's some double scanning or 
double initializing.

It's behaving as if there were two spring jars in the WEB-INF/lib. (I'm 
sure there's not, but the behavior seems to be the same as if that was 
happening.)

-- Scott


 [13-07-06 16:52:02.422] INFO com.caucho.server.webapp.WebApp log: 
 WebApp[production/webapp/default/ROOT,STARTING] Spring 
 WebApplicationInitializers detected on classpath: 
 [com.latencyzero.gamecenter.web.WebappInitializer@7c739ebd]
 [13-07-06 16:52:02.456] INFO com.caucho.server.webapp.WebApp log: 
 WebApp[production/webapp/default/ROOT,STARTING] Initializing Spring root 
 WebApplicationContext
 [13-07-06 16:52:03.931] WARNING com.caucho.server.webapp.WebApp startImpl: 
 java.lang.IllegalStateException: Cannot initialize context because there is 
 already a root application context present - check whether you have multiple 
 ContextLoader* definitions in your web.xml!
   at 
 org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:264)
   at 
 org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:112)
   at 
 com.caucho.server.webapp.WebApp.startImpl(WebApp.java:3677)
   at 
 com.caucho.server.webapp.WebApp$StartupTask.run(WebApp.java:5196)
   at 
 com.caucho.env.thread2.ResinThread2.runTasks(ResinThread2.java:173)
   at 
 com.caucho.env.thread2.ResinThread2.run(ResinThread2.java:118)



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

Re: [Resin-interest] start stop resin 4.0.13 on mac with java 1.6.0_51

[Scott Ferguson]

On 6/26/13 12:38 AM, Riccardo Cohen wrote:
 Hello
 For information :

 Since last Apple java update, launching and stopping resin from
 terminal, opens an interactive application (with icon and menu) for
 several seconds, with name com.caucho.boot.ResinBoot.

 I added -Djava.awt.headless=true -Djava.awt.headlesslib=true in
 resin.sh (after exec $JAVA_EXE) and it solved the problem.

Thanks. I've filed this. Resin should already be setting 
java.awt.headless, but not the headlesslib.

-- Scott


 Thanks to add this in future release if not already done.



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

Re: [Resin-interest] Hessian between servers on different versions of Resin

[Scott Ferguson]

On 6/7/13 9:35 AM, Alan Wright wrote:
 Hi

 We are sending messages using hessian from our server to another server.

 When both servers were on Resin 2.1.17 all was OK.

 We have since upgraded to Resin 4.0.36 on our server (when will the 4.1
 series come out by the way?)

Hmm. I'm not sure. We've been working on getting a usable 7.0.0 out.


 Now the client code no longer works - throwing the following error on
 our server (the client) at the point where the remote method is invoked.

 I am I doing something stupid expecting the 2 to communicate. Is it
 possible to get a Hessian 2 client to talk to a hessian 1 server?

I'm not sure about 2.1.17. It's very old.

Hessian 2/1 are designed to interoperate (basically the caller sends at 
Hessian 1 call with a note that it can upgrade to Hessian 2.)

-- Scott


 com.caucho.hessian.client.HessianRuntimeException:
 com.caucho.hessian.io.HessianProtocolException: '
 ' is an unknown code
   at
 com.caucho.hessian.client.HessianProxy.invoke(HessianProxy.java:222)
   at $Proxy0.addRegistrant(Unknown Source)
   at
 com.athene.jaffa.xbatch.admin.MarketMakerTransferXBatch.main(MarketMakerTransferXBatch.java:77)
 Caused by: com.caucho.hessian.io.HessianProtocolException: '
 ' is an unknown code
   at
 com.caucho.hessian.client.HessianProxy.invoke(HessianProxy.java:220)
   ... 2 more



 Thanks



 Alan



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

Re: [Resin-interest] 4.0.35 works great locally on OS X, slightly busted on Rackspace Ubuntu 12.04

[Scott Ferguson]

On 4/8/13 7:37 PM, Rick Mann wrote:
 I have a server that's completely annotation-driven, and it was mostly 
 working on .33, but .35 fixes an issue I had with mappings. Now it works 
 perfectly locally on my OS X laptop, but when I run it on the server, 
 everything seems to load except some resources under /css, which come back as 
 404.

 I get errors like this in the log:

 19:32:14.099 WARN  servlet.DispatcherServlet (DispatcherServlet.java:1108) No 
 mapping found for HTTP request with URI [/css/tt.css] in DispatcherServlet 
 with name 'dispatcher'
 19:32:14.102 WARN  servlet.DispatcherServlet (DispatcherServlet.java:1108) No 
 mapping found for HTTP request with URI [/css/foundation.css] in 
 DispatcherServlet with name 'dispatcher'

That's not a Resin message (I just searched to make sure), so I'm not 
sure what the context is.

 From that getServletMappings() method, I'm wondering if you've 
overridden the default servlet.

If you have, then it makes sense that Resin is no longer service static 
files like css, because your servlet has taken over for Resin's default 
servlet (resin-file).

-- Scott



 It's very nearly an out-of-box installation. The only differences I can think 
 of:

 - on OS X, I didn't run configure/make/make install. On Ubuntu I did. On OS 
 X, I just unzipped and dragged to the install location.

 - on OS X, resin.properties is more stock, without an admin user, no setuid 
 user/group, port 8080.

 As to the dispatcher servlet, getServletMappings looks like this:

  protected
  java.lang.String[]
  getServletMappings()
  {
  String[] mappings = { / };
  return mappings;
  }

 I have a Spring controller at /service/* that works great.

 Just stuff under /css is 404. Any ideas?



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

Re: [Resin-interest] calling JspServlet instance directly

[Scott Ferguson]

On 3/21/13 10:51 AM, Riccardo Cohen wrote:
 Hello
 I'm refactoring my url requests processing and need some advice. I've
 learnt mostly by myself, and I'm not sure to make the good choices.

 Presently my request processing is a mixing of servlet configurations like :

 servlet-mapping url-pattern=*.jsp servlet-name=resin-jsp/
 servlet-mapping url-pattern=/fr/* servlet-name=urlmanager/

 and some java code in UrlManager.java servlet, analysing the url
 request, processing the request, and calling at the end :

 req.getRequestDispatcher(/page.jsp).forward(req,res);



 QUESTION 1:

 When I call req.getRequestDispatcher(/page.jsp).forward(req,res); this
 goes through a certain process depending on resin.xml conf (first line
 above), analysing the pseudo-request /page.jsp, and finally calling
 service() of the instance of com.caucho.jsp.JspServlet created by resin.
 I was wondering how to call directly the JspServlet instance myself ? It
 would be much quicker because I know this is a jsp page (systematic
 final step of the processing).

Since all that processing is cached, the cost is really just a hash map 
lookup, which
probably isn't noticeable.

You could also use ServletContext.getRequestDispatcher(...) in an 
init() method (or lazily) and save the RequestDispatcher object. The 
RequestDispatcher is reusable.

So calling directly shouldn't actually be a measurable gain.


 QUESTION 2

 What I would like is having a better control on requests, by gathering
 all the processing in one point, not half configuration, half java code.
 My solution would be to have all requests handled by my unique
 urlmanager servlet, and I would dispatch them myself with built-in resin
 servlets. Any suggestion will be appreciated, as long as performance is
 very good.

Someone else would be in a better position to answer, but that sounds 
like a reasonable
architecture to me.

-- Scott


 I must say I'm a bit afraid of these big frameworks like spring/struts
 that brings many features that already exists in Resin, like
 persistency, tag library, dependency injection etc. One of the reason I
 like resin, apart from performances, is that there is everything in it.

 Thanks for your help.



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

Re: [Resin-interest] custom component providers for injection

[Scott Ferguson]

On 2/27/13 11:36 AM, Olaf Krische wrote:
 3)

 Do i really have to write explicitly, what MyFactory can produce? I have
 hundreds of components in my provider, that potentially could be used.

 I would like to be able to define a chain, like, look first in my own
 ComponentProvider, and then maybe lookup somewhere else.
 Did not find a solution for that one yet. I can give my produce method an 
 InjectionPoint to get more info about the context, but i still have to create 
 a produce method for each type to produce.

 Any ideas?

You could use the extension mechanism. I'm not sure if there's a good 
tutorial. It's a bit more complicated
than basic CDI use. (And I'm not sure I can quickly explain it here.)

-- Scott

 Nice tutorial by the way:

 - 
 http://code.google.com/p/jee6-cdi/wiki/DependencyInjectionAnIntroductoryTutorial_Part1

 ___
 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 Pro 4.0.34 with Eclipselink 2.4.0.v20120608-r11652 - @Inject UserTransaction null

[Scott Ferguson]

On 2/24/13 2:54 PM, c.whalley wrote:
 On 24/02/2013 17:21, Scott Ferguson wrote:
 On 2/24/13 2:06 AM, c.whalley wrote:
 On 24/02/2013 05:49, Dan Ziegelbein wrote:
 The reason you're getting NPE's is that your instances of APICommand are
 not themselves injected by the container (you are instantiating them in
 code somewhere...indicated by the fact that APICommand has a
 non-injected parameterized constructor).

 Dan
 Hi Dan  thanks for this,

 I looked more at this and realised I need to do as you say, and it seems
 I need Webbeans and the @Component annotation, plus token
 META-INF/web-beans.xml to mark it as so? If that's right, I'm now
 struggling to even get the @Component to resolve - does the webbeans
 package come with Resin or is it an external download?
 For Resin 4.0, it's CDI and all the names changed:

 the magic file in META-INF/beans.xml in a jar or WEB-INF/beans.xml for
 the WEB-INF/classes. The smallest content of that file beans/.

 You don't need an annotation on the bean, but you can use something like
 @javax.inject.Singleton if you want it to be a single instance. The
 default behavior instantiates a new instance of your bean at each
 @Inject point.

 -- Scott
 Umm ... I hope I read you right - I just added beans.xml to WEB-INF with
 just beans/ as its content and that ut is still null.
 I did change it slightly from the code I posted earlier to ensure it
 really is a bean, in case that was significant:

How are you instantiating APICommand?

For example, are you injecting it into your servlet?

If you used new APICommand(), CDI wouldn't be invoked, because it's 
not doing that kind of bytecode generation on the constructor.

Two general patterns are:
   @Inject APICommand _command; // injecting into another bean
   @Inject InstanceAPICommand _factory; // creates a factory to return 
new instances

-- Scott

 public class APICommand implements Serializable {
   private static final long serialVersionUID = 1L;
   private static final Logger log =
 Logger.getLogger(APICommand.class.getName());

   @PersistenceUnit(unitName=my_persistence_unit)
   private EntityManagerFactory emf;

   @Inject
   private UserTransaction ut;
   private EntityManager em;
 ...
   private void update(User user) {
   try {
   ut.begin();
   em = emf.createEntityManager();
 ...
   }
 }

 -- Carl Whalley

 ___
 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] custom component providers for injection

[Scott Ferguson]

On 2/24/13 2:06 PM, Olaf Krische wrote:
 Hello,

 by the way, about injection, is there an tutorial out there on how to
 bind custom component providers to Resin's CDI? For example, i use
 picocontainer and i would like to have Resin ask picocontainer as well
 (mostly singletons)

 For Jersey, which also uses Injection, i have created a bridge, so that
 it can ask picocontainer, which is stored in the servlet context.

@Produces is probably what you need. You can create a factory/bridge class
to return CDI objects. Resin itself does this for the predefined objects.

@Singleton
public class MyFactory {  // it doesn't have to be a @Singleton, but 
probably would be
   @Produces
   public static MyObject _myField; // you can use static methods

   @Produces
   public MyObject myBuilder() { ... } // or methods (I'd prefer methods)
}

MyFactory would need to know how to get the picocontainer objects.

-- Scott



 ___
 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 Pro 4.0.34 with Eclipselink 2.4.0.v20120608-r11652 - @Inject UserTransaction null

[Scott Ferguson]

On 2/24/13 2:06 AM, c.whalley wrote:
 On 24/02/2013 05:49, Dan Ziegelbein wrote:
 The reason you're getting NPE's is that your instances of APICommand are
 not themselves injected by the container (you are instantiating them in
 code somewhere...indicated by the fact that APICommand has a
 non-injected parameterized constructor).

 Dan
 Hi Dan  thanks for this,

 I looked more at this and realised I need to do as you say, and it seems
 I need Webbeans and the @Component annotation, plus token
 META-INF/web-beans.xml to mark it as so? If that's right, I'm now
 struggling to even get the @Component to resolve - does the webbeans
 package come with Resin or is it an external download?

For Resin 4.0, it's CDI and all the names changed:

the magic file in META-INF/beans.xml in a jar or WEB-INF/beans.xml for 
the WEB-INF/classes. The smallest content of that file beans/.

You don't need an annotation on the bean, but you can use something like 
@javax.inject.Singleton if you want it to be a single instance. The 
default behavior instantiates a new instance of your bean at each 
@Inject point.

-- Scott



 -- Carl Whalley

 ___
 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] mod_caucho again with resin4

[Scott Ferguson]

On 2/13/13 8:11 AM, Olaf Krische wrote:
 Hello again,


 app-0$ ./resinctl disable -server app-0

This is a case where Resin's load balancer is more capable than 
mod_caucho (we have some open bugs to upgrade it.)

mod_caucho primarily handles connection failures. It's not aware of 503's.

 app-0$ ./resinctl web-app-stop myapp

Currently, neither load balancer is precise enough to handle per-web-app 
disables (again, an open bug, although it might require Resin 7 for that 
enhancement because we're revamping the load balancing.)

 app-0$ ./resinctl stop

This should work with mod_caucho.

 Finally a change:

 - apache's /caucho-status: app-0 is getting red. Juhu.

 But still:

 - apache's access.log is full with 503 (why oh why its not going to app-1, 
 because)
 - app-1 almost gets almost gets no traffic.

We'll need to check on this. With the backend stopped, mod_caucho should 
failover to the existing servers.

If you're using the pre-fork model, though, it may take a number of 
requests before the Apache processes become aware of the closed server, 
because each process is independent.

-- Scott

 app-0$ ./resinctl start

 - app-0/1 slowly start get request again according to resin's access.log
 - in between i even start to see 404 in apache's log. Hm, this could be my 
 fault, though resin should not start to deliver, when the webapp is not fully 
 app.

 In any way, i am pretty lost.

 The only properties i have overwritten:

 dev_mode : false
 app_servers  : 172.17.32.4:6800 172.17.32.5:6800
 session_store : false
 remote_admin_enable : true
 web_admin_enable : true
 web_admin_external : true
 rest_admin_enable : true
 admin_user : admin
 admin_password : ...

 And i have put those two ResinConfigServer (config triad) into the 
 httpd.conf:

 ResinConfigServer 172.17.32.4 6800
 ResinConfigServer 172.17.32.5 6800

 Is anyone using mod_caucho in production and has no problems with it? Am i 
 missing something here? :-)

 Thanks!

 ___
 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] mod_caucho again with resin4

[Scott Ferguson]

On 2/13/13 9:31 AM, Olaf Krische wrote:
 Or in short:

 Whenever i disable or even stop a resin in a cluster, then i see a lot of 503 
 in apache's access.log. This should not happen. Why is that so? Why the other 
 servers do not take over?

For stopping, is this transient or permanent?


 And second: when i disable (not stop) a resin in a cluster, why caucho-status 
 still shows it in green as ok?

Because mod_caucho can still connect to the backend Resin. When Resin is 
disabled, it's still accepting connections; it's just returning 503s.

-- Scott
 ___
 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] Watchdog loglevel

[Scott Ferguson]

On 2/12/13 1:50 AM, Jens Dueholm Christensen wrote:


Hi

We're running Resin 3.1.11 (soon to be 3.1.12 in the next 
servicewindow) in our production environment, and a few days ago we 
had an app that was restarted several times by the watchdog -- with no 
apparent reason.


The watchdog-log contains this:

[2013/02/08 11:17:46.478] WatchdogProcess[Watchdog[results],1] 
stopping Resin


[2013/02/08 11:17:46.478] WatchdogProcess[Watchdog[results],2] 
starting Resin


[2013/02/08 11:20:37.256] WatchdogProcess[Watchdog[results],2] 
stopping Resin


[2013/02/08 11:20:37.256] WatchdogProcess[Watchdog[results],3] 
starting Resin


[2013/02/08 11:23:24.221] WatchdogProcess[Watchdog[results],3] 
stopping Resin


[2013/02/08 11:23:24.221] WatchdogProcess[Watchdog[results],4] 
starting Resin


There was a lot of regular and normal activity in our apps stdout-log 
before and inbetween all the restarts, but nothing that -- in our 
opinion -- should cause a restart by the watchdog. The JVM log has no 
mention of problems (performing CMS and young generation GC as 
expected) and load on the server was also low -- no automatic 
stacktraces were taken.




Well, remember that the watchdog itself doesn't normally shutdown Resin 
on errors. Resin exits itself and the watchdog just starts a new 
instance. (Resin 4.0 communicates the reason better to the watchdog 
through exit codes.)


So the problem is in the Resin instance itself.

Are there hs_err* files or something similar?

-- Scott


We have been running with the same resin configuration, app codebase 
and OS software-stack for a long time, so we are quite baffeled, as 
this struck us as lightning from a clear sky.


Is there any way of getting more verbose output about the watchdog and 
what it decides to do?


We tried setting logger name=com.caucho level=fine/ and 
restarting Resin completely (not just a restart of the JVM), but that 
did not seem to help.


Regards,

*Jens Dueholm Christensen
*Survey IT



___
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] which version of ActiveMQ works with Resin 3.1?

[Scott Ferguson]

On 2/12/13 1:07 PM, Sadhana Jain wrote:
 Hello,

 I was wondering if anyone has tried the latest version of ActiveMQ 5.x with
 Resin 3.1? Does Resin support only a particular version of ActiveMQ or will
 any version of ActiveMQ work with any version of Resin?

There shouldn't be a version dependency, particularly if you use the 
non-JCA version.

-- Scott


 Thank you,
 Sadhana


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

Re: [Resin-interest] Does Resin 4.0 support integration with ActiveMQ via JCA?

[Scott Ferguson]

On 2/6/13 10:09 AM, Sadhana Jain wrote:

Hello Resin Developers,

Could you please confirm if the ActiveMQ integration is supported and 
will work with Resin 4.0? I don't see any documentation on it and 
therefore am unable to figure out how to configure the jms queue in 
the resin-web.xml file. The old way (resin 3.x) of configuring it 
doesn't seem to work. Also, I am trying to find out how to get the 
sources for JMSQueue implementation so I can debug the issue myself. 
Could someone please help me?


I'll need to update the docs (and test with ActiveMQ). The example you 
gave used a very old draft of CDI (before it was called CDI.)


The injection annotation is @javax.inject.Inject.

Do you need JCA? (For example, for XA support.) If you don't, the 
non-JCA configuration would be simpler.


-- Scott


Thanks a lot,
Sadhana


___
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] Simple loadbalancing per mod_caucho, without using cluster-functionality in resin4

[Scott Ferguson]

On 1/21/13 11:14 AM, Olaf Krische wrote:
 Hi,

 with resin2 a setup to loadbalance was pretty simple:

   LoadModule caucho_module  modules/mod_caucho.so
   CauchoConfigFile /home/krische/resin/current/conf/resin.conf

 And resin.conf would contain N srun entries for N backend servers. Done.

 Even when resin.conf changes, mod_caucho would react accordingly. No restart 
 of apache was necessary.

 My question: is that possible in resin4 without using any fancy resin pro 
 functionality?

Since the resin.xml is now too flexible for a C-based parser to handle, 
the backend Resin does the parsing and then forwards the configuration 
on to mod_caucho.

So that's no longer possible.

 Because in the community edition i already fail to add N server into a 
 cluster/-configuration. Because thats only available in Resin Pro.

 And to add N CauchoHosts manually in the httpd.conf and reload the whole 
 apache is a pita. Also i need root-access for that.

 What would you guys recommend?

Well, we'd recommend buying a license, of course :)


 Or has anyone ever tried a different kind of loadbalancing than e.g. 
 mod_proxy on apache?

mod_proxy should work fine too. I think we added a session option to 
make sticky sessions easier for mod_proxy to handle.

-- Scott

 Thanks.

 ___
 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] System.getenv() behaves differently

[Scott Ferguson]

On 1/14/13 6:15 AM, Mattias Jiderhamn wrote:
 I have noticed that System.getenv() behaves differently on our different
 Linux servers.

 When running stand-alone Java applications there is no issue, but on at
 least one server the environment variables are inherited from the
 watchdog process to the Resin process, and on others they are not. This
 can be verified with -verbose when starting Resin.

 I cannot find any difference in the setup (startup script + config), but
 on the other hand I'm not sure what I should be looking for.
 Any ideas?

 (Resin version is 4.0.29)

Can you send a -verbose?

When the watchdog spawns Resin, the env is built using System.getenv() 
on the watchdog, and then a few overrides extend the environment 
(CLASSPATH, LD_LIBRARY_PATH).

-- Scott


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

Re: [Resin-interest] BEAST SSL Attack

[Scott Ferguson]

On 1/5/13 5:14 PM, Keith Fetterman wrote:

Hi Scott,

We need this too.

Can you try http://caucho.com/download/resin-pro-4_0-snap.tar.gz

The configuration is honor-cipher-ordertrue/honor-cipher-order in 
openssl.


-- Scott



Thanks,
Keith

On 1/2/2013 1:36 PM, Scott Ferguson wrote:

On 1/2/13 11:58 AM, Aaron Freeman wrote:


We have now been scanned and been found to be non-compliant due to 
lack of the ability to order ciphers.   Is there any timeframe we 
might expect even a snapshot to have this capability?




I'll see if I can get a snapshot this week.

-- Scott


Thanks,

Aaron

*From:*resin-interest-boun...@caucho.com 
[mailto:resin-interest-boun...@caucho.com] *On Behalf Of *Aaron Freeman

*Sent:* Wednesday, December 05, 2012 10:51 AM
*To:* 'General Discussion for the Resin application server'
*Subject:* Re: [Resin-interest] BEAST SSL Attack

Very good, I appreciate the feedback.

Thanks,

Aaron

*From:*resin-interest-boun...@caucho.com 
[mailto:resin-interest-boun...@caucho.com] *On Behalf Of *Paul Cowan

*Sent:* Wednesday, December 05, 2012 9:02 AM
*To:* General Discussion for the Resin application server
*Subject:* Re: [Resin-interest] BEAST SSL Attack

Hi Folks,

Resin does not support SSLHonorCipherOrder yet.  We already 
received a request from another customer and there is a feature 
request for this here:


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

This is an OpenSSL feature, not JSSE.  We'll be implementing it in 
an upcoming release.  Probably it will be in 4.0.44, as .43 is due 
for release soon.


Thanks,

Paul

On Dec 5, 2012, at 8:13 AM, Aaron Freeman wrote:

Knut,

Thanks a bunch for your reply.   I saw you referencing another email 
you sent, but this is the only one I saw come through the group.


At any rate, we are already using the cipher-suites feature, but in 
this case that's not enough.   They are telling us that we actually 
have to be able to prioritize the order that the suites are 
negotiated on the server side.  The only cipher suites guaranteed 
not to have the BEAST attack issue are ones that aren't wide-spread 
yet (TLSv1.1) however if we can put TLSv1.0 in a specific order that 
will suffice for PCI compliance.


This bug for Tomcat addresses the issue and gives good details about 
a directive, SSLHonorCipherOrder, that handles the 
problem:https://issues.apache.org/bugzilla/show_bug.cgi?id=53481


Any other ideas for Resin?

Aaron

*From:*resin-interest-boun...@caucho.com 
mailto:resin-interest-boun...@caucho.com[mailto:resin-interest-boun...@caucho.com]*On 
Behalf Of*Knut Forkalsrud

*Sent:*Tuesday, December 04, 2012 9:31 PM
*To:*General Discussion for the Resin application server
*Subject:*Re: [Resin-interest] BEAST SSL Attack

Actually, I got it wrong in my previous mail.  The feature should be 
working.


There is a ticket describing the feature: 
http://bugs.caucho.com/view.php?id=3593


On Tue, Dec 4, 2012 at 7:00 PM, Knut Forkalsrud 
knut-cau...@forkalsrud.org mailto:knut-cau...@forkalsrud.org wrote:


In the days of Resin2.1.4 and onwards 
http://www.caucho.com/resin-3.1/changes/changes-2.xtpthere was 
such a feature, however it seems to have lapsed.  I remember because 
there was a similar issue with MSIE 
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q305217.


I my good old copy of Resin 3.1.8 there are remains the feature.

If you bring up the source code for 
com.caucho.vfs.JsseSSLFactory.create(host, port)


you will find a block of code commented out.

Then there was a second incarnation where you could specify cipher 
suites.  That seems to have dies some time around Aug 2009 with the 
commit: 
https://github.com/mdaniel/svn-caucho-com-resin/commit/96de31370ffd0153eb45fc49725a9b796bc11224#modules/resin/src/com/caucho/vfs/JsseSSLFactory.java


I suspect you could get it going again if you have the fortitude to 
play around with Resin's source code and build your own.


Good luck,

Knut Forkalsrud

On Mon, Dec 3, 2012 at 7:53 AM, Aaron Freeman 
aaron.free...@layerz.com mailto:aaron.free...@layerz.com wrote:


SSL BEAST

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

===
Paul Cowan, Software Engineer
Caucho Technology
co...@caucho.com mailto:co...@caucho.com
http://blog.caucho.com
http://twitter.com/cauchoresin



___
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


--
-
Keith Fetterman  206-780-5670
Mariner Supply, inc.kfetter...@go2marine.com
http://www.go2marine.com

http://www.boatersline.com

Re: [Resin-interest] Easing Development

[Scott Ferguson]

On 1/3/13 2:21 PM, Rick Mann wrote:
 I typically work on web apps as a component of other projects. At any given 
 time on my local machine I've got three or four web apps that I rotate 
 through. To speed things up, I reconfigure resin.xml each time I switch to a 
 new one, so I don't have to wait for the others to start up. I run resin in 
 console mode to make it easy to kill and restart

 I find it a little cumbersome to go to resin.xml and uncomment one webapp 
 and comment out another. I'm wondering if I can't accomplish the same thing 
 by moving the webapp declarations to separate files in a known directory, 
 and just have resin.xml include all the files in that directory. That way, I 
 can just move the fragment files in and out of this enabled apps directory.

 So, I tried changing resin.xml to:

 cluster id=app
  !-- define the servers in the cluster --
  server-multi id-prefix=app- address-list=${app_servers} 
 port=6800/

  !-- the default host, matching any host name --
  host id= root-directory=/Projects/
  
  resin:import
  fileset dir=/config/resin/enabled
  include name=*.xml/
  /fileset
  /resin:import
 //

 and I'm trying to include a file that contains:

 web-app id=/ document-directory=MyApp/web/trunk/target/build
 ...
 /web-app

 But it doesn't like web-app at the top level. So I wrapped that in resin 
 tags, but it doesn't like that, either. Can I not do this?

You need to use host in this case.

The resin:import expects the current tag as the included top-level tag.

That way, your foo.xml could have multiple web-app items or other 
host children.

-- Scott
   


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

Re: [Resin-interest] BEAST SSL Attack

[Scott Ferguson]

On 1/2/13 11:58 AM, Aaron Freeman wrote:


We have now been scanned and been found to be non-compliant due to 
lack of the ability to order ciphers.   Is there any timeframe we 
might expect even a snapshot to have this capability?




I'll see if I can get a snapshot this week.

-- Scott


Thanks,

Aaron

*From:*resin-interest-boun...@caucho.com 
[mailto:resin-interest-boun...@caucho.com] *On Behalf Of *Aaron Freeman

*Sent:* Wednesday, December 05, 2012 10:51 AM
*To:* 'General Discussion for the Resin application server'
*Subject:* Re: [Resin-interest] BEAST SSL Attack

Very good, I appreciate the feedback.

Thanks,

Aaron

*From:*resin-interest-boun...@caucho.com 
[mailto:resin-interest-boun...@caucho.com] *On Behalf Of *Paul Cowan

*Sent:* Wednesday, December 05, 2012 9:02 AM
*To:* General Discussion for the Resin application server
*Subject:* Re: [Resin-interest] BEAST SSL Attack

Hi Folks,

Resin does not support SSLHonorCipherOrder yet.  We already received 
a request from another customer and there is a feature request for 
this here:


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

This is an OpenSSL feature, not JSSE.  We'll be implementing it in an 
upcoming release.  Probably it will be in 4.0.44, as .43 is due for 
release soon.


Thanks,

Paul

On Dec 5, 2012, at 8:13 AM, Aaron Freeman wrote:

Knut,

Thanks a bunch for your reply.   I saw you referencing another email 
you sent, but this is the only one I saw come through the group.


At any rate, we are already using the cipher-suites feature, but in 
this case that's not enough. They are telling us that we actually have 
to be able to prioritize the order that the suites are negotiated on 
the server side.  The only cipher suites guaranteed not to have the 
BEAST attack issue are ones that aren't wide-spread yet (TLSv1.1) 
however if we can put TLSv1.0 in a specific order that will suffice 
for PCI compliance.


This bug for Tomcat addresses the issue and gives good details about a 
directive, SSLHonorCipherOrder, that handles the 
problem:https://issues.apache.org/bugzilla/show_bug.cgi?id=53481


Any other ideas for Resin?

Aaron

*From:*resin-interest-boun...@caucho.com 
mailto:resin-interest-boun...@caucho.com[mailto:resin-interest-boun...@caucho.com]*On 
Behalf Of*Knut Forkalsrud

*Sent:*Tuesday, December 04, 2012 9:31 PM
*To:*General Discussion for the Resin application server
*Subject:*Re: [Resin-interest] BEAST SSL Attack

Actually, I got it wrong in my previous mail.  The feature should be 
working.


There is a ticket describing the feature: 
http://bugs.caucho.com/view.php?id=3593


On Tue, Dec 4, 2012 at 7:00 PM, Knut Forkalsrud 
knut-cau...@forkalsrud.org mailto:knut-cau...@forkalsrud.org wrote:


In the days of Resin2.1.4 and onwards 
http://www.caucho.com/resin-3.1/changes/changes-2.xtpthere was such 
a feature, however it seems to have lapsed.  I remember because there 
was a similar issue with MSIE 
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q305217.


I my good old copy of Resin 3.1.8 there are remains the feature.

If you bring up the source code for 
com.caucho.vfs.JsseSSLFactory.create(host, port)


you will find a block of code commented out.

Then there was a second incarnation where you could specify cipher 
suites.  That seems to have dies some time around Aug 2009 with the 
commit: 
https://github.com/mdaniel/svn-caucho-com-resin/commit/96de31370ffd0153eb45fc49725a9b796bc11224#modules/resin/src/com/caucho/vfs/JsseSSLFactory.java


I suspect you could get it going again if you have the fortitude to 
play around with Resin's source code and build your own.


Good luck,

Knut Forkalsrud

On Mon, Dec 3, 2012 at 7:53 AM, Aaron Freeman 
aaron.free...@layerz.com mailto:aaron.free...@layerz.com wrote:


SSL BEAST

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

===
Paul Cowan, Software Engineer
Caucho Technology
co...@caucho.com mailto:co...@caucho.com
http://blog.caucho.com
http://twitter.com/cauchoresin



___
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] java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file javax/servlet/ServletException

[Scott Ferguson]

On 12/14/12 1:41 AM, Rick Mann wrote:
 I've been working on this Spring-based webapp. It was originally a 
 servlet-2.5, XML-configured webapp that ran great under Resin and I had a 
 nice spring-test-mvc-based test class for it, and it all worked well.

 After upgrading it to servlet-3.0, and using only annotations to configure 
 (no XML!), the webapp works, but I can't get my test class to work. I'm 
 fairly sure I still haven't configured it correctly, but in the Spring forums 
 I'm being told that I'm linking against the javaee-web-api 6.0 jar, which 
 contains no implementation.

 While this is true, it was also true before the configuration changes. So the 
 guy (a fair expert on Spring) tells me it must be due to some JAR load order 
 difference that's causing the error to appear now. Thing is, in the test 
 environment, I don't have any part of resin involved. I don't know where else 
 I might be getting an implementation.

Try looking at System.getProperty(java.class.path). That might help 
track down the jar order.

jar order can sometimes be random, depending on how the classpath is built.

 The exception is

  [junit] java.lang.ClassFormatError: Absent Code attribute in method that 
 is not native or abstract in class file javax/servlet/ServletException
  [junit]  at java.lang.ClassLoader.defineClass1(Native Method)

That's a very strange error message.

It shouldn't even be possible with normal complication.

It seems to be saying that someone took a post-processor to a compiled 
class that stripped out parts of the .class file, specifically the 
Code attribute, which is the part of the .class file that contains the 
actual code for a method.

So whatever jar is containing that class is a weird/broken jar.

-- Scott
  ...
  [junit]  at 
 org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.determineCandidateConstructors(AutowiredAnnotationBeanPostProcessor.java:230)
  ...
  [junit]  at 
 org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:148)
  [junit]  at 
 org.springframework.test.context.web.ServletTestExecutionListener.setUpRequestContextIfNecessary(ServletTestExecutionListener.java:105)
  ...

 So, I'm just curious if anyone here can shed some light on how this can come 
 to be.

 Thanks!




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

Re: [Resin-interest] Resin 4.0.33 not dispatching servlet-3.0?

[Scott Ferguson]

On 12/13/12 3:56 AM, Rick Mann wrote:
 Hi guys.

 The .33 snapshot is instantiating my initializer correctly, and that code is 
 calling this:

  ServletRegistration.Dynamic registration = 
 servletContext.addServlet(servletName, dispatcherServlet);
  registration.setLoadOnStartup(1);
  registration.addMapping(new String[/]);

That behavior is part of the spec.

If the mapping already exists, the addMapping does nothing. It's not an 
override.

I've added a bug report so we might special case the Resin defaults 
somehow, so those are overridable.

-- Scott


 However, I don't see anything in the Caucho logging indicating that it 
 registered a servlet (not sure if there is anything). I did see this, which 
 doesn't seem right:

 [12-12-13 03:50:11.038] CONFIG com.caucho.server.dispatch.ServletMapper 
 addUrlMapping: servlet-mapping / - resin-file


 It also doesn't respond to a request for http://localhost:8080/. I see this 
 much:

 [12-12-13 03:50:22.636] FINER com.caucho.network.listen.TcpSocketLink 
 requestAccept: TcpSocketLink[id=http://*:8080-5,http://*:8080,INIT] 
 request-accept http://*:8080-5 (count=4, idle=3)
 [12-12-13 03:50:22.636] FINEST com.caucho.network.listen.TcpSocketLink 
 startThread: TcpSocketLink[id=http://*:8080-5,http://*:8080,INIT] start 
 thread resin-port-8080-22 (count=5, idle=4)
 [12-12-13 03:50:22.637] FINEST com.caucho.network.listen.TcpSocketLink 
 initSocket: TcpSocketLink[id=1,app-0] starting connection 
 TcpSocketLink[id=http://*:8080-1,http://*:8080,ACCEPT], total=5
 [12-12-13 03:50:22.637] FINER com.caucho.network.listen.TcpSocketLink 
 handleAcceptTaskImpl: TcpSocketLink[id=http://*:8080-1,http://*:8080,ACCEPT] 
 accept from [::1]:8080
 [12-12-13 03:50:22.645] FINE com.caucho.server.http.HttpRequest parseRequest: 
 Http[app-0, 1] GET / HTTP/1.1
 [12-12-13 03:50:22.645] FINE com.caucho.server.http.HttpRequest parseRequest: 
 Http[app-0, 1] Remote-IP: [::1]:8080
 [12-12-13 03:50:22.645] FINE com.caucho.server.http.HttpRequest parseHeaders: 
 Http[app-0, 1] Host: localhost:8080
 [12-12-13 03:50:22.645] FINE com.caucho.server.http.HttpRequest parseHeaders: 
 Http[app-0, 1] User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) 
 AppleWebKit/536.26.17 (KHTML, like Gecko) Version/6.0.2 Safari/536.26.17
 [12-12-13 03:50:22.645] FINE com.caucho.server.http.HttpRequest parseHeaders: 
 Http[app-0, 1] Accept: 
 text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
 [12-12-13 03:50:22.646] FINE com.caucho.server.http.HttpRequest parseHeaders: 
 Http[app-0, 1] DNT: 1
 [12-12-13 03:50:22.646] FINE com.caucho.server.http.HttpRequest parseHeaders: 
 Http[app-0, 1] Cache-Control: max-age=0
 [12-12-13 03:50:22.646] FINE com.caucho.server.http.HttpRequest parseHeaders: 
 Http[app-0, 1] Accept-Language: en-us
 [12-12-13 03:50:22.646] FINE com.caucho.server.http.HttpRequest parseHeaders: 
 Http[app-0, 1] Accept-Encoding: gzip, deflate
 [12-12-13 03:50:22.646] FINE com.caucho.server.http.HttpRequest parseHeaders: 
 Http[app-0, 1] Cookie: 
 __utma=111872281.1148524109.1354299737.1354304258.1355118330.3; 
 __utmz=111872281.1354299737.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none);
  JSESSIONID=aaaCemYsZ1z9x6D_VaoUt; uid=1; crucibleprefs1=D%3D1343201447093; 
 remember=rmann:0:cb76f8d95c02b5fae41a3fa0206a927c
 [12-12-13 03:50:22.647] FINE com.caucho.server.http.HttpRequest parseHeaders: 
 Http[app-0, 1] Connection: keep-alive
 [12-12-13 03:50:22.651] FINEST com.caucho.server.webapp.WebApp getRealPath: 
 real-path / - 
 /Users/rmann/Projects/Clients/RedBirdStudios/repo/web/trunk/target/build/
 [12-12-13 03:50:22.651] FINEST com.caucho.server.webapp.ServletContextImpl 
 getResourceAsStream: java.io.FileNotFoundException: 
 /Users/rmann/Projects/Clients/RedBirdStudios/repo/web/trunk/target/build/
   at 
 com.caucho.vfs.JniFilePathImpl.openReadImpl(JniFilePathImpl.java:402)
   at com.caucho.vfs.Path.openRead(Path.java:1149)
   at 
 com.caucho.server.webapp.ServletContextImpl.getResourceAsStream(ServletContextImpl.java:404)
   at 
 com.caucho.server.dispatch.ServletMapper.mapServlet(ServletMapper.java:252)
   at 
 com.caucho.server.webapp.WebApp.buildInvocation(WebApp.java:3906)
   at 
 com.caucho.server.webapp.WebAppContainer.buildInvocation(WebAppContainer.java:781)
   at 
 com.caucho.server.host.Host.buildInvocation(Host.java:752)
   at 
 com.caucho.server.host.HostContainer.buildInvocation(HostContainer.java:319)
   at 
 com.caucho.server.cluster.ServletService.buildInvocation(ServletService.java:1014)
   at 
 com.caucho.server.dispatch.InvocationServer.buildInvocation(InvocationServer.java:247)
   at 
 

Re: [Resin-interest] Resin 4.0.33 not dispatching servlet-3.0?

[Scott Ferguson]

On 12/13/12 12:49 PM, Rick Mann wrote:
 Okay, so it sounds like I'll have to go back to pre-3.0 configuration for the 
 foreseeable future.

 Hate to say it, because you guys do such great work, but it seems that as 
 currently implemented, resin can't be used as a servlet 3.0 container.

 Let me ask this: the only URL I really need to run through Spring's 
 DispatcherServet is /service/**. I had been running everything through it so 
 my Spring controllers could handle everything, but I don't need that right 
 now. Should I be able to register it for /service and get what I need?

Yep. You can use /* as well. It's only exact matches that are 
rejected, and / exactly matches the default file servlet.

 Also, is resin creating that ContextLoaderListener on its own?

I'm not sure what you mean.

-- Scott


 Sent from my iPhone

 On Dec 13, 2012, at 12:36, Scott Ferguson f...@caucho.com wrote:

 On 12/13/12 12:16 PM, Rick Mann wrote:
 On Dec 13, 2012, at 11:32 , Scott Ferguson f...@caucho.com wrote:

 That behavior is part of the spec.

 If the mapping already exists, the addMapping does nothing. It's not an
 override.
 Wait, really? In my web.xml, I used to have:
 ...
 And you're saying that the new hotness doesn't allow me to do that?
 Yep, the new spec feature works backwards from Resin's configuration
 behavior. (No, I don't know why they chose that definition.)

 Or is there a way to avoid the resin mapping?
 That's what the bug report would be. We'd have to add some kind of
 configuration or marker to let Resin's configuration be a lower priority.

 -- Scott



 ___
 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, EclipseLink, and Cache Coordination

[Scott Ferguson]

I've marked this as a bug at http://bugs.caucho.com/view.php?id=5291.

I'll need to lookup the message destination. Resin's JMS passes the TCK, 
but there might be some requirement that's not properly tested there.


your workaround sounds fine.

-- Scott


On 11/27/12 1:47 PM, Daniel B Ziegelbein wrote:

FYI, I got this working...kind of.

After getting past the JNDI issue (just had to set the JNDI name of 
the ClusterTopic and JmsConnectionFactory), I had a problem where 
EclipseLink would throw an exception upon receipt of a cache 
coordination message because the message's destination was null.


To make it work, I had to use a Message Driven Bean, inject an 
instance of ClusterTopic in that bean and explicitly set the message 
destination in the onMessage method of the MDB (setting it to the 
injected ClusterTopic instance). It doesn't seem right that the 
message destination is null, but if this is a legitimate work-around 
then I'm fine with it.


Can anyone shed more light on this? Is this a legitimate work-around?


Dan


On Nov 14, 2012, at 11:27 PM, Dan Ziegelbein wrote:

I am trying to figure out how to get EclipseLink's cache coordination 
working within a Resin cluster. I am trying to get it working using JMS.


So far I haven't been able to get past the JNDI lookup of the 
JmsConnectionFactory (which is failing).


Right now my knowledge on this subject is a shaky patchwork of 
tidbits from a bunch of google searches, and I'm hoping that I'm 
missing some simple configuration step. But, before getting into all 
that...Should I even be able to do this?


Currently using Resin Pro  4.0.23.

Thanks,

Dan
/
/
___
resin-interest mailing list
resin-interest@caucho.com mailto: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] Scaling Up

[Scott Ferguson]

On 11/8/12 6:11 PM, Rick Mann wrote:
 I've used Resin for 6 or 8 years now, ever since working at a company that 
 used it.

 I use it for a lot of little personal projects and web sites, nothing very 
 substantial. But there's a chance that something I did recently will grow, 
 and I'm looking at how to use Resin with Rackspace virtual hosts.

 I'm finding it hard to get through some of Caucho's concepts. How is a web 
 server different from an app server? Is a web server the same as a load 
 balancer? All my apps run completely self-contained on a single server, 
 talking to a MySQL instance running on the same machine, using Hibernate and 
 no special caching.

 I'm having a hard time quickly learning how to move from that environment to 
 the triad and elastic servers. Can I take the intermediate step of running 
 just two servers?

 How does load balancing work? I've only ever used a Big IP F5. Do I want to 
 bother with Rackspace's load balancers?

 Stuff like that. Is there a good introductory document (not just a set of 
 slides)? So far, everything I've read assumes a certain level of knowledge.

We're working on a video that should help.

In the meantime:

1) Basically, we start with a single server, just like you're using now. 
That's an app server because it runs your applications (it also serves 
static web requests of course.).

   app_servers : 127.0.0.1:6800

2) Now you either want or need a second app server, either because of 
load or memory or reliability. That would be two servers. The two 
servers would be the first two in the triad. The triad stuff happens 
automatically. The first servers in your list are triad members. In 
truth, you don't usually need to know about the triad, except you should 
take a little care to put them on different hardware for reliability.

   app_servers : 192.168.0.10:6800, 192.168.0.11:6800

(You can also put two Resin servers on one box. Just use the same IP and 
different ports, like 6801. We use this for testing all the time, and 
some people do that for reliability or better memory management on one 
machine.)

3) load balancing

But now there's a difficulty because some how the requests need to be 
shared across the multiple servers, so you need a load balancer of some 
sort.

Resin doesn't care what load balancer you use. We're trying to support 
whatever configuration you want, assuming that you have a better idea of 
how you want to balance your own load.

Resin's load balancer is mostly provided as an option for medium sites 
so you don't need to use a hardware load balancer, and because it's easy 
to configure. (Some sites even use a hardware load balancer in 
combination with Resin's load balancer.)

If you're using a non-Resin load balancer, just point it to the 2 
server's http ports.

If you're using Resin's load balancer, just add a web_server entry:

   web_servers : 192.168.1.10:6820

In this case, I put the load balancer on the first machine. That's a 
perfectly reasonable configuration for a smallish configuration.

Make sure all servers are using the same resin.xml and resin.properties. 
The entire point of Resin's design is to allow you to use a single 
configuration for your entire cluster.

4) Adding servers.

You can keep adding servers to the app_servers list. The first three are 
automatically the triad. You don't need to do anything special, but if 
you have different physical servers, it's a good idea to split them for 
reliability. As long as every server sees that app_servers, the load 
balancing will just work with the new servers.

5) web vs app tiers.

The idea of those two is to mirror the common Apache/Resin or 
nginx/Resin reverse proxy configuration where you replace Apache with 
another Resin. You can use that configuration even if you have one 
app-server. (Benefit is that it isolates the application from the actual 
network. The penalty is a bit of performance.)

The web tier is simple and more reliable because it's only serving 
HTTP requests and cached data. It also isolates the web from the app 
tier, because only the web tier needs to worry about things like flaky 
network connections.

When you're using Resin as a load balancer the web tier is the load 
balancer.

6) The triad.

Mostly, it's an internal Resin clustering concept.

The main purpose is to handle clustering for fairly large sites that 
have large variations in load where they want to add or drop servers 
frequently.

The triad servers are the reliable servers. You don't actually need 3. 
If you have 2, the 2 servers act as backups for each other. The key of 
the triad is that every other server: 4, 5, 6 can be can be added or 
dropped whenever you want without affecting things like clustered 
sessions or caching.

For example, you can configure 7 servers, and only have 3 live. Shut 
down the last 4 and the system just works. But _don't_ shut down the 
first 3, because that's the triad. That's really the only reason you 
need to know about the 

Re: [Resin-interest] Scaling Up

[Scott Ferguson]

On 11/8/12 7:17 PM, Rick Mann wrote:
 Thanks, Scott, I'll read through that more carefully shortly.

 One question. Do I set up one server with the multi-machine additions as you 
 show, and then just replicate the config file (and server, webapp, et al) 
 onto all the machines? I realize that may seem obvious, but I want to be sure.

Yes, all the servers will have the same configuration.
 Also, how do I get them to talk to each other via private interfaces? Or does 
 that happen magically with Rackspace?

Ah. I wasn't explicit about that. (You're right about assumptions.)

The IP addresses you put in app_servers and web_servers are *private* 
addresses. You shouldn't put public addresses in the app_servers and 
web_servers, if you have the option. If you have 1 machine, you should 
use 127.0.0.1, otherwise use the private IP.

I don't specifically know about Rackspace, but you might need to change 
the firewall settings so each server is allowed to connect to 6800. 
Amazon, for example, has a security group firewall, so only the servers 
in the security group are allowed to see 6800. Outside servers can't get 
to it. I'm sure Rackspace has something similar.

When you start Resin with start-all (or the /etc/init.d script), Resin 
will compare its own IP address with the configuration IP addresses in 
app_servers and web_servers and start itself as the local address. (Does 
that make sense?)
-- Scott

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

Re: [Resin-interest] Scaling Up

[Scott Ferguson]

On 11/8/12 7:39 PM, Rick Mann wrote:
 On Nov 8, 2012, at 19:28 , Scott Ferguson f...@caucho.com wrote:

 Yes, all the servers will have the same configuration.
 Okay, so, I can set one up with the config, make a snapshot of that machine, 
 then bring up more instances from that snapshot. I'll have to figure out how 
 to manage the IP addresses of the hosts that I bring up; might have to 
 manually edit the config file after they're brought up.
Yep.

If the IP addresses are random, like Amazon, Resin has a few tricks to 
help, but that's a complication that's not necessary if you can rely on 
an IP address.

 Similar question for elastic servers.

You do have to tweak the config for the first elastic server, but after 
that you can take a snapshot of the elastic server and just bring up 
lots of instances with the new snapshot without changing the configuration.

 Yes, I remember dealing with that on EC2, I'll figure out what 
 Rackspace does. I did find the two IPs, internal and external. One 
 thing that's becoming clear is what was listening on 6800 vs 80: 6800 
 is for internal communication among servers. Not sure if it's used in 
 the single-server case, but I understand. 

Exactly.

 When you start Resin with start-all (or the /etc/init.d script), Resin
 will compare its own IP address with the configuration IP addresses in
 app_servers and web_servers and start itself as the local address. (Does
 that make sense?)
 Yes, I think so.

 After I make some dinner I'll try to go through your original email and get a 
 couple servers running. The first server will be my load balancer, which will 
 hit itself and the other server. MySQL can sit on the first server (although 
 I imagine in that configuration, it might make sense for it to sit on the 
 other server, since the first has the added burden of being the load 
 balancer).

 Thanks! I'm rather excited to try running multiple machines, and see how 
 badly my code breaks.

Hopefully, it won't even notice :)

-- Scott





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

Re: [Resin-interest] Managing Tenured Memory in Resin

[Scott Ferguson]

On 10/30/12 10:14 AM, Keith Fetterman wrote:
 Hi Everyone,

 I could use a little help troubleshooting some messages in my
 jvm-default.log.  I am seeing a lot of the following messages in our
 Resin logs.  We are currently running Resin 4.0.23 Pro.

 INFO com.caucho.env.health.HealthService 
 MemoryTenuredHealthCheck[WARNING:0.48% free (10.127M free, 2097.152M max, 
 2087.025M used)]
 I did a bit of research this morning about adjusting tenured memory
 limits, but I didn't find anything specific to adjusting the value. Does
 anyone know what property I need to adjust?  I currently have the
 following Java settings in my resin.xml file:

As Knut said, that size should be plenty.

I'd look to see if you have some kind of memory leak. Take a look at 
either the heap section of Resin's PDF or /resin-admin. Specifically 
look for the ZombieClassLoaderMarker.

 jvm-arg-J-server/jvm-arg
  jvm-arg-J-d64/jvm-arg
  jvm-arg-Xms3000M/jvm-arg
  jvm-arg-Xmx3000M/jvm-arg
  jvm-arg-XX:MaxPermSize=250M/jvm-arg
 I could increase the -Xmx property, but I am wondering if there is a
 better property to tweak.

 I am also seeing the following warning messages:

 WARNING com.caucho.health.analysis.AnomalyAnalyzer AnomalyAnalyzer 
 JVM|Thread|JVM Blocked Count WARNING
 WARNING com.caucho.health.analysis.AnomalyAnalyzer AnomalyAnalyzer 
 JVM|Thread|JVM Runnable Count WARNING
 Does anyone have some advice on how to resolve these warnings?  I read
 the Resin documentation, but I didn't find something specific.

Again, take a look at the PDF report (or thread graphs at that time.)

If it's a little spike (2-3 threads), it's not a big problem, but if 
there are lots of threads in that spike you might have some kind of 
locking issue.

-- Scott


 Thanks for your help

 Keith



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

Re: [Resin-interest] Managing Tenured Memory in Resin

[Scott Ferguson]

On 10/30/12 4:23 PM, Keith Fetterman wrote:
 Thanks Scott,

 We are currently running 4.0.23 Pro.  I am getting ready to deploy
 4.0.32 Pro into production.  Do you think the reporting in 4.0.32 Pro is
 better and would help troubleshoot the problem?

It should be about the same. The 4.0.23 heap dump will show the same 
information. There are a few reporting changes in 4.0.32, but nothing major.

-- Scott


 Keith


 On 10/30/2012 02:04 PM, Scott Ferguson wrote:
 On 10/30/12 10:14 AM, Keith Fetterman wrote:
 Hi Everyone,

 I could use a little help troubleshooting some messages in my
 jvm-default.log.  I am seeing a lot of the following messages in our
 Resin logs.  We are currently running Resin 4.0.23 Pro.

 INFO com.caucho.env.health.HealthService 
 MemoryTenuredHealthCheck[WARNING:0.48% free (10.127M free, 2097.152M max, 
 2087.025M used)]
 I did a bit of research this morning about adjusting tenured memory
 limits, but I didn't find anything specific to adjusting the value. Does
 anyone know what property I need to adjust?  I currently have the
 following Java settings in my resin.xml file:
 As Knut said, that size should be plenty.

 I'd look to see if you have some kind of memory leak. Take a look at
 either the heap section of Resin's PDF or /resin-admin. Specifically
 look for the ZombieClassLoaderMarker.
 jvm-arg-J-server/jvm-arg
jvm-arg-J-d64/jvm-arg
jvm-arg-Xms3000M/jvm-arg
jvm-arg-Xmx3000M/jvm-arg
jvm-arg-XX:MaxPermSize=250M/jvm-arg
 I could increase the -Xmx property, but I am wondering if there is a
 better property to tweak.

 I am also seeing the following warning messages:

 WARNING com.caucho.health.analysis.AnomalyAnalyzer AnomalyAnalyzer 
 JVM|Thread|JVM Blocked Count WARNING
 WARNING com.caucho.health.analysis.AnomalyAnalyzer AnomalyAnalyzer 
 JVM|Thread|JVM Runnable Count WARNING
 Does anyone have some advice on how to resolve these warnings?  I read
 the Resin documentation, but I didn't find something specific.
 Again, take a look at the PDF report (or thread graphs at that time.)

 If it's a little spike (2-3 threads), it's not a big problem, but if
 there are lots of threads in that spike you might have some kind of
 locking issue.

 -- Scott

 Thanks for your help

 Keith

 ___
 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 4.0.30+ NotSerializableException: com.caucho.el.MethodExpr$MethodCall

[Scott Ferguson]

On 10/01/2012 08:05 AM, Mattias Jiderhamn wrote:
 Without having had time to look into it further, I'm wondering if anyone
 else has seen these exceptions moving from Resin 4.0.29 to 4.0.30 (same
 problem with 4.0.31 for us)? Any workaround?

I'm marking it as a bug. That structure is supposed to be a runtime 
cache, and not saved during serialization.

-- Scott


 Caused by: java.io.NotSerializableException:
 com.caucho.el.MethodExpr$MethodCall
   at
 java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
 ~[na:1.6.0_30]
   at
 java.util.concurrent.ConcurrentHashMap.writeObject(ConcurrentHashMap.java:1247)
 ~[na:1.6.0_30]
   at sun.reflect.GeneratedMethodAccessor160.invoke(Unknown Source)
 ~[na:na]
   at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 ~[na:1.6.0_30]
   at java.lang.reflect.Method.invoke(Method.java:597) ~[na:1.6.0_30]
   at
 java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1469)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
 ~[na:1.6.0_30]
   at
 com.sun.faces.facelets.el.TagValueExpression.writeExternal(TagValueExpression.java:186)
 ~[javax.faces-2.1.11.jar:2.1.11]
   at
 java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1429)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1398)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
 ~[na:1.6.0_30]
   at java.util.ArrayList.writeObject(ArrayList.java:570) ~[na:1.6.0_30]
   at sun.reflect.GeneratedMethodAccessor72.invoke(Unknown Source)
 ~[na:na]
   at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 ~[na:1.6.0_30]
   at java.lang.reflect.Method.invoke(Method.java:597) ~[na:1.6.0_30]
   at
 java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1469)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1346)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1154)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1346)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1154)
 ~[na:1.6.0_30]
   at
 java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
 ~[na:1.6.0_30]
   at java.util.HashMap.writeObject(HashMap.java:1001) ~[na:1.6.0_30]
   at sun.reflect.GeneratedMethodAccessor155.invoke(Unknown Source)
 ~[na:na]
   at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 ~[na:1.6.0_30]
   at java.lang.reflect.Method.invoke(Method.java:597) ~[na:1.6.0_30]
   at
 java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
 ~[na:1.6.0_30]
   at
 

Re: [Resin-interest] Tiles issues on 4.0.x

[Scott Ferguson]

On 09/24/2012 11:11 PM, Matt Pangaro wrote:

Hi all,
I'm working to try and diagnose some issues we're seeing with an 
existing application that's being moved from Resin 3.1.7a to Resin 4. 
So far we have tested on versions 4.0.20 and 4.0.31 and have seen the 
same issue.


The application uses Spring 3.0.4 and Struts 1.2.8 with Tiles. It 
currently uses c:import tags to insert tiles content in some cases, 
which worked fine in Resin 3.1.7a, but has caused exceptions in both 
Resin 4 versions. The error messages look something like:


[15:24:10,597] FATAL - Error ID: Error Msg:Unhandled exception 
'javax.servlet.jsp.JspException: ServletException in 
'/pages/tiles/page1.jsp': ServletException in 
'/tiles/search/search.jsp': c:import status code 401 recieved while 
serving /tiles/search/page2.jsp' for request '/admin/page'


As you can see, there's a  bunch of nesting going on. Using a 
jsp:include instead of the c:import clears up the issue, but we're 
trying to get to the root cause before we settle on a solution. We 
were hoping somebody else might have seen this.




Can you run this with a level=finer?

401 is an authentication issue. It's conceivable that some information 
isn't getting passed to the child request using c:import.


-- Scott


Thanks,
Matt Pangaro



___
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] Up-to-date remote deploy strategy

[Scott Ferguson]

On 09/20/2012 01:33 AM, Mattias Jiderhamn wrote:
 What is the current recommended approach for remote deploying from
 Hudson/Jenkins to recent Resin versions (4.0.29+)?
 It looks like the resin-maven-plugin [1] (which may have been
 preferable) has been abandoned? Latest version is 4.0.17 and does not
 seem to be working.
 Is command line deploy [2] the latest and greatest? What would be the
 recommended approach for invoking from Hudson/Jenkins?

Command line is the best. It's current and tested nightly as part of our 
automated testing.

The ant/maven was before we upgraded the CLI.

 exec-maven-plugin with exec:java or exec:exec?

Probably exec. On our .deb and .rpm install resinctl is installed in 
the normal search path, so exec would give the installed version.

 Is the same Resin version required on both machines?

Yes, it's a good idea. We have upgraded the communication several times.

-- Scott

 1: http://caucho.com/resin-4.0/admin/deploy-ant-maven.xtp
 2: http://caucho.com/resin-4.0/admin/deploy-command-line.xtp




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

Re: [Resin-interest] SSL redirect for specific web applications

[Scott Ferguson]

On 09/12/2012 11:46 AM, Matthew Serrano wrote:
I am trying to force all access to a specific web application to be 
secured under SSL. The documentation says:

resin xmlns=http://caucho.com/ns/resin;
 xmlns:resin=urn:java:com.caucho.resin
 
   cluster ...

   host ...
 ...
 resin:Redirect regexp=^ target=https://${host.name}  
https://$%7Bhost.name%7D
   resin:IfSecure value=false/
 /resin:Redirect
 ...
   /host
/resin
I have tried this in various forms and it does not force the security. 
Is there somewhere specific this needs to be placed or is there a new 
format for this directive? I am running resin-pro 4.0.29.


Can you send me an exact resin.xml? I'm trying to reproduce the problem 
here, but it's working for me.




Also, I import specific web-app definitions in resin.xml using 
resin:import to load things like database resources per application:



*MYAPP.XML (placed in webapps folder)*
host xmlns=http://caucho.com/ns/resin; 
xmlns:resin=http://caucho.com/ns/resin/core;



If I try to include the resin:Redirect directive in this imported 
file, I get an error:
'resin:Redirect' is an unknown property of 
'com.caucho.server.webapp.WebApp'.


The xmlns:resin is incorrect for myapp.xml. It needs to be 
urn:java:com.caucho.resin.


-- Scott

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

Re: [Resin-interest] JSP encoding issues

[Scott Ferguson]

On 08/27/2012 05:04 PM, Rick Mann wrote:
 Oh, I can also put that empty page directive at the end of my include file, 
 and it also triggers the correct behavior.

What, exactly isn't working? The parsing of the page? Or the 
content-type header?

I just created a filter and JSP to reproduce this, and in all cases the 
res.setCharacterEncoding or res.setContentType is passed through to the 
output.

-- Scott


 On Aug 27, 2012, at 16:39 , Rick Mann rm...@latencyzero.com wrote:

 I'm trying to serve everything UTF-8. To this end, I wrote a request filter 
 that sets the input and output encodings to UTF-8, and I've used that 
 successfully in the past. I've been able to avoid putting a page encoding 
 directive in each page.

 With resin 4.0.30, I'm seeing something odd. I only get the right behavior 
 if the JSP page as an extra %@ page % at the top somewhere. The actual 
 directive inside doesn't seem to matter. I had an import directive, but 
 tried it without one and still got the right behavior.

 I also have, before that, at %@ include directive, which must also be 
 present. It includes the following:

 %@ page contentType=text/html; charset=UTF-8 %

 Without that, the resulting encoding isn't correct, either.

 What's odd is the empty page directive required to make it work.

 Any ideas?

 -- 
 Rick




 ___
 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 4.0.30 is available

[Scott Ferguson]

On 08/23/2012 11:14 PM, Keith Fetterman wrote:

Hi Scott,

This is excellent news.

Will 4.1.0 be considered a stable release intended for production 
environments?  We're still running 4.0.23 because of problems in 
4.0.24 - 4.0.28


Yes, assuming no major problems are found in 4.0.30 in the next few weeks.

-- Scott



Thanks,
Keith


On 08/23/2012 05:12 PM, Scott Ferguson wrote:

Resin 4.0.30 is available for download at the usual:

http://caucho.com/download

Resin 4.0.30 is a release-candidate for 4.1.0. If no critical bugs 
are found after a few weeks, we'll promote it to 4.1.0.


As a note, the most recent Resin 4.0.x releases beat nginx (a fast 
C-based web server) in stress tests using autobench. We've published 
the results at


http://wiki4.caucho.com/NginX_1.2.0_versus_Resin_4.0.29_performance_tests

-- Scott



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


--
-
Keith FettermanDirect: 206-319-9434
Mariner Supply, Inc.   206-780-5670
http://www.go2marine.comkfetter...@go2marine.com

http://www.boatersline.com



___
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 hang

[Scott Ferguson]

On 08/01/2012 08:19 AM, Chen Bangzhong wrote:

Hi, All

We run resin 3.1.9 open source version in our production environment. 
The visit is about 5M visit/day per resin instance. We ran into the 
resin hang problem several times. We belive it is the same problem as 
bug 3509


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

All the threads are deadlocked and the number of threads is 
approaching the thread-max setting.


Is there any workaroud to bug 3509 except upgrade to 4.0? Is this bug 
fixed in resin 3.1 ? Can we disable access log to workaroud this problem?


Does your thread dump show the same place that it's blocking on as in 
that bug report? i.e. the access log.




Besides, what's the suggested thread-max for resin ? We set it to 
3000, is it too big? 


That's a good value.

If we set it to a lower value, what will happen if the concurrent 
requests exceeds the thread-max value?


In a normal situation, you shouldn't reach the thread-max ever. (Resin 
4.0.x enforces that better with a port-thread-max.)


If it hits thread max, Resin will queue new thread requests until one is 
idle.




Another observation is that when the problem arise, the number of 
threads is approaching the thread-max setting. I want to know under 
what condition will resin start a new thread?


There's a thread-idle-min value. When the number of idle threads drops 
below that value, Resin spawns a new one. That generally avoids any 
actual wait for a new thread to be spawned, because they're normally 
taken from the idle pool.




Our environment:

Jdk 1.6.21 on CentOS 5.3 64bit
Resin 3.1.9 open source version
-Xms 4G -Xmx 4G -Xmn 1200m

 jvm-arg-Xmn1200m/jvm-arg
  jvm-arg-Xms4000m/jvm-arg
  jvm-arg-Xmx4000m/jvm-arg
  jvm-arg-Xss128k/jvm-arg

  memory-free-min100M/memory-free-min
  thread-max3000/thread-max
  socket-timeout65s/socket-timeout
  keepalive-max250/keepalive-max
  keepalive-timeout10s/keepalive-timeout


These look fine.

-- Scott



thanks.




___
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] Db Pool freezes waiting on _pool (3.1.3)

[Scott Ferguson]

On 07/06/2012 11:47 AM, Knut Forkalsrud wrote:
You may want to keep track of the DB pool statistics.  Active versus 
maximum allocation counts.  If this is a connection leak you would 
notice the number of active connection creeping upwards until it 
reaches max and your freezing symptoms appear.


Also, which driver is this with? There's a specific synchronization 
problem with the mysql ConnectionPool driver that might be a problem.


And, for jstack, the thread that owns the lock/counter is more important 
than the threads waiting. If you can find the threads that are opening 
the connection (in the actual driver code), that would help track this down.


An upgrade might help, but it would depend on what's causing the problem.

-- Scott



Knut Forkalsrud



On Fri, Jul 6, 2012 at 5:51 AM, Steven Cassidy 
steven.cass...@gmail.com mailto:steven.cass...@gmail.com wrote:


Hi, I'm using resin-3.1.3 on a busy site. Periodically the site
freezes. A jstack on the server shows most threads in this state:

java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at com.caucho.jca.ConnectionPool.create(ConnectionPool.java:897)
- locked 0x2aaaba60be48 (a java.util.ArrayList)
at com.caucho.jca.ConnectionPool.allocatePool(ConnectionPool.java:779)
at com.caucho.jca.ConnectionPool.allocate(ConnectionPool.java:740)
at
com.caucho.jca.ConnectionPool.allocateConnection(ConnectionPool.java:551)
at com.caucho.sql.DataSourceImpl.getConnection(DataSourceImpl.java:65)
at com.caucho.sql.DBPool.getConnection(DBPool.java:669)

It looks like no thread ever gets notified and all wait indefinitely.
Resin generally restarts itself about 15 minutes later if left alone.
The database itself apppears idle during this time.

I wondered if this might be a known problem and if upgrading to 3.1.12
would help? I don't think the pool is full. I noticed a pool timing
issue was fixed in 3.1.10 (bug 3837) and the implementation of the
allocate method changed, but that wasn't directly related to freezing.
Perhaps we should just try it and see, but I figured I'd ask if this
was noted / known behavior.

Many thanks,
Steven

___
resin-interest mailing list
resin-interest@caucho.com mailto: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] Leap Second behaviour

[Scott Ferguson]

On 07/02/2012 06:28 AM, Jens Dueholm Christensen (JEDC) wrote:

Hi
I'm quite well aware that the base problem regarding leap seconds is 
not connected to Resin, but to JVM and OS.
However I saw some strange behaviour in the aftermatch, that might be 
interesting to clear up.
Normally we run Resin 3.1.12 without any specific configuration for 
stat-service.

This means a default sample-period of 60 seconds.
Because of this every 59th second this was logged:
[2012-07-01 02:14:59.000][02:14:59.000] StatService[] cpu-load=41.05
[2012-07-01 02:14:59.000][02:14:59.000] StatService[] cpu-load=41.05
[2012-07-01 02:14:59.000][02:14:59.000] StatService[] cpu-load=41.05
[2012-07-01 02:14:59.000][02:14:59.000] StatService[] cpu-load=41.05
[2012-07-01 02:14:59.000][02:14:59.000] StatService[] cpu-load=41.05
... ~26600 lines later
[2012-07-01 02:14:59.999][02:14:59.999] StatService[] cpu-load=41.05
[2012-07-01 02:14:59.999][02:14:59.999] StatService[] cpu-load=41.05
[2012-07-01 02:14:59.999][02:14:59.999] StatService[] cpu-load=41.05
[2012-07-01 02:14:59.999][02:14:59.999] StatService[] cpu-load=41.05
[2012-07-01 02:14:59.999][02:14:59.999] StatService[] cpu-load=41.05
[2012-07-01 02:14:59.999][02:14:59.999] StatService[] cpu-load=41.05
[2012-07-01 02:14:59.999][02:14:59.999] StatService[] cpu-load=41.05
This seemed a bit much to log every 60th second.
I tried to add a stat-service section with 10 minute sample-period, 
and saw that those ~26600 lines was now only logged every 10th minute.
But still loads more than usual (I would expect just a single line 
beeing logged).
Was Resin to blame for this (ie. is there a possible bug around here?) 
or was it the JVM and OS?


I'd guess it's related to the JVM/OS issue. In our nightly regressions, 
there were some sleep/waits that were stuck before we updated the system.


It's pretty impressive that a 1s change could cause that much chaos. :)

-- Scott


Regards,
*Jens Dueholm Christensen
*Survey IT


___
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] JNI timeout on multipart forms in 4.0.28

[Scott Ferguson]

On 06/19/2012 02:18 PM, Scott Ferguson wrote:
 On 06/19/2012 01:13 AM, Mattias Jiderhamn wrote:
 - Original Message -
 Subject: Re: [Resin-interest] JNI timeout on multipart forms in 4.0.28
 Date: Fri, 15 Jun 2012 11:29:12 +0200
 From: Mattias Jiderhamnmj-li...@expertsystems.se
 I can recreate this quite easily, without any forwards. All that is
 needed is a large enough (   75 parts) form.
 ...
 Were you able to recreate this?
 Not yet. I'm doing a bug list pass from oldest to newest. I should get
 to it in a day or two.

Is this an SSL request? I'm duplicating it with OpenSSL, but it's an 
OpenSSL buffering issue (in combination with Resin's timeouts). It 
wouldn't affect non-SSL requests.

-- Scott

 -- Scott



 ___
 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] JNI timeout on multipart forms in 4.0.28

[Scott Ferguson]

On 06/19/2012 01:13 AM, Mattias Jiderhamn wrote:
 - Original Message -
 Subject: Re: [Resin-interest] JNI timeout on multipart forms in 4.0.28
 Date: Fri, 15 Jun 2012 11:29:12 +0200
 From: Mattias Jiderhamnmj-li...@expertsystems.se

 I can recreate this quite easily, without any forwards. All that is
 needed is a large enough (  75 parts) form.
 ...
 Were you able to recreate this?

Not yet. I'm doing a bug list pass from oldest to newest. I should get 
to it in a day or two.

-- Scott



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

Re: [Resin-interest] JNI timeout on multipart forms in 4.0.28

[Scott Ferguson]

On 06/14/2012 08:21 AM, Mattias Jiderhamn wrote:

I'm really glad Resin 4.0.28 is here since it resolves multiple issues
we've been having lately. However, it seems a new critical issue may
have been introduced since 4.0.25.


I've filed this as http://bugs.caucho.com/view.php?id=5120

Is it possible that this code is from a forward? I just closed a bug 
where a forwarded form would try to double-read the content.


Otherwise, this looks new.

If you can create a tiny example POST that triggers the problem and send 
it, that should help track it down.


Our plan is to release the next few versions fairly quickly, focusing 
just on bug fixes.


-- Scott



When running on 64-bit Linux, compiled with --enable-64bit and
--enable-ssl, and posting a multipart/form-data form without any file
parts included, we're getting timeouts. See stacktrace below.

We do not have any issues with
- non-multipart forms
- multipart forms containing file parts
- multipart forms without file parts, when running on Windows

Have there been any additional configuration parameters added, that
might be worth trying out?
Any other ideas?
Thanks in advance.

[2012-06-14 17:13:21.414] com.caucho.vfs.SocketTimeoutException: client
timeout
  at
com.caucho.vfs.JniStream.exception(JniStream.java:231)
  at
com.caucho.vfs.JniStream.read(JniStream.java:83)
  at
com.caucho.vfs.ReadStream.read(ReadStream.java:472)
  at
com.caucho.server.http.ContentLengthStream.read(ContentLengthStream.java:75)
  at
com.caucho.vfs.ReadStream.readBuffer(ReadStream.java:1239)
  at
com.caucho.vfs.ReadStream.read(ReadStream.java:365)
  at
com.caucho.vfs.MultipartStream.read(MultipartStream.java:420)
  at
com.caucho.vfs.MultipartStream.read(MultipartStream.java:352)
  at
com.caucho.vfs.ReadStream.readBuffer(ReadStream.java:1239)
  at
com.caucho.vfs.ReadStream.readChar(ReadStream.java:571)
  at
com.caucho.server.http.MultipartFormParser.parsePostData(MultipartFormParser.java:177)
  at
com.caucho.server.http.AbstractCauchoRequest.parsePostQueryImpl(AbstractCauchoRequest.java:441)
  at
com.caucho.server.http.AbstractCauchoRequest.parseQueryImpl(AbstractCauchoRequest.java:275)
  at
com.caucho.server.http.AbstractCauchoRequest.getParts(AbstractCauchoRequest.java:232)
  at
se.exder.servlet.ServletUtils.parseMultipart(ServletUtils.java:303)
  ...



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

Re: [Resin-interest] Out of PermGen space

[Scott Ferguson]

On 05/29/2012 09:51 PM, Mattias Jiderhamn wrote:
 On 05/29/2012 12:27 PM, Mattias Jiderhamn wrote:
 - Original Message -
 Subject: Re: [Resin-interest] Out of PermGen space
 Date: Fri, 27 Apr 2012 11:23:41 +0200
 From: Mattias Jiderhamnmj-li...@expertsystems.se

 I should also mention, that I have an open bug report on Resin 4.0.27
 which seems to cause classloader leaks.
 http://bugs.caucho.com/view.php?id=5010
 Has anyone had time to confirm this bug?
 It seems to be triggered more often when using JSF, so when developing
 JSF applications I need to restart the server over and over (no
 difference whether HotSwap is enabled or not).
 Would be happy to know if there is hope that this will be fixed.
 Do you have a trace to root on one of those?

 (We've finally found the bugtrack upload corruption issue, but haven't
 updated that server yet, so the current pngs aren't readable.)
 See http://jiderhamn.se/resin4027.png + http://jiderhamn.se/resin4027b.png

 Let me know if I can provide any additional info.

Thanks. The first one is straightforward to fix (the AnnotationLiteral 
is a surprising dependency, though.)

I'm not sure how the second one is possible (the one where your 
application's bean is in the ResinSystem CDI context.) I assume that 
bean is just scanned normally?

-- Scott


 /Mattias

 ___
 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] Out of PermGen space

[Scott Ferguson]

On 05/29/2012 12:27 PM, Mattias Jiderhamn wrote:
 - Original Message -
 Subject: Re: [Resin-interest] Out of PermGen space
 Date: Fri, 27 Apr 2012 11:23:41 +0200
 From: Mattias Jiderhamnmj-li...@expertsystems.se

 I should also mention, that I have an open bug report on Resin 4.0.27
 which seems to cause classloader leaks.
 http://bugs.caucho.com/view.php?id=5010
 Has anyone had time to confirm this bug?
 It seems to be triggered more often when using JSF, so when developing
 JSF applications I need to restart the server over and over (no
 difference whether HotSwap is enabled or not).
 Would be happy to know if there is hope that this will be fixed.

Do you have a trace to root on one of those?

(We've finally found the bugtrack upload corruption issue, but haven't 
updated that server yet, so the current pngs aren't readable.)

-- Scott


 /Mattias

 In pretty much every heap dump I analyze for ZombieClassLoaderMarker
 these days, com.caucho.config.inject.InjectManager turns up somewhere in
 the path to root. Not sure if it will fix all the problems, but it sure
 would be interesting to try a Resin version without this issue.

 P.S. I did some experimenting with Resin Pro vs Open Source today, and
 on both found some strange paths leading to JNI Local
 com.caucho.env.thread2.ResinThread2. Disabling JNI (on Windows,
 removing resin_os.dll) seemed to postpone the crash (which again
 included InjectManager) substantially. Not enought statistics to draw
 conclustions, but there *may* be something fishy about the JNI
 connection under Windows.

 /Mattias


 -- /Mattias

 ___
 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] Moved from 4.0.23 Pro to 4.0.27 Pro, now 2 servers clash listening to *:8080

[Scott Ferguson]

On 05/01/2012 02:17 AM, Stargazer wrote:
 On 29/04/2012 11:44, Stargazer wrote:
 Using Ubuntu 64bit with mod_caucho behind Apache. The 4.0.23 config
 Here's the same question put a much simpler way  - its answer will give
 me a clue.
 I just installed a fresh copy of Resin Pro 4.0.27 and started it with no
 changes to any config files. The machine its on has the IP 1.2.3.4. The
 start up log shows http listening to *:8080. What config change do I
 need to make to get that to read http listening to 1.2.3.4:8080 please?

You'll need to modify the cluster-default.xml. Look for the http.

I'll update it to add a http_address for the resin.properties for the 
ext release.

-- Scott



 ___
 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] Moved from 4.0.23 Pro to 4.0.27 Pro, now 2 servers clash listening to *:8080

[Scott Ferguson]

On 05/01/2012 02:41 PM, Stargazer wrote:
 On 01/05/2012 17:15, Scott Ferguson wrote:
 On 05/01/2012 02:17 AM, Stargazer wrote:
 On 29/04/2012 11:44, Stargazer wrote:
 Using Ubuntu 64bit with mod_caucho behind Apache. The 4.0.23 config
 Here's the same question put a much simpler way  - its answer will give
 me a clue.
 I just installed a fresh copy of Resin Pro 4.0.27 and started it with no
 changes to any config files. The machine its on has the IP 1.2.3.4. The
 start up log shows http listening to *:8080. What config change do I
 need to make to get that to read http listening to 1.2.3.4:8080 please?
 You'll need to modify the cluster-default.xml. Look for thehttp.
 I'll update it to add a http_address for the resin.properties for the
 ext release.
 Thanks. Is there a way to specify a different cluster-default.xml per
 resin instance the way described in the root, or should I just wait for
 the next version where I can see this will be easy now?

You can modify the resin.xml and add http elements for each server 
with your own property names. I think that would be the easiest.

You can also change the cluster-default.xml or make a new one of your 
own. The standard config is just intended to handle most simple 
configurations, not all sites.

We still expect many sites will change their resin.xml, even with the 
new resin.properties. The main idea is to let the simpler sites (and new 
users) to use the resin.properties, not to forbid changes to the 
resin.xml. We split out the cluster-default.xml mostly because the 
resin.xml was getting to complicated, and because most of the config in 
the cluster-default.xml was fairly standard.

-- Scott

-- Scott


 -- Carl

 ___
 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] Out of PermGen space

[Scott Ferguson]

On 04/25/2012 08:47 PM, Matt White wrote:
 On 4/24/2012 5:13 PM, Bill Au wrote:

 Wow, something I'm actually qualified to talk about on this list! :)


 Out of PermGen space is almost always caused by a classloader leak which
 occurs when a webapp is reloaded.  It could be caused by either your own
 code, third-party code, or in some case Java core classes.
 I debug PermGen errors quite a bit. Some of our apps have a cache of
 dynamically generated classes (Drools does this) that, if held onto long
 enough, will make the the JVM run out of PermGen. This isn't really a
 mistake, it's just how it works, sadly.


 You need to take heap dumps before and after webapp reload and use a
 heap analyzer to see what is holding onto the leaked classloader(s).
 That's how I debug them. Take a series of heap dumps and start comparing
 the differences between them -- YourKit even makes this easy for you
 with a tool that diffs heap dumps.

If you're using Resin 4.0, have you tried looking for the 
ZombieClassLoaderMarker? It's designed to make that tracing easier.

-- Scott


 - Matt

 ___
 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] Out of PermGen space

[Scott Ferguson]

On 04/24/2012 03:13 PM, Bill Au wrote:
Out of PermGen space is almost always caused by a classloader leak 
which occurs when a webapp is reloaded.  It could be caused by either 
your own code, third-party code, or in some case Java core classes.


You need to take heap dumps before and after webapp reload and use a 
heap analyzer to see what is holding onto the leaked classloader(s).


As a quick check, if you're using Resin 4.0 Pro, the PDF dump shows 
ZombieClassLoaderMarker in the heap dump section. Or you can use a 
heap analyzer and look for ZombieClassLoaderMarker and do a 
search-to-root on it.


In Resin, a zombie classloader is one that Resin expects to be garbage 
collected.


-- Scott



Bill

On Tue, Apr 24, 2012 at 5:41 PM, Chris Pratt thechrispr...@gmail.com 
mailto:thechrispr...@gmail.com wrote:


Well, yes and no.  As I understand the problem, it really got bad
around the Java 5 timeframe because of the addition of
Enumerations to the language.  What Resin does (and all
auto-reloading Java containers do) is to create a ClassLoader that
contains all the code for your application.  When it senses a
change to your code, it loads that new code into a brand new
ClassLoader and releases the old one to be garbage collected once
it's done processing it's active requests.  The problem is that,
since Enumerations are guaranteed to work with the == operator,
even when serialized/deserialized between different computers,
Java treats them special, by keeping them in the Permanent
Generation (so their internal ID's won't change).  Unfortunately,
each time the app is loaded a new set of Enumerations takes up
more space in the precious PermGen until it finally blows its lid.
 So, theoretically, you could use less PermGen by limiting
Enumeration use, but that's really not a realistic response.
 Before Java became property of Oracle, there was some talk about
fixing this problem at the JVM level, but I haven't heard anything
in quite a while.
  (*Chris*)


On Tue, Apr 24, 2012 at 1:54 PM, Rick Mann rm...@latencyzero.com
mailto:rm...@latencyzero.com wrote:

When I'm making changes to the code of a webapp, Resin kindly
reloads it for me. I can usually get a handful of reloads in
before Resin complains about being out of PermGen space.

Is there something I'm doing wrong in my app that it leaks
like this?

--
Rick


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



___
resin-interest mailing list
resin-interest@caucho.com mailto: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] Override EL implementation (help us stay with Resin)

[Scott Ferguson]

On 04/17/2012 12:40 PM, Mattias Jiderhamn wrote:


- Original Message -
Subject: Re: [Resin-interest] Override EL implementation (help us stay 
with Resin)

Date: Mon, 16 Apr 2012 13:12:15 -0700
From: Scott Ferguson f...@caucho.com
 Anyway, when javaee-16.jar/javax/el is replaced with Maven dep

 javax.el/el-api/2.2 the problems were gone, so therefore I assumed the
 repackaging was based on a pre 2.2 version and Resin was not to blame
 for the bugs per se.

 But what you are saying is, that our best bet is to report each
 separate bug against Resin, and hope to see them fixed in the next
 version?

Correct. Fixing those bugs are generally pretty simple, because they're
fairly small in functionality. 


Well, I feel like a n00b after having realized the most severe 
problems we're actually caused by the fact that a team member (who is 
running JBoss locally) had set com.sun.faces.expressionFactory 
parameter to com.sun.el.ExpressionFactoryImpl. So there was a mixture 
of two implementations. Sorry for blaming Resin! *blush*


After changing the setting to com.caucho.el.ExpressionFactoryImpl (or 
rather a proxy using com.caucho.el.ExpressionFactoryImpl if present), 
the problems turning are much less severe.


I reported http://bugs.caucho.com/view.php?id=5034 (which has a very 
easy workaround) and http://bugs.caucho.com/view.php?id=5035 (which 
should be no problem in production, but make development much less 
effective; trivial to fix so I trust it to be in the next release)


Thanks.



I do want to ask, why Resin is using a custom EL implementation rather 
than the Sun implementation? Performance? Licensing?


Historically licensing and performance.

-- Scott


 In case there is good reason to stick with custom implementation, and 
the above two bugs are fixed, I guess 
http://bugs.caucho.com/view.php?id=5011 can be closed.


--

   /Mattias


___
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] Override EL implementation (help us stay with Resin)

[Scott Ferguson]

On 04/16/2012 03:47 AM, Mattias Jiderhamn wrote:
 We have been using Resin for 10+ years, mostly very satisfied, but as we
 are now working with JSF we've had numerous problems related to Resin.
 Most of the problems are caused by Resins implementation of EL (not
 resolving parameters, not being able to call a method defined in a super
 class, requiring setter to allow getter access).

Hmm. I'd assumed you were talking about the draft for JavaEE 7, because 
the bug report says update EL to 2.2 (and not remembering the exact 
bug report number.)

Instead of reporting specific bugs against Resin's implementation (which 
we can fix), you're asking for it to be replaced? That's backwards.

Am I understanding this right? I'd put it on a low priority, because I 
thought you were asking for early draft implementation of JavaEE 7, not 
bugs against JavaEE 6 (because your requests weren't described as JavaEE 
6 bugs.)

-- Scott


 We've managed some partial workarounds (such as a custom
 com.sun.faces.expressionFactory), but at this point it seems the only
 rational thing to do is to replace/override individual classes or the
 entire javax.el package (which Resin does not allow out of the box) - or
 look for another application server. I want your help to see what our
 workaround options are.

 There are obviously benefits of being able to limit the workaround to
 the application, so that a WAR can include any EL updates and there is
 no special operation required per server / when upgrading Resin etc. The
 fact that the application is supposed to be hosted by a third party,
 also means we don't know if we are even allowed to make necessary
 changes to the Resin installation.

 Here are the options I see so far:

 A) Configure the server to include alternative EL implementation JAR
 (el-api-2.2.jar) in the classpath, preceeding Resins javaee-16.jar. This
 could be achieved by setting CLASSPATH environment variable and should
 also be possible with thejvm-arg  tag in Resin configuration.
 Drawbacks: EL cannot be updated with application, but needs separate
 update. Not sure hosting companies allow it. Probably not compatible
 with Resin IDE plugin (haven't got it working yet...), so there will be
 different configs in dev and production.

 B) Patch Resins javaee-16.jar with the contents of the other EL
 implementation JAR (el-api-2.2.jar). This has been tested in dev
 environment and seems to work.
 Drawbacks: EL cannot be updated with application, but needs separate
 update. Unlikely that hosting companies allow this. Needs to be done for
 every Resin upgrade (until Resin is fixed...). Hacky.

 C) Allow override of classes inside application (as of the Servlet
 spec...) by patching the Relax NG Schema of Resin configuration
 (env.rnc) and adding
 class-loaderpriority-packagejavax.el/priority-package.
 Drawbacks: Less likely that hosting companies allow this. Lead to other
 issues when testing.

 D) I believe it may be possible replacing for example
 com.sun.faces.el.ELUtils.BEAN_RESOLVER constant with another
 implementation, using reflection and Apache BCEL. This way, everthing
 would be included in WAR and no special configuration needed per server.
 Drawbacks: Unimplemented and untested (requires time, may not work),
 very hacky. There may be interdependencies between classes in the
 javax.el package that are broken if only single classes replaced.

 Are there other options?
 Flaws in the above reasoning?

 Thanks in advance,



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

Re: [Resin-interest] Override EL implementation (help us stay with Resin)

[Scott Ferguson]

On 04/16/2012 12:30 PM, Mattias Jiderhamn wrote:


I'm sorry if http://bugs.caucho.com/view.php?id=5011 is misphrased. 
I'm still a bit of a newbie on the JEE 6+ stack.


I thought javaee-16.jar only contained repackaged standard API:s. Are 
you saying it contains Caucho specific implementations of these API:s, 
javax.el.BeanELResolver in particular...?
(The fact that standard API interfaces such as 
javax.servlet.http.HttpServletRequest and 
javax.transaction.UserTransaction have a Caucho licensing header in 
the Resin source dist makes it harder to see what is standard and what 
isn't)


They're standard APIs with our implementation.

In most cases, those APIs are just interfaces. In some cases like the 
EL, the specification puts implementation in those jars. (Personally, I 
don't like those APIs, since I don't think spec jars should have much 
functionality.)




Anyway, when javaee-16.jar/javax/el is replaced with Maven dep 
javax.el/el-api/2.2 the problems were gone, so therefore I assumed the 
repackaging was based on a pre 2.2 version and Resin was not to blame 
for the bugs per se.


But what you are saying is, that our best bet is to report each 
separate bug against Resin, and hope to see them fixed in the next 
version?


Correct. Fixing those bugs are generally pretty simple, because they're 
fairly small in functionality.


-- Scott



/Mattias



Am I understanding this right? I'd put it on a low priority, because I
thought you were asking for early draft implementation of JavaEE 7, not
bugs against JavaEE 6 (because your requests weren't described as JavaEE
6 bugs.)

-- Scott


 We've managed some partial workarounds (such as a custom
 com.sun.faces.expressionFactory), but at this point it seems the only
 rational thing to do is to replace/override individual classes or the
 entire javax.el package (which Resin does not allow out of the box) 
- or

 look for another application server. I want your help to see what our
 workaround options are.

 There are obviously benefits of being able to limit the workaround to
 the application, so that a WAR can include any EL updates and there is
 no special operation required per server / when upgrading Resin 
etc. The

 fact that the application is supposed to be hosted by a third party,
 also means we don't know if we are even allowed to make necessary
 changes to the Resin installation.

 Here are the options I see so far:

 A) Configure the server to include alternative EL implementation JAR
 (el-api-2.2.jar) in the classpath, preceeding Resins javaee-16.jar. 
This

 could be achieved by setting CLASSPATH environment variable and should
 also be possible with thejvm-arg tag in Resin configuration.
 Drawbacks: EL cannot be updated with application, but needs separate
 update. Not sure hosting companies allow it. Probably not compatible
 with Resin IDE plugin (haven't got it working yet...), so there 
will be

 different configs in dev and production.

 B) Patch Resins javaee-16.jar with the contents of the other EL
 implementation JAR (el-api-2.2.jar). This has been tested in dev
 environment and seems to work.
 Drawbacks: EL cannot be updated with application, but needs separate
 update. Unlikely that hosting companies allow this. Needs to be 
done for

 every Resin upgrade (until Resin is fixed...). Hacky.

 C) Allow override of classes inside application (as of the Servlet
 spec...) by patching the Relax NG Schema of Resin configuration
 (env.rnc) and adding
 class-loaderpriority-packagejavax.el/priority-package.
 Drawbacks: Less likely that hosting companies allow this. Lead to 
other

 issues when testing.

 D) I believe it may be possible replacing for example
 com.sun.faces.el.ELUtils.BEAN_RESOLVER constant with another
 implementation, using reflection and Apache BCEL. This way, everthing
 would be included in WAR and no special configuration needed per 
server.

 Drawbacks: Unimplemented and untested (requires time, may not work),
 very hacky. There may be interdependencies between classes in the
 javax.el package that are broken if only single classes replaced.

 Are there other options?
 Flaws in the above reasoning?

 Thanks in advance,






___
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] UnavailableException???

[Scott Ferguson]

On 03/23/2012 01:34 PM, Rick Mann wrote:
 WTF.

 I have resin 4.0.23 running on a server on rackspace. They just forcibly 
 migrated my host (I had rebooted a different one earlier to control when the 
 migration happened, but dropped the ball on this one).

 When it came back up, resin didn't restart (config problem on my end). So I 
 logged in an re-started it. Everything seemed fine.

 Then a while later, it died (ran out of permgen space). Note that this is a 
 very unloaded server.

 So, I killed it (I tried using resin.sh stop, but that took so long, I used 
 kill -kill on all the resin processes).

 Now it starts up, and I'm getting this:

 [show]
   javax.servlet.UnavailableException: 
 org.apache.commons.digester.Digester.parse(Ljava/net/URL;)Ljava/lang/Object;


 javax.servlet.UnavailableException: 
 org.apache.commons.digester.Digester.parse(Ljava/net/URL;)Ljava/lang/Object;
   at org.apache.struts.action.ActionServlet.init(ActionServlet.java:402)
   at javax.servlet.GenericServlet.init(GenericServlet.java:70)
   at 
 com.caucho.server.dispatch.ServletConfigImpl.createServletImpl(ServletConfigImpl.java:1356)
   at 
 com.caucho.server.dispatch.ServletConfigImpl.createServlet(ServletConfigImpl.java:1204)
   at 
 com.caucho.server.dispatch.ServletManager.init(ServletManager.java:232)



 I haven't changed anything else. Any ideas?

Possibly a missing or out-of-date jar file for struts or one of its 
dependencies?

The exception is a servlet exception, but the message string looks more 
like a JVM linking error, so maybe struts is rethrowing a linking problem.

-- Scott


 Thanks,
 Rick


 ___
 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] Multiple servers defined on a cluster now(4.x) requires Resin Professional

[Scott Ferguson]

On 03/16/2012 01:43 AM, Daniel López wrote:
 Hi there,

 We are using Resin 3 and we even though we are not using real
 clustering, we used the possibility of defining various servers inside a
 cluster, so we could share a configuration file among various hosts,
 like this:

You can always use resin:import/ and -conf to select the server (or 
use resin:choose with a -D to select the options.)

That way the unique config files would stay small and maintainable, and 
you wouldn't need to repeat configuration.

-- Scott

 --
 cluster id=app-tier
   root-directory./root-directory
   server-default
 !-- The http port --
 http address=* port=XXX/
 ...
   /server-default

   server id=Host.1 address=host.1.com port=XXX/
   server id=Host.2 address=host.2.com port=XXX/
   server id=Local address=127.0.0.1 port=XXX/
 ---
 and then start one or the other depending on the -server argument passed
 etc.
 I'm trying to see how we would migrate to Resin 4 and, if I'm not
 mistaken, this is no longer allowed as you require a license to define
 more than one server on a cluster, right?

 Is there any other way to have server share the configuration like that,
 we need to have different server ids forcookie-append-server-index /,
 or is having different configuration files or moving to Resin Pro the
 only options?

 S!
 D.
 ---
 Daniel Lopez Janariz (d.lo...@uib.es)
 Web Services
 Centre for Information and Technology
 Balearic Islands University
 (SPAIN)
 ---

 ___
 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] HTTP header size

[Scott Ferguson]

On 03/12/2012 09:30 PM, Deepak Ramaprasad wrote:
 s there a way to increase the HTTP header size?
 
   There are malicious clients that try to break into the server with long
   requests. Resin's size limit is designed to protect against that. So if
   this is an
   externally visible site, that might be normal.
 This is an Internal application not exposed to the external world. We
 are posting a huge chunk of data. Is there any way to work around
 this?

I've added it as a feature request. We already allow url sizes to be 
configurable.
We can do the same for the headers.

-- Scott




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

Re: [Resin-interest] HTTP header size

[Scott Ferguson]

On 03/12/2012 05:55 AM, Deepak Ramaprasad wrote:
 Greetings!

 Is there a way to increase the HTTP header size?

 What is the default?

The default is pretty large (8k for the URL, and 16k for the headers.)

I'm getting this:


==  log/jvm-default.log==
[12-03-12 18:21:48.340] {http://*:8080-10}
com.caucho.server.dispatch.BadRequestException: Invalid request: URL
or headers are too long
[12-03-12 18:21:48.340] {http://*:8080-10} Invalid request: URL or
headers are too long


There are malicious clients that try to break into the server with long
requests. Resin's size limit is designed to protect against that. So if 
this is an
externally visible site, that might be normal.

-- Scott



 Thanks
 Deepak




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

Re: [Resin-interest] JMS queue in database

[Scott Ferguson]

On 03/12/2012 01:11 PM, Mattias Jiderhamn wrote:
 Seems that the syntax is

 jms-queue uri=jdbc:dataSource=jdbc/foobar ... /

 however it is not implemented?

Or jms:JdbcQueue .../, although it was backed out for 4.0.

-- Scott


 /Mattias

 - Original Message -
 Subject: [Resin-interest] JSM queue in database
 Date: Mon, 12 Mar 2012 20:52:33 +0100
 From: Mattias Jiderhamnmj-li...@expertsystems.se

 How can I use a DataSource (or simply a JDBC accessible SQL database) as
 the storage for the Resin JMS Queue implementation?




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

Re: [Resin-interest] Resin 4.0 Clustering and HTTP MULTIPART

[Scott Ferguson]

On 02/22/2012 11:08 AM, Aaron Freeman wrote:
 Does Resin 4.0 have any notion of handling a situation where a large HTTP
 MULTIPART POST request has come in (a large file transfer for example), and
 then when one of the nodes of the cluster that is handling that MULTIPART
 POST were to go offline, another node would take over with no interruption
 between the client and the cluster?

 If not, is there any technology that handles large MULTIPART POSTs in some
 redundant form like that?

I'm not sure I understand the question.

At the base level, a POST is just a stream of bytes. The multipart/mime 
handling is just a convenience parser on top so you don't have to parse 
it yourself. A half-parsed POST (or fully parsed, but not processed) 
isn't something that can be failed over automatically, because the 
individual Parts aren't really meaningful.

But we also can't failover POSTs at all once the dispatch has begun, 
because there's no way for Resin to know if the application's POST 
handling is idempotent, safe to retry. We can failover on a 
load-balancer/app-server connection failure, or on a 503 response, but 
not on any other kind of response.

-- Scott


 Thanks,

 Aaron



 ___
 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] JSP pages wont compile : java.lang.RuntimeException: bad scheme in...

[Scott Ferguson]

On 02/21/2012 06:08 AM, Sean Moore wrote:
   All of a sudden I have jsp pages that will not compile with the below error.

 The issue does not show up on my test server.  Nothing much has happened on 
 the deployment server.

 It looks like it is in the process of loading all the tlds.  None of my very 
 few tlds say anything about facebook.  Where else could it be trying to read 
 the scheme from?


It should be scanning the WEB-INF directories. That scanning can be 
changed in the resin-web.xml with the tld-file-set or tld-dir directive.

Do you know how those are set?

Hmm. Checking the code, though. If you have a file under WEB-INF which 
is _named_ like a URL (for example in WEB-INF/tmp), you might have this 
problem.

-- Scott


 Help!

 Resin version 3.0.26

 Thanks,
 Sean Moore
 s...@homegauge.com


 java.lang.RuntimeException: bad scheme in 
 `https:%2F%2Fwww.facebook.com%2Fmedia%2Fset%2F?set=a.153069261371130.27793.10041703265type=1.webhistory'
  at com.caucho.vfs.HttpPath.schemeWalk(HttpPath.java:156)
  at com.caucho.vfs.Path.lookupImpl(Path.java:183)
  at com.caucho.vfs.Path.lookup(Path.java:121)
  at com.caucho.vfs.Path.lookup(Path.java:92)
  at com.caucho.config.types.FileSetType.getPaths(FileSetType.java:152)
  at com.caucho.config.types.FileSetType.getPaths(FileSetType.java:152)
  at com.caucho.config.types.FileSetType.getPaths(FileSetType.java:137)
  at com.caucho.config.types.FileSetType.getPaths(FileSetType.java:124)
  at com.caucho.jsp.TldManager.loadAllTlds(TldManager.java:302)
  at com.caucho.jsp.TldManager.init(TldManager.java:202)
  at com.caucho.jsp.TldManager.parseTld(TldManager.java:434)
  at com.caucho.jsp.TaglibManager.readTaglib(TaglibManager.java:225)
  at com.caucho.jsp.TaglibManager.getTaglib(TaglibManager.java:172)
  at com.caucho.jsp.ParseTagManager.addTaglib(ParseTagManager.java:258)
  at com.caucho.jsp.JspParser.processTaglib(JspParser.java:1655)
  at 
 com.caucho.jsp.JspParser.processTaglibDirective(JspParser.java:1629)
  at com.caucho.jsp.JspParser.parseDirective(JspParser.java:1159)
  at com.caucho.jsp.JspParser.parseScriptlet(JspParser.java:1033)
  at com.caucho.jsp.JspParser.parseNode(JspParser.java:417)
  at com.caucho.jsp.JspParser.parseJsp(JspParser.java:328)
  at com.caucho.jsp.JspParser.parse(JspParser.java:252)
  at 
 com.caucho.jsp.JspCompilerInstance.generate(JspCompilerInstance.java:466)
  at 
 com.caucho.jsp.JspCompilerInstance.compile(JspCompilerInstance.java:373)
  at com.caucho.jsp.JspManager.compile(JspManager.java:233)
  at com.caucho.jsp.JspManager.createPage(JspManager.java:177)
  at com.caucho.jsp.JspManager.createPage(JspManager.java:157)
  at com.caucho.jsp.PageManager.getPage(PageManager.java:248)
  at com.caucho.jsp.PageManager.getPage(PageManager.java:166)
  at com.caucho.jsp.QServlet.getSubPage(QServlet.java:292)
  at com.caucho.jsp.QServlet.getPage(QServlet.java:210)



 ___
 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] Problems with rollover of logfile with log4j 1.2.16 and AsyncAppender

[Scott Ferguson]

On 02/20/2012 12:56 PM, Jens Dueholm Christensen (JEDC) wrote:

Hi

Lately we are seeing increased blocking behaviour from log4j when Resin 
performs the nightly rollover of logfiles.

We’re running Resin Pro 3.1 (license #1013826) in a pre .11 snapshot 
(resin-pro-3.1.s110225) (due to bug #4349 and a bit of waiting before 3.1.11 
was released).
Updating to 3.1.12 is planned, but the changelog 
(http://www.caucho.com/resin-3.1/changes/changes.xtp is the best I could find?) 
does not mention any fix for our current problem, so I’m looking for any 
insights or advise.


I'd need to look at the log4j code to understand what it's doing.

I don't think that wait() should be related to Resin (other than timing) 
but I'd need to look at their code to be certain, and I can't think of 
any logging that would help. (Logging the logging code is tricky :)


3.1.13 should be out next week, by the way.

-- Scott


We’ve configured resin to perform rollovers of this logfile:

   stdout-log path=/usr/local/www/xact/logs/resin-web-stdout.log
 timestamp=[%Y-%m-%d %H:%M:%S.%s] rollover-period=1D/

In our log4j configuration we log to stdout with:

appender name=CONSOLE class=org.apache.log4j.ConsoleAppender
   param name=Target value=System.out/
   layout class=org.apache.log4j.PatternLayout
  param name=ConversionPattern value=%d{ISO8601} [%-20.20t] %5p %c{1} - %m 
- %x%n/
   /layout
/appender

appender name=ASYNC class=org.apache.log4j.AsyncAppender
   appender-ref ref=CONSOLE/
/appender

root
   priority value=warn/
   appender-ref ref=ASYNC/
/root

loggers

Some time after midnight when Resin performs the rollover, the JVM becomes 
unresponsive and a stacktrace shows multiple threads hanging, and we have to 
manually restart (it doesn’t get picked up by the watchdog, and can/will hang 
for hours).

A complete JVM stacktrace is attached to this mail.

All threads that are attempting to log are waiting for access to the object 
blocked by this thread:

http-172.27.80.36:8080-30$1663241944 daemon prio=10 tid=0x7f8804005800 
nid=0x2a40 in Object.wait() [0x7f87a08ed000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at org.apache.log4j.AsyncAppender.append(AsyncAppender.java:195)
- locked0x0005ba882928  (a java.util.ArrayList)
at 
org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)
- locked0x0005b8d6db00  (a org.apache.log4j.AsyncAppender)
at 
org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)
at org.apache.log4j.Category.callAppenders(Category.java:206)
- locked0x0005ba6f9e38  (a org.apache.log4j.spi.RootLogger)
at org.apache.log4j.Category.forcedLog(Category.java:391)
at org.apache.log4j.Category.info(Category.java:666)
at 
com.pls.popinhandler.PopinScriptHandler.handleRequest(PopinScriptHandler.java:65)
…

It seems like something never never calls notifyAll() on the ArrayList, and as 
a result our world grinds to a halt..

https://issues.apache.org/bugzilla/show_bug.cgi?id=38137#c16 (comment #16) has 
the same kind of stacktrace as we are seeing, and the comments in #17 does 
point towards Resin.

The last line in logfile resin-web-stdout.log.20120218 (before rotation) has 
the timestamp 2012-02-18 23:59:59,718.
The first line in the new logfile resin-web-stdout.log.20120219 has the 
timestamp 2012-02-19 01:30:48.878 (here we actually waited to see if the 
problem corrected itself – but alas) which was when we did a restart.
All other logfiles (watchdog, jvm, resin stdout and stderr) does not contain 
any indication of what is wrong.

If it’s not Resin causing the problem, I guess we’ll just have to switch our 
entire log4j setup to use org.apache.log4j.rolling.RollingFileAppender (part of 
log4j companions), but we’d prefer to stick with the existing setup.

Are there any interesting Resin loggers (and loglevel) that could show 
something?

Any thoughts or possible hints are appriciated.

Regards,
Jens Dueholm Christensen
Rambøll Survey IT




___
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] Tried Pro 4.0.25 - had to revert back to Pro 4.0.23 due to not a valid cluster IP

[Scott Ferguson]

On 02/14/2012 08:03 AM, Stargazer wrote:
 Just doing the +1 thing ... this open bug stopped us dead as we're in
 the same situation:
 http://bugs.caucho.com/bug_view_advanced_page.php?bug_id=4941

Yep. It's one of the bugs that's needed before 4.0.26.

Basically, we wanted to make sure people didn't expose the cluster ports 
by mistake.

-- Scott

 Unless there were config changes required - I didn't make any, so if
 there are I'd like to know please.


 ___
 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] [4.0.25] tremendously increases my server load when starts-up

[Scott Ferguson]

On 02/11/2012 07:44 AM, smallufo wrote:

Hi
sorry for reply late
I tried this snap , and the situation seems the same...
after start , the server almost hangs there


Thanks for checking.

I'm working through the threading code methodically for 4.0.26. I'm not 
sure when I'll have another snapshot to test. Possibly later this week.


-- Scott




$ w
 23:40:29 up 55 days,  5:40,  2 users,  load average: 519.06, 252.13, 
96.59

USER TTY  FROM  LOGIN@   IDLE   JCPU   PCPU WHAT
smallufo pts/1destiny2.smalluf 12:111.00s 11.71s  0.92s -bash
smallufo pts/2destiny2.smalluf 23:400.00s  0.07s  0.01s w


I've also updated my JDK to the latest version:
 $ java -version
java version 1.6.0_30
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) Client VM (build 20.5-b03, mixed mode, sharing)



2012/2/7 Scott Ferguson f...@caucho.com mailto:f...@caucho.com

Can you try the snapshot
http://caucho.com/download/resin-pro-4_0-snap.tar.gz?

The IP bug was a red-herring. There is a timing issue with
threading/clustering.

That snapshot is not suitable for production (several known
regression failures), but it can be used to verify the startup bug.


___
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 in the last Netcraft Web Server Survey

[Scott Ferguson]

On 02/08/2012 06:21 AM, Kevin Decherf wrote:

Hi,

FYI:

http://news.netcraft.com/archives/2012/02/07/february-2012-web-server-survey.html

The Resin application server has been experiencing strong growth
over the past 12 months; seeing an almost tenfold growth from 480k
hostnames in February 2011 to 4.7M or 0.77% of the market in
February 2012. Resin is a Java application server
from Caucho which is used on a number of the Million Busiest
Sites, including Bebo — now recovered from its outage last week.



Fantastic!

-- Scott




Kevin Decherf - M: +33 681194547 - T: @Kdecherf
C0DA 3C9A 0DB6 00C5 3D00 BBF4 A8CE A30C 6B4E BA7A


___
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] Encoding for javax.servlet.http.Part.getInputStream()

[Scott Ferguson]

On 02/06/2012 05:51 AM, Mattias Jiderhamn wrote:
 Hi. For multipart String parameters, Resin returns a UTF-8 encoded
 stream from javax.servlet.http.Part.getInputStream() without regards to
 request.getCharacterEncoding().

 I cannot find whether the UTF-8 encoding is stipulated by the spec, or
 if this is a Resin bug.
 Anyone knows...? Reference?

I'm filing this as a bug. http://bugs.caucho.com/view.php?id=4954

-- Scott

 Thanks in advance.




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

Re: [Resin-interest] [4.0.25] tremendously increases my server load when starts-up

[Scott Ferguson]

Can you try the snapshot 
http://caucho.com/download/resin-pro-4_0-snap.tar.gz?


The IP bug was a red-herring. There is a timing issue with 
threading/clustering.


That snapshot is not suitable for production (several known regression 
failures), but it can be used to verify the startup bug.


-- Scott

On 02/03/2012 01:45 AM, smallufo wrote:

Hi
This is my ip addresses :

$ ifconfig
eth0  Link encap:Ethernet  HWaddr 00:50:08:02:FA:8E
  inet addr:192.168.2.2  Bcast:192.168.2.255  Mask:255.255.255.0
  inet6 addr: fe80::250:8ff:fe02:fa8e/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:856152 errors:0 dropped:0 overruns:0 frame:0
  TX packets:460283 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:122552727 (116.8 MiB)  TX bytes:284641238 (271.4 MiB)
  Interrupt:233 Base address:0xc000

eth1  Link encap:Ethernet  HWaddr 00:60:6E:60:07:4B
  inet addr:192.168.1.104  Bcast:192.168.1.255  Mask:255.255.255.0
  inet6 addr: fe80::260:6eff:fe60:74b/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:11431817 errors:0 dropped:0 overruns:0 frame:0
  TX packets:13056593 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:3686915772 (3.4 GiB)  TX bytes:1152022111 (1.0 GiB)

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:201560031 errors:0 dropped:0 overruns:0 frame:0
  TX packets:201560031 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:1693844049 (1.5 GiB)  TX bytes:1693844049 (1.5 GiB)

All are local addresses , no VM installed.


2012/2/3 Scott Ferguson f...@caucho.com mailto:f...@caucho.com

On 02/02/2012 06:53 PM, smallufo wrote:

I cannot operate my server when I start resin 4.0.25
The load is so high that the server almost hangs there...
Even a ls is so sluggish...
It happens even in a clean install (no other webapps installed ,
just default resin.xml settings)



It might be related to a JVM bug having to do with the IP
addresses. What do you IP addresses look like? Are there any
virtual ones.

-- Scott




$ uname -a
Linux dev 2.6.18-164.6.1.el5 #1 SMP Tue Nov 3 16:18:27 EST 2009
i686 i686 i386 GNU/Linux

/var/log/resin $ head watchdog-manager.log
[2012/02/03 00:08:14.368] {main}
[2012/02/03 00:08:14.369] {main} Resin-4.0.25 (built Tue, 24 Jan
2012 11:09:58 PST)
[2012/02/03 00:08:14.370] {main}
[2012/02/03 00:08:14.370] {main} Linux 2.6.18-164.6.1.el5 i386
[2012/02/03 00:08:14.370] {main} Java(TM) SE Runtime Environment
1.6.0_22-b04, UTF-8, zh
[2012/02/03 00:08:14.371] {main} Java HotSpot(TM) Server VM
17.1-b03, 32, mixed mode, Sun Microsystems Inc.




2012/2/3 Scott Ferguson f...@caucho.com mailto:f...@caucho.com

On 02/02/2012 08:12 AM, smallufo wrote:

When I execute 'resinctl start'  , I notice my server almost
hangs 
And the server load is very high :

$ w
 00:07:51 up 46 days,  6:07,  3 users,  load average:
526.31, 298.59, 121.04
USER TTY  FROM  LOGIN@   IDLE   JCPU  
PCPU WHAT

smallufo pts/1destiny  Wed166:09   2.91s
 1.92s top
smallufo pts/2destiny  Wed221.00s  2.67s
 0.01s w
smallufo pts/3destiny  Wed233:36   7:07  
6:56  /usr/java/jdk/bin/java -jar

/usr/local/share/resin-4.0.25/lib/resin.jar -root-directory /hom

The load peaks to 500 or even higher !
After 5 or more minutes , the load goes down...


Can you get a thread dump?

Or better yet, if you have resin-pro, get a resinctl
pdf-report --profile.

-- Scott



It does not happen in 4.0.19 !


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



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



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



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

Re: [Resin-interest] [4.0.25] tremendously increases my server load when starts-up

[Scott Ferguson]

On 02/06/2012 10:54 AM, Bill Au wrote:

Scott,

What would trigger the JVM bug having to do with the IP addresses?  I 
want to make sure that I am not affected before I upgrade.


What version of JVM does that affect?


http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7078386

Looks like it's fixed in 1.6 b21 from the bug report.

Also, according to the bug report it's specific to Linux and certain 
IPv6 configurations.


It's not related to the 4.0.25 issue. Since Resin calls it once at 
startup, it would crash immediately.


-- Scott


Bill

On Mon, Feb 6, 2012 at 11:34 AM, Scott Ferguson f...@caucho.com 
mailto:f...@caucho.com wrote:


Can you try the snapshot
http://caucho.com/download/resin-pro-4_0-snap.tar.gz?

The IP bug was a red-herring. There is a timing issue with
threading/clustering.

That snapshot is not suitable for production (several known
regression failures), but it can be used to verify the startup bug.

-- Scott


On 02/03/2012 01:45 AM, smallufo wrote:

Hi
This is my ip addresses :

$ ifconfig
eth0  Link encap:Ethernet  HWaddr 00:50:08:02:FA:8E
  inet addr:192.168.2.2  Bcast:192.168.2.255
 Mask:255.255.255.0
  inet6 addr: fe80::250:8ff:fe02:fa8e/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:856152 errors:0 dropped:0 overruns:0 frame:0
  TX packets:460283 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:122552727 (116.8 MiB)  TX bytes:284641238
(271.4 MiB)
  Interrupt:233 Base address:0xc000

eth1  Link encap:Ethernet  HWaddr 00:60:6E:60:07:4B
  inet addr:192.168.1.104  Bcast:192.168.1.255
 Mask:255.255.255.0
  inet6 addr: fe80::260:6eff:fe60:74b/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:11431817 errors:0 dropped:0 overruns:0 frame:0
  TX packets:13056593 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:3686915772 (3.4 GiB)  TX bytes:1152022111 (1.0
GiB)

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:201560031 errors:0 dropped:0 overruns:0 frame:0
  TX packets:201560031 errors:0 dropped:0 overruns:0
carrier:0
  collisions:0 txqueuelen:0
  RX bytes:1693844049 (1.5 GiB)  TX bytes:1693844049 (1.5
GiB)

All are local addresses , no VM installed.


2012/2/3 Scott Ferguson f...@caucho.com mailto:f...@caucho.com

On 02/02/2012 06:53 PM, smallufo wrote:

I cannot operate my server when I start resin 4.0.25
The load is so high that the server almost hangs there...
Even a ls is so sluggish...
It happens even in a clean install (no other webapps
installed , just default resin.xml settings)



It might be related to a JVM bug having to do with the IP
addresses. What do you IP addresses look like? Are there any
virtual ones.

-- Scott




$ uname -a
Linux dev 2.6.18-164.6.1.el5 #1 SMP Tue Nov 3 16:18:27 EST
2009 i686 i686 i386 GNU/Linux

/var/log/resin $ head watchdog-manager.log
[2012/02/03 00:08:14.368] {main}
[2012/02/03 00:08:14.369] {main} Resin-4.0.25 (built Tue, 24
Jan 2012 11:09:58 PST)
[2012/02/03 00:08:14.370] {main}
[2012/02/03 00:08:14.370] {main} Linux 2.6.18-164.6.1.el5 i386
[2012/02/03 00:08:14.370] {main} Java(TM) SE Runtime
Environment 1.6.0_22-b04, UTF-8, zh
[2012/02/03 00:08:14.371] {main} Java HotSpot(TM) Server VM
17.1-b03, 32, mixed mode, Sun Microsystems Inc.




2012/2/3 Scott Ferguson f...@caucho.com
mailto:f...@caucho.com

On 02/02/2012 08:12 AM, smallufo wrote:

When I execute 'resinctl start'  , I notice my server
almost hangs 
And the server load is very high :

$ w
 00:07:51 up 46 days,  6:07,  3 users,  load average:
526.31, 298.59, 121.04
USER TTY  FROM  LOGIN@   IDLE  
JCPU   PCPU WHAT
smallufo pts/1destiny  Wed166:09  
2.91s  1.92s top

smallufo pts/2destiny  Wed221.00s
 2.67s  0.01s w
smallufo pts/3destiny  Wed233:36   7:07
  6:56  /usr/java/jdk/bin/java -jar
/usr/local/share/resin-4.0.25/lib/resin.jar
-root-directory /hom

The load peaks to 500 or even higher !
After 5 or more minutes , the load goes down...


Can you get a thread dump

Re: [Resin-interest] [4.0.25] tremendously increases my server load when starts-up

[Scott Ferguson]

On 02/02/2012 08:12 AM, smallufo wrote:

When I execute 'resinctl start'  , I notice my server almost hangs 
And the server load is very high :

$ w
 00:07:51 up 46 days,  6:07,  3 users,  load average: 526.31, 298.59, 
121.04

USER TTY  FROM  LOGIN@   IDLE   JCPU   PCPU WHAT
smallufo pts/1destiny  Wed166:09   2.91s  1.92s top
smallufo pts/2destiny  Wed221.00s  2.67s  0.01s w
smallufo pts/3destiny  Wed233:36   7:07   6:56 
 /usr/java/jdk/bin/java -jar 
/usr/local/share/resin-4.0.25/lib/resin.jar -root-directory /hom


The load peaks to 500 or even higher !
After 5 or more minutes , the load goes down...


Can you get a thread dump?

Or better yet, if you have resin-pro, get a resinctl pdf-report --profile.

-- Scott



It does not happen in 4.0.19 !


___
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] [4.0.25] tremendously increases my server load when starts-up

[Scott Ferguson]

On 02/02/2012 06:53 PM, smallufo wrote:

I cannot operate my server when I start resin 4.0.25
The load is so high that the server almost hangs there...
Even a ls is so sluggish...
It happens even in a clean install (no other webapps installed , just 
default resin.xml settings)




It might be related to a JVM bug having to do with the IP addresses. 
What do you IP addresses look like? Are there any virtual ones.


-- Scott



$ uname -a
Linux dev 2.6.18-164.6.1.el5 #1 SMP Tue Nov 3 16:18:27 EST 2009 i686 
i686 i386 GNU/Linux


/var/log/resin $ head watchdog-manager.log
[2012/02/03 00:08:14.368] {main}
[2012/02/03 00:08:14.369] {main} Resin-4.0.25 (built Tue, 24 Jan 2012 
11:09:58 PST)

[2012/02/03 00:08:14.370] {main}
[2012/02/03 00:08:14.370] {main} Linux 2.6.18-164.6.1.el5 i386
[2012/02/03 00:08:14.370] {main} Java(TM) SE Runtime Environment 
1.6.0_22-b04, UTF-8, zh
[2012/02/03 00:08:14.371] {main} Java HotSpot(TM) Server VM 17.1-b03, 
32, mixed mode, Sun Microsystems Inc.





2012/2/3 Scott Ferguson f...@caucho.com mailto:f...@caucho.com

On 02/02/2012 08:12 AM, smallufo wrote:

When I execute 'resinctl start'  , I notice my server almost
hangs 
And the server load is very high :

$ w
 00:07:51 up 46 days,  6:07,  3 users,  load average: 526.31,
298.59, 121.04
USER TTY  FROM  LOGIN@   IDLE   JCPU   PCPU WHAT
smallufo pts/1destiny  Wed166:09   2.91s  1.92s top
smallufo pts/2destiny  Wed221.00s  2.67s  0.01s w
smallufo pts/3destiny  Wed233:36   7:07   6:56
 /usr/java/jdk/bin/java -jar
/usr/local/share/resin-4.0.25/lib/resin.jar -root-directory /hom

The load peaks to 500 or even higher !
After 5 or more minutes , the load goes down...


Can you get a thread dump?

Or better yet, if you have resin-pro, get a resinctl pdf-report
--profile.

-- Scott



It does not happen in 4.0.19 !


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



___
resin-interest mailing list
resin-interest@caucho.com mailto: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] JSP runtime errors and resin error-page

[Scott Ferguson]

On 01/24/2012 08:53 AM, Alan Wright wrote:
 Hi

 We are running a struts based application inside Resin.

 In cases where a runtime error occurs for jsp pages (eg expected objects
 referenced on the page not found in the session) it seems that the
 response has already been generated partially when the error occurs and
 then the error page as specified in our resin.xml gets added to the
 response and sent to the client browser.

 Because we are using gzip, this results in content encoding errors in
 the browser because it seems as if the error page is gzipped inside the
 main response which is also gzipped (I am guessing that this is what is
 occuring). If the gzip filter is disabled we get the part complete
 response with the error page tagged onto the end and a non functioning
 web page.

 Error pages are specified in resin.xml for the application as follows:

 error-page
 error-code500/error-code
 location/error500.jsp/location
 /error-page

 error-page
 error-code403/error-code
 location/error403.jsp/location
 /error-page


 Is this something that Resin should be able to handle, or is it just
 inevitable in the face of jsp runtime errors?  Is there something we
 should do or configure to prevent the response being sent untill the jsp
 has processed without error?

Runtime errors are tricky because of the flushed buffer issue.

You can increase the JSP buffer size (though I'd generally not recommend 
it because it chews up memory.)

When possible it's best to verify everything before rendering anything. 
So if it's a known possibility that data could be missing, to add a 
check at the top. That wouldn't help true runtime errors, though.

I don't think there's much Resin can do besides the above. Once the data 
is flushed, it can't really be fixed.

-- Scott



 Thanks for any suggestions.


 Alan






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

Re: [Resin-interest] Change classloader precedence / priority / order

[Scott Ferguson]

For your sitation, wouldn't it just be easier to put the new jar in the 
classpath? For example using jvm-arg.

The overriding from a child classloader has always been a bad idea. (And 
in your case, probably wouldn't work, because the JSP and Servlet and 
CDI classes depend on EL, so the EL needs to be in the same classloader 
as the JSP.)

-- Scott


On 01/12/2012 07:33 AM, Mattias Jiderhamn wrote:
 It seems this is possible via the priorityPackage setting available on
 the DynamicClassLoader, however, that isn't allowed by the config Relax
 NG schema. If I hack the schema (env.rnc), I'm able to configure
 class-loader
 priority-packagejavax.el/priority-package
 (but of course that leads to other issues...).

 Is there any reason for this feature to be disable, or could the schema
 be update in the next release?

 /Mattias

 - Original Message -
 Subject: [Resin-interest] Change classloader precedence / priority / order
 Date: Thu, 12 Jan 2012 15:40:49 +0100
 From: Mattias Jiderhamnmj-li...@expertsystems.se

 Is there a way to change the priority / order of classloaders on
 different levels? The class-loader config tag claims to do this, but it
 seems to me it only affects the order within the current level (such as
 WEB-INF/classes vs WEB-INF/lib), and not classes already loaded by a
 higher level (${resin.rootDirectory}/lib).

 In particular, I need a newer javax.el implementation than what Resin
 provides in lib/javaee-16.jar.
 Preferrably I would just include the updated el-api and el-impl jars in
 my .war (WEB-INF/lib), and somehow tell Resin that they take precedence
 over the ones on resin level (without making explicit reference from
 resin.xml into the particular webapp-directory).

 Is that possible...?




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

Re: [Resin-interest] Reserve a http thread for admin connection.

[Scott Ferguson]

On 12/03/2011 08:11 PM, sam munkes wrote:

Hi,

We are running resin pro version 4.0.15 on a windows machine, using 
the IIS handler to handle the static files  forward the application 
requests to the resin server listening on port 6800.
The thread-max is configured to 1024, during normal loads resin is 
handling 10 requests concurrently.
The problem we are having is: If the requests are getting locked, for 
example waiting on database queries, the request threads fill up the 
1024 thread max, and the application stops responding to clients, 
including local admin requests.
Is there a way to configure resin to reserve a thread for 
administrative request? possible setup resin to listen on another port 
that will not be affected by the global thread-max limit?


If Resin listens to another port, it will have dedicated threads 
attached to it.


For a port, the accept-thread-min threads are allocated before the 
accept() call, so they would avoid the thread-max check.


You would need to listen to a different port (or IP), though, because 
there wouldn't be a way to reserve threads just for certain URLs.


-- Scott



Thanks.

--
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

Re: [Resin-interest] 4.0.24 configuration notes

[Scott Ferguson]

On 11/22/2011 02:57 AM, Stargazer wrote:
 On 22-Nov-2011 09:43, Aaron Freeman wrote:
 I hope so. Since it's new, this is a great time for feedback
 For the first time, Resin 4.0.24 doesn't work out of the box when added to
 Eclipse as a new server.
 I go through this process pain free for each new release, but now
 immediately see the message 'default' is an unknown server in the
 configuration file and the server doesn't start.

 To recreate, use Servers | New | Server | Resin 4.0 | (Create runtime
 specifying the new Resin home) | Next | Finish (add apps as necessary) |
 try
 to start the server.
 In fact the 4.0.23 server is still present which I'm sticking with for
 now.

 I had a similar issue with 4.0.23 (though it was my fault), and by switching
 out:

 -conf ${resin.configuration.file}

 with:

 -conf /path/to/resin.xml

 it went away.  I have always set that explicitly though and have never tried
 to figure out how ${resin.configuration.file} gets set.

 Not sure that helps much, but thought I would throw it out there as
 something to try.
 Thanks. Still not right - the path was fully qualified anyway - but on a
 hunch I copied the 4 files from the 4.0.23-config (admin-users.xml,
 app-default.xml, resin.xml and health.xml) over the new ones and resin
 started. Theres something wrong in the newly generated config files
 themselves. I notice health.xml doesn't appear in the new set.

You can also just add a server id= .../ to the resin.xml. This is an 
issue we're working on.

The health.xml has been moved to local.d in the distribution.

-- Scott

 Aaron



 ___
 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] Database Conflict

[Scott Ferguson]

On 11/21/2011 04:25 AM, Aaron Freeman wrote:


With the latest resin-pro-4.0.23 plugin we are now getting an error 
when trying to start multiple instances of Resin within a single 
Eclipse environment:


_java.sql.SQLException_: CREATE for path 
'C:\opt\project\ext\resin-pro-4.0.23\resin-data\default\tmp\temp_file' 
failed, because the file already exists.  CREATE can not override an 
existing table.


We were able to get around the issue by adding a --data-directory 
argument to the Resin plugin's Program arguments section, but why do 
we have to do that suddenly?


What is the best practice for starting multiple VMs?Is there some 
setting we can use to get it to use WEB-INF (not sure that is a good 
idea), or ${resin.root}/${server}/tmp or something?


Any other options that would be better than having to explicitly add 
that extra program argument with a hardcoded path?




If your servers have different server-id's that conflict won't happen.

What's happening is that you're starting two servers with the same name 
(but different ports I assume?) and in the same directory.


I'll add this as a bug report because the Eclipse plugin should be 
upgraded to somehow handle that automatically.


-- Scott


Thanks,

-a


___
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] 4.0.24 configuration notes

[Scott Ferguson]

As part of our work on simplifying the Resin configuration to make 
dynamic/cloud servers easier to deploy, 4.0.24 now has

   rpm support
   two new configuration tags resin:properties and server-multi
   a new EL function rvar()
   two new CLI commands start-all and generate-password
   and a new command-line script resinctl

all to help make the cluster/cloud deployment easier (and also help 
simplify /resin-admin setup).

Our goal is to make a new dynamic server require very little in specific 
configuration to attach to the triad and start working. If the small 
specific configuration can fit in an Amazon-style user-data, that would 
be perfect (we're not quite there yet, but 4.0.24 is a good step forward.)

The start-all is used in the updated /etc/init.d/resin to start all 
servers that are configured on the local IP addresses of the current 
machine, avoiding the earlier requirement of specifying the -server. 
With 4.0.24, the /etc/init.d/resin can be left as-is.

If you look at the new default resin.xml, it has a

resin:properties path=${__DIR__}/resin.properties

and several uses of rvar like http port=${rvar('http')}/. The 
resin:properties is similar to the resin:import, but loads a 
properties file and saves the values in EL expressions which are then 
available to the resin.xml. Basically, this means that many sites will 
only need to change the resin.properties and may never need to touch the 
resin.xml.

The new server-multi works with the resin.properties to make it easier 
to define the triad or the entire cluster. Instead of creating on 
server entry for each server, you can use the server-multi and set 
its address-list attribute to list all of the servers in the 
resin.properties like:

   app_tier : 192.168.1.10 192.168.1.11 192.168.1.12

and

server-multi id-prefix=app- address-list=${rvar('app_tier')} 
port=6800/

Together with the CLI start-all, this lets you configure the app-tier 
cluster without modifying either the resin.xml or the /etc/init.d/resin.

The resin.xml also includes a

resin:import fileset=${__DIR__}/local.d/*.xml/

which will let you add configuration such as database tags in a 
separate *.xml without needing to modify the standard one.

resinctl is now placed in /usr/bin for the make install, the rpm, and 
the deb. So it's always available. It's similar to bin/httpd.sh, but has 
the default installed locations build-in. In other words, on a Linux 
system, it already knows about /etc/resin, /var/log/resin, /var/www, and 
/usr/local/share/resin.

-- Scott



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

Re: [Resin-interest] 4.0.24 configuration notes

[Scott Ferguson]

On 11/21/2011 11:08 AM, Aaron Freeman wrote:

 -Original Message-
 If you look at the new default resin.xml, it has a

 resin:properties path=${__DIR__}/resin.properties

 and several uses of rvar likehttp port=${rvar('http')}/. The
 resin:properties  is similar to the resin:import, but loads a properties
 file
 and saves the values in EL expressions which are then available to the
 resin.xml. Basically, this means that many sites will only need to change
 the
 resin.properties and may never need to touch the resin.xml.
 This could be awesome!

I hope so. Since it's new, this is a great time for feedback

 Will modifying the resin.properties force your resin instance to restart?

Yes. It's the same mechanism as modifying resin.xml causing a restart.

 The resin.xml also includes a

 resin:import fileset=${__DIR__}/local.d/*.xml/

 which will let you add configuration such asdatabase  tags in a separate
 *.xml without needing to modify the standard one.
 Same question as above, will modifying the *.xml files force your resin
 instance to restart?

Yep.

-- Scott



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

Re: [Resin-interest] Need help with host/web-app config

[Scott Ferguson]

On 11/15/2011 12:04 PM, Rick Mann wrote:
 I've been doing this a while now, so I'm not sure what I've overlooked to 
 cause this behavior. I'm migrating my server from 4.0.20 on one host to a new 
 host on 4.0.23. I'm coping parts of the resin.xml file in chunks, verifying 
 each host as I go. The first went smoothly, as did the second. When I added 
 the third, it seems to work, but it serves up pages from the second. Here are 
 the relevant bits:

Resin generally identifies hosts and web-apps uniquely by their root 
directory. So the second and third host elements which share the 
root-directory are probably being combined.

-- Scott

 host host-name=latencyzero.com 
 root-directory=/lz/var/www/com/latencyzero
   host-alias-regexptycho.latencyzero.com[\.]?/host-alias-regexp   
 
   host-alias-regexp(www\.)?latencyzero.com[\.]?/host-alias-regexp 
 
   web-app id=/ document-directory=www
 //


 host host-name=roderickmann.org 
 root-directory=/lz/var/www/org/roderickmann
   host-alias-regexp(www\.)?roderickmann.org[\.]?/host-alias-regexp
 
   host-alias-regexp(www\.)?rickmann.org[\.]?/host-alias-regexp
 
   web-app id=/ document-directory=www
 //

 host host-name=mgfb.roderickmann.org 
 root-directory=/lz/var/www/org/roderickmann
   host-alias-regexpmgfb\.roderickmann.org[\.]?/host-alias-regexp  
 
   host-alias-regexpblog\.roderickmann.org[\.]?/host-alias-regexp  
 
   web-app id=/ document-directory=mgfb
 //


 Browsing to http://latencyzero.com/; gets the first content correctly. 
 Browsing to http://roderickmann.org/; gets the second content correctly. 
 Browsing to http://mgfb.roderickmann.org/;, however, returns the content 
 from the second webapp.

 Any ideas? Thanks!




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

Re: [Resin-interest] Need help with host/web-app config

[Scott Ferguson]

On 11/15/2011 12:24 PM, Rick Mann wrote:
 On 11 15, 2011, at 12:19 , Scott Ferguson wrote:

 On 11/15/2011 12:04 PM, Rick Mann wrote:
 I've been doing this a while now, so I'm not sure what I've overlooked to 
 cause this behavior. I'm migrating my server from 4.0.20 on one host to a 
 new host on 4.0.23. I'm coping parts of the resin.xml file in chunks, 
 verifying each host as I go. The first went smoothly, as did the second. 
 When I added the third, it seems to work, but it serves up pages from the 
 second. Here are the relevant bits:
 Resin generally identifies hosts and web-apps uniquely by their root
 directory. So the second and thirdhost  elements which share the
 root-directory are probably being combined.
 Huh. Shouldn't it use the canonical host name?

It can't, because hosts can be deployed like host-deploy and might be 
modified by an explicit host (which might set the canonical host name.)

 Anyway, I tried changing the second to be /lz/var/www/org/roderickmann/mgfb, 
 and the web-app inside to point to ., but it still does the same thing.

Hmm. If you turn on logging for the dispatch/startup, you should see the 
Host[production:host:host-name] which will include the canonical name. 
Can you check that and see which host name is being started?

-- Scott

 -- Scott

 host host-name=latencyzero.com 
 root-directory=/lz/var/www/com/latencyzero
 host-alias-regexptycho.latencyzero.com[\.]?/host-alias-regexp   
 
 host-alias-regexp(www\.)?latencyzero.com[\.]?/host-alias-regexp 
 
 web-app id=/ document-directory=www
 //


 host host-name=roderickmann.org 
 root-directory=/lz/var/www/org/roderickmann
 host-alias-regexp(www\.)?roderickmann.org[\.]?/host-alias-regexp
 
 host-alias-regexp(www\.)?rickmann.org[\.]?/host-alias-regexp
 
 web-app id=/ document-directory=www
 //

 host host-name=mgfb.roderickmann.org 
 root-directory=/lz/var/www/org/roderickmann
 host-alias-regexpmgfb\.roderickmann.org[\.]?/host-alias-regexp  
 
 host-alias-regexpblog\.roderickmann.org[\.]?/host-alias-regexp  
 
 web-app id=/ document-directory=mgfb
 //


 Browsing to http://latencyzero.com/; gets the first content correctly. 
 Browsing to http://roderickmann.org/; gets the second content correctly. 
 Browsing to http://mgfb.roderickmann.org/;, however, returns the content 
 from the second webapp.

 Any ideas? Thanks!



 ___
 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