Re: [Resin-interest] Resin 4.0.9 release

2010-08-10 Thread Jan Kriesten 

Hi Scott,

the snapshot hasn't solved the restart-problem on our server:

Resin Professional 4.0.s100809 (built Mon, 09 Aug 2010 11:41:02 PDT)
[07:19:42.671] {main} ProResin[id=] started in 91076ms
[...]
[07:50:33.998] {main} ProResin[id=] started in 77686ms
[...]
[08:21:38.785] {main} ProResin[id=] started in 77336ms
[...]
[08:52:42.604] {main} ProResin[id=] started in 76134ms

So it's seems to be every 30 minutes. :-/

The watchdog-manager.log is cluttered with the following entries - but I
don't know what to make of them:

[2010/08/10 07:58:40.775]
com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
Alarm[alarm[HostController[null]]] 30116ms
[2010/08/10 07:58:40.775]
com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
Alarm[alarm[ProServer[id=,cluster=]]] 30117ms
[2010/08/10 07:59:10.775]
com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
Alarm[alarm[com.caucho.network.listen.SocketLi
nklistener$suspendrea...@71ce5e7a]] 60111ms
[2010/08/10 07:59:10.775]
com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
Alarm[alarm[NetworkListenService[]]] 60110ms
[2010/08/10 07:59:40.775]
com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
alarm[alarm[com.caucho.boot.watchdogmana...@23
9cd5f5]] 90103ms
[2010/08/10 07:59:40.776]
com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
alarm[alarm[com.caucho.log.rotatestr...@4ab346
46]] 66890ms
[2010/08/10 08:00:10.775]
com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
Alarm[alarm[WebAppController$2034408626[null]]
] 6ms
[2010/08/10 08:00:10.776]
com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
Alarm[alarm[SessionManager[]]] 60001ms
[2010/08/10 08:00:40.775]
com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
Alarm[alarm[HostController[null]]] 6ms
[2010/08/10 08:00:40.776]
com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
Alarm[alarm[ProServer[id=,cluster=]]] 60001ms
[...]
[2010/08/10 11:11:10.665]
com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
Alarm[alarm[SessionManager[]]] 59941ms
[2010/08/10 11:11:10.724]
com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
Alarm[alarm[HostController[null]]] 30059ms
[2010/08/10 11:11:40.665]
com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
Alarm[alarm[ProServer[id=,cluster=]]] 59941ms
[2010/08/10 11:11:40.724]
com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
Alarm[alarm[NetworkListenService[]]] 6ms
[2010/08/10 11:12:10.665]
com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
Alarm[alarm[com.caucho.network.listen.SocketLi
nklistener$suspendrea...@71ce5e7a]] 6ms
[2010/08/10 11:12:10.724]
com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
alarm[alarm[com.caucho.boot.watchdogmana...@23
9cd5f5]] 6ms
[2010/08/10 11:12:40.665]
com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
Alarm[alarm[WebAppController$2034408626[null]]
] 59941ms
[2010/08/10 11:12:40.724]
com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
Alarm[alarm[SessionManager[]]] 30059ms

Other errors are not reported by resin, though.

Best regards, --- Jan.



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

Re: [Resin-interest] Resin 4.0.9 release

2010-08-10 Thread Scott Ferguson 
Jan Kriesten wrote:
 Hi Scott,

 the snapshot hasn't solved the restart-problem on our server:

 Resin Professional 4.0.s100809 (built Mon, 09 Aug 2010 11:41:02 PDT)
 [07:19:42.671] {main} ProResin[id=] started in 91076ms
 [...]
 [07:50:33.998] {main} ProResin[id=] started in 77686ms
 [...]
 [08:21:38.785] {main} ProResin[id=] started in 77336ms
 [...]
 [08:52:42.604] {main} ProResin[id=] started in 76134ms

 So it's seems to be every 30 minutes. :-/
   
Thanks.

It's not simply the ping because the restart isn't happening here. I'm 
working on improving the logging on both the Resin and Watchdog to get 
better information about this.
 The watchdog-manager.log is cluttered with the following entries - but I
 don't know what to make of them:

 [2010/08/10 07:58:40.775]
 com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
 Alarm[alarm[HostController[null]]] 30116ms
   

That may be related. When a Resin alarm (internal timer) is woken, it 
checks against the time it expected to be woken up. If that time is too 
big (over 30s) it prints that warning. If there's a big GC or 100% CPU, 
that might be expected, but that message is in the watchdog, so there's 
no good reason for the delay.

-- Scott
 
 [2010/08/10 07:58:40.775]
 com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
 Alarm[alarm[ProServer[id=,cluster=]]] 30117ms
 [2010/08/10 07:59:10.775]
 com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
 Alarm[alarm[com.caucho.network.listen.SocketLi
 nklistener$suspendrea...@71ce5e7a]] 60111ms
 [2010/08/10 07:59:10.775]
 com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
 Alarm[alarm[NetworkListenService[]]] 60110ms
 [2010/08/10 07:59:40.775]
 com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
 alarm[alarm[com.caucho.boot.watchdogmana...@23
 9cd5f5]] 90103ms
 [2010/08/10 07:59:40.776]
 com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
 alarm[alarm[com.caucho.log.rotatestr...@4ab346
 46]] 66890ms
 [2010/08/10 08:00:10.775]
 com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
 Alarm[alarm[WebAppController$2034408626[null]]
 ] 6ms
 [2010/08/10 08:00:10.776]
 com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
 Alarm[alarm[SessionManager[]]] 60001ms
 [2010/08/10 08:00:40.775]
 com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
 Alarm[alarm[HostController[null]]] 6ms
 [2010/08/10 08:00:40.776]
 com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
 Alarm[alarm[ProServer[id=,cluster=]]] 60001ms
 [...]
 [2010/08/10 11:11:10.665]
 com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
 Alarm[alarm[SessionManager[]]] 59941ms
 [2010/08/10 11:11:10.724]
 com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
 Alarm[alarm[HostController[null]]] 30059ms
 [2010/08/10 11:11:40.665]
 com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
 Alarm[alarm[ProServer[id=,cluster=]]] 59941ms
 [2010/08/10 11:11:40.724]
 com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
 Alarm[alarm[NetworkListenService[]]] 6ms
 [2010/08/10 11:12:10.665]
 com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
 Alarm[alarm[com.caucho.network.listen.SocketLi
 nklistener$suspendrea...@71ce5e7a]] 6ms
 [2010/08/10 11:12:10.724]
 com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
 alarm[alarm[com.caucho.boot.watchdogmana...@23
 9cd5f5]] 6ms
 [2010/08/10 11:12:40.665]
 com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
 Alarm[alarm[WebAppController$2034408626[null]]
 ] 59941ms
 [2010/08/10 11:12:40.724]
 com.caucho.util.alarm$coordinatorthr...@3ce95a56 slow alarm
 Alarm[alarm[SessionManager[]]] 30059ms

 Other errors are not reported by resin, though.

 Best regards, --- Jan.




   



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

[Resin-interest] Duplicate singletons

2010-08-10 Thread Jeff Schnitzer 
There seems to still be a problem with singletons exposed as hessian
services.  I can create a test project if necessary, but I'm seeing
this behavior in two separate applications:

1) Create a @Singleton bean
2) Give the bean a @Startup @PostConstruct method that initializes some data
3) Give the bean a @HessianService annotation
4) Call the bean via hessian
5) Observe that the data isn't initialized

This was a problem long ago in 4.0.0 (with the equivalent annotations
at the time) but I thought it was fixed sometime later.  I could be
wrong about that though.  The old workaround was to have the hessian
endpoint on a different bean which itself injects the singleton.

Jeff


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

Re: [Resin-interest] Resin 4.0.9 release

2010-08-10 Thread Jan Kriesten 

Hi Scott,

 It's not simply the ping because the restart isn't happening here. I'm
 working on improving the logging on both the Resin and Watchdog to get
 better information about this.

that would be helpful. Funny thing is, it only happens on one of the
machines. The configuration is the same on both, the only difference is

a) in the number of virtual hosts (104 to 2)
b) the number of provdided database jndi connections (57 to 5)

Maybe this helps?

Best regards, --- Jan.


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