Re: [Resin-interest] Eclipse Plugin
On Wed, May 13, 2009 at 08:22:19PM +0200, Michael Ludwig wrote:
So after a couple of minutes, this error message pops up in a window
labeled Problem Occurred and the running and serving Resin is stopped,
maybe because it hasn't reported startup success back to the parent
process.
I added -consoleLog to my eclipse.ini, but I have no idea where the log
is going. If it is just the console window in the IDE, there is nothing
special to see, just the usual Resin startup messages plus additional
debug info my application generates.
Can you try running eclipse from the command line and adding the
-consoleLog? On Windows it's supposed to pop up a Java console
window, but it might not work in eclipse.ini.
(2) in place
A new error message :-) - Reference to undefined variable
resin.configuration.file. Won't start :-(
I can't reproduce this error. But I swear it was there the first time
around!
:-) Could be some artifact from the upgrade.
But with this in place configuration, all I get is 404. I tried all
kinds of possible context paths, but none seems to work. Which is sort
of logical, as I don't see my application's startup blurb in the console
log. On the other hand, Resin mentions it (DbXml01):
[20:13:46.062] {main} resin.home = C:\MILU\Server\resin-4.0.0\
[20:13:46.062] {main} resin.root = C:\MILU\Server\resin-4.0.0\
[20:13:46.328] {main} resin.conf =
/C:/MILU/eclipse/plugins/com.caucho.resin.eclipse_4.0.0/conf/resin40/in-place.xml
[20:13:46.328] {main}
[20:13:46.328] {main} server = 127.0.0.1:0 (:)
[20:13:46.328] {main} user.name = MiLu
[20:13:46.328] {main}
[20:13:46.593] {main} WebApp[http://default/DbXml01] active
[20:13:46.593] {main} Host[default] active
[20:13:46.593] {main}
[20:13:46.609] {main} http listening to *:8099
[20:13:46.625] {main}
[20:13:46.625] {main} Server[id=,cluster=] active
[20:13:46.625] {main} Resin[id=] started in 1188ms
20:14:59,20 C:\MILU\dev\ds
# netstat -p tcp -na | findstr 8099
TCP0.0.0.0:8099 0.0.0.0:0 ABHÖREN
TCP127.0.0.1:4394 127.0.0.1:8099 SCHLIESSEN_WARTEN
TCP127.0.0.1:8099 127.0.0.1:4394 FIN_WARTEN_2
The port I specified is taken into account, the address isn't.
It's trying to open http://localhost:8099/DbXml01 and not getting
anything? It looks like Resin's finding the webapp, so something else
must be the issue.
This is a hack, but can you add finest logging to the in-place.xml in
C:/MILU/eclipse/plugins/com.caucho.resin.eclipse_4.0.0/conf/resin40/in-place.xml
This should do it:
logger name=com.caucho level=finest/
That should show why Resin's serving a 404.
Emil
Emil Ong
Chief Evangelist
Caucho Technology, Inc.
Tel. (858) 456-0300
mailto:e...@caucho.com
http://blog.caucho.com/
Caucho: Reliable Open Source
-- Resin: application server
-- Quercus: PHP in Java
-- Java CanDI: contexts and dependency injection
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Custom hessian serialization in Resin
Is there a way to register custom hessian serializers in Resin? Resin4 can't serialize java.net.URL :-( Thanks, Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Regarding bug 3418, Watchdog Startup Synchronization
On May 14, 2009, at 12:57 PM, Rob Lockstone wrote: Environment: Resin Pro 3.1.9 (100 Server License) on 64-bit Windows 2003/08 Server with Java 1.5_18. This bug http://bugs.caucho.com/view.php?id=3418 is still present in Resin Pro 3.1.9. I've already updated the bug, but figured I would post here because I don't know how often bugs are read/updated. Looking at the code, the socket timeout is only 1s, which is pretty short. The timeout is in com.caucho.boot.WatchdogProcess.runInstance -- Scott Our deployment system uses the Windows SC (Service Controller) commands to stop and then start resin. I built in a five second delay between the time the SC query command notifies me that resin has stopped and the time that it attempts to start it up again. My concern, of course, is that five seconds might not always be enough time for the watchdog to completely exit. The original reporter of this bug indicates that, on a busy machine, he has to wait as long as 15 seconds. However, it's unclear to me if he's confirmed that resin has stopped before initiating the 15 second delay. The five second delay I put in kicks in *after* I've confirmed that resin has stopped as reported by the sc query command. Is there any way to know if this five second delay is a legitimate hack? Waiting for the dev/QA cycle for the 3.1.10 release isn't going to work for us on our time table. I'm looking at the watchdog code now to see if I can figure out a fix, but I'm not going to be able to spend too much time on it, I'm afraid. Rob ___ 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 hessian serialization in Resin
Solved the problem of serializing a byte[]... it had nothing to do
with the byte[], it was because we are calling overloaded methods.
Must call HessianProxyFactory.setOverloadEnabled(true), which we here
are now calling the setBroken(false) method :-)
Still can't deserialize java.net.URL, looks like Hessian is calling
the URL(String) constructor and passing in a null.
Jeff
On Thu, May 14, 2009 at 11:27 AM, Jeff Schnitzer j...@infohazard.org wrote:
In addition, we're having problems serializing a byte[].
One additional complication is that if we turn com.caucho.hessian
logging to finest, it throws an exception that is not thrown when
logging is lower (and not useful, unfortunately):
[11:21:06.493] {http--8080-9} WARNING [ErrorPageManager]
java.lang.IllegalStateException: 1 is an unknown object type
[11:21:06.493] {http--8080-9} at
com.caucho.hessian.io.HessianDebugState$ObjectState.init(HessianDebugState.java:1345)
[11:21:06.493] {http--8080-9} at
com.caucho.hessian.io.HessianDebugState$State.nextObject(HessianDebugState.java:523)
[11:21:06.493] {http--8080-9} at
com.caucho.hessian.io.HessianDebugState$CompactListState.next(HessianDebugState.java:1651)
[11:21:06.493] {http--8080-9} at
com.caucho.hessian.io.HessianDebugState.next(HessianDebugState.java:98)
Thanks,
Jeff
On Thu, May 14, 2009 at 11:05 AM, Jeff Schnitzer j...@infohazard.org wrote:
Is there a way to register custom hessian serializers in Resin?
Resin4 can't serialize java.net.URL :-(
Thanks,
Jeff
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Regarding bug 3418, Watchdog Startup Synchronization
On May 14, 2009, at 14:03, Scott Ferguson wrote: On May 14, 2009, at 12:57 PM, Rob Lockstone wrote: Environment: Resin Pro 3.1.9 (100 Server License) on 64-bit Windows 2003/08 Server with Java 1.5_18. This bug http://bugs.caucho.com/view.php?id=3418 is still present in Resin Pro 3.1.9. I've already updated the bug, but figured I would post here because I don't know how often bugs are read/updated. Looking at the code, the socket timeout is only 1s, which is pretty short. The timeout is in com.caucho.boot.WatchdogProcess.runInstance Agreed. The logs indicate that the closingInstance() method is getting called. But look at the time stamps between the time when that happens and the time when it attempts to restart the WatchdogTask (which is when the problem occurs): [2009/05/14 06:29:58.873] WatchdogProcess[Watchdog[],1] stopping Resin [2009/05/14 06:30:01.827] java.lang.IllegalStateException: Can't start new task because of old task 'WatchdogTask[Watchdog[]]' That's about 3 seconds. So I don't think the socket time out is an issue. It does get to the closeInstance() method. In the closingInstance() method, line 322 is: int status = process.exitValue(); So that means it has to wait for the process itself to exit. The destroy() method does a waitFor() on the process, which is reasonable. However, that waitFor() isn't encapsulated by any kind of maximum wait time thread. Java doesn't offer a waitFor() method with a wait time. In code that I've written that uses Processes, I always encapsulate the Process inside a thread and specify a maximum amount of time that I'm willing to wait for the process to end. In theory, this could lead to memory leaks if the process *never* ends. But at least that information can be logged. But anyway, none of this explains why the specified WatchdogTask isn't being set to null in the Watchdog (it does, but only in the kill() method), so that means the same Watchdog instance is getting re-used. That's where I'm getting a little lost in the code. I see the WatchdogManager, and I see that there are a few places that Watchdog instances get added to the Map, but I don't see where they get removed. Should there be some point where a Watchdog instance gets removed from the WatchdogManager? Then again, given that resin is getting completely shut down, why is there even a WatchdogManager and list of Watchdogs to worry about? Shouldn't all that disappear along with everything else? Rob -- Scott Our deployment system uses the Windows SC (Service Controller) commands to stop and then start resin. I built in a five second delay between the time the SC query command notifies me that resin has stopped and the time that it attempts to start it up again. My concern, of course, is that five seconds might not always be enough time for the watchdog to completely exit. The original reporter of this bug indicates that, on a busy machine, he has to wait as long as 15 seconds. However, it's unclear to me if he's confirmed that resin has stopped before initiating the 15 second delay. The five second delay I put in kicks in *after* I've confirmed that resin has stopped as reported by the sc query command. Is there any way to know if this five second delay is a legitimate hack? Waiting for the dev/QA cycle for the 3.1.10 release isn't going to work for us on our time table. I'm looking at the watchdog code now to see if I can figure out a fix, but I'm not going to be able to spend too much time on it, I'm afraid. Rob ___ 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
