Re: [Resin-interest] resin 4.0.1 : Chinese UTF8 characters problems in Quercus
On Tuesday 06 October 2009 00:15:44 smallufo wrote: > Both of my java and php file are encoded in UTF8 > It seems Chinese words in php can successfully pass to java side , > BUT , java side cannot correctly pass Chinese words back. > see my attachments for detail . > > If you cannot see the attachment , I uploaded to here : > > http://i273.photobucket.com/albums/jj212/smallufo/quercus_Chinese_bug.gif Are you sure your javac encoding is set to utf-8? It should match your source encoding, or else. And it can still be latin-1. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Automating virtual hosting....
On Tuesday 19 May 2009 21:36:40 Peter Amiri wrote:
We've been there, done that!
Sample resin.conf:
--> All your interesting settings stuff goes here! <--
2W
1mb
1mb
1mb
jdbc/main
SELECT password FROM auth_users WHERE login =
?
SELECT name FROM auth_roles WHERE login = ?
none
jdbc/main
jdbc:postgresql://localhost:5432/${database}
${db.user}
${db.user}
64
20
10s
then, we have resin/conf/virtual/ directories, which contain only one
configuration file: host.xml
http://caucho.com/ns/resin";
xmlns:resin="http://caucho.com/ns/resin/core";>
(this is one example)
This way, you get virtual hosting, adding and removing sites without restarting
resin, flexible site directory locations and it works generally just fine.
The trick is
There's another way, you can leave unchanged
this way, your conf/virtual//host.xml will look like this:
http://caucho.com/ns/resin"; root-directory="/home/yoursite./www">
2W
1mb
1mb
1mb
jdbc/main
SELECT password FROM auth_users WHERE login =
?
SELECT name FROM auth_roles WHERE login = ?
none
jdbc/main
jdbc:postgresql://192.168.200.254:5432/yourdb
yourdb
yourdb
64
20
30s
But, I've chose to move all that info into host-default, and make host.xml only
supply variables.
> Scott,
>
> Thanks for the input. May be I'm going about this the wrong way. What
> is the best practices for setting up shared virtual hosting of Resin.
> I basically want to provide Railo (http://www.getrailo.org) hosting.
> Railo is a CFML engine that can run on top of any J2EE container.
> Right now I am using the cPanel control panel and have hooks
> programmed in to create the necessary domain.xml files which are
> tapped into a single install of Resin.
>
> The current architecture works ]like this, when a user signs up, a new
> domain.xml file is created and stored in a config directory. Then the
> script does a touch on the resin.conf file to force a restart. The
> resin.conf includes the newly created domain.xml using the
> tag that reads all the xml files in the config
> directory. So everything is working and automated, I just wanted to
> know if there was a way to make it so the applications didn't see the
> service go up and down.
>
> Any advice you could provide on this would be appreciated.
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Why does resin.conf treeloads ${resin.*}/lib explicitly?
I was profiling file access, and I've found, by doing ls -al /proc/$resinpid/fd, that resin (3.1.8 in this case) keeps two fd-s on every file in resin-3.1.8/lib. After I've removed from resin.conf, I've experienced no actual difference, except that second fd copy of every file no longer haunts /proc/$foo/fd, and the fact that server starts up somewhat faster than it used to! (Server start up time is same, but it renders the first request way much sooner In case of a very massive app on my shabby test machine, 40 sec difference!) So, why do those tree-loaders are kept in resin.conf? I can justify resin.home one - it might be different than resin-3.1.8/lib, but why list resin.root one here if it only makes things slightly worse? Or do they carry a Deep Internal Meaning? Or are them not supposed to point to the same dir as resin loads implicitly? Maybe we've messed it up? Maybe they're just left-over and should be dropped from config? ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Resin 3.1.8: thread deadlock against Xalan XSLTC
Hi *! I've occassionally found a thread deadlock in a halted instance of Resin-3.1.8. I've appended the jstack trace. Xalan XSLTC does employ some aggressive classloading, since it's a XSLT-to-java compiler. It seems that it would occassionally (I don't remember this happening often) cause resin's classloader to fail. Looks like thread http--8123-29 and thread http--8123-33 are deadlocked in the classloader code, Found one Java-level deadlock: = "http--8123-120$22712691": waiting to lock monitor 0x08b126ac (object 0x5828b390, a ru.sbtc.util.StylesheetManager), which is held by "http--8123-25$8931423" "http--8123-25$8931423": waiting to lock monitor 0x08b0b5e0 (object 0x5525c6b0, a com.caucho.loader.SystemClassLoader), which is held by "http--8123-33$15917864" "http--8123-33$15917864": waiting to lock monitor 0x089d2be0 (object 0x5d3fea48, a com.caucho.loader.ClassEntry), which is held by "http--8123-29$31079116" "http--8123-29$31079116": waiting to lock monitor 0x08b0b5e0 (object 0x5525c6b0, a com.caucho.loader.SystemClassLoader), which is held by "http--8123-33$15917864" Java stack information for the threads listed above: === "http--8123-120$22712691": at ru.sbtc.util.StylesheetManager.getTransformer(StylesheetManager.java:139) - waiting to lock <0x5828b390> (a ru.sbtc.util.StylesheetManager) at ru.sbtc.sitebuilder.servlet.XMLMenuServlet.doGet(XMLMenuServlet.java:84) at javax.servlet.http.HttpServlet.service(HttpServlet.java:114) at javax.servlet.http.HttpServlet.service(HttpServlet.java:91) ... "http--8123-25$8931423": at org.apache.xalan.xsltc.compiler.XPathLexer.(XPathLexer.java:165) at org.apache.xalan.xsltc.compiler.Parser.parseTopLevel(Parser.java:1092) at org.apache.xalan.xsltc.compiler.Parser.parseExpression(Parser.java:1055) at org.apache.xalan.xsltc.compiler.If.parseContents(If.java:61) at org.apache.xalan.xsltc.compiler.SyntaxTreeNode.parseChildren(SyntaxTreeNode.java:432) at org.apache.xalan.xsltc.compiler.VariableBase.parseContents(VariableBase.java:229) at org.apache.xalan.xsltc.compiler.Variable.parseContents(Variable.java:53) at org.apache.xalan.xsltc.compiler.Stylesheet.parseOwnChildren(Stylesheet.java:577) at org.apache.xalan.xsltc.compiler.Stylesheet.parseContents(Stylesheet.java:559) at org.apache.xalan.xsltc.compiler.Parser.createAST(Parser.java:383) at org.apache.xalan.xsltc.compiler.XSLTC.compile(XSLTC.java:361) at org.apache.xalan.xsltc.compiler.XSLTC.compile(XSLTC.java:446) at org.apache.xalan.xsltc.trax.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:799) at ru.sbtc.util.StylesheetManager.loadTemplates(StylesheetManager.java:174) at ru.sbtc.util.StylesheetManager.getTransformer(StylesheetManager.java:161) - locked <0x5828b390> (a ru.sbtc.util.StylesheetManager) at ru.sbtc.sitebuilder.servlet.XMLMenuServlet.doGet(XMLMenuServlet.java:84) at javax.servlet.http.HttpServlet.service(HttpServlet.java:114) at javax.servlet.http.HttpServlet.service(HttpServlet.java:91) ... "http--8123-33$15917864": at com.caucho.loader.DynamicClassLoader.loadClass(DynamicClassLoader.java:1431) - waiting to lock <0x5d3fea48> (a com.caucho.loader.ClassEntry) at com.caucho.loader.DynamicClassLoader.findClassImpl(DynamicClassLoader.java:1390) at com.caucho.loader.DynamicClassLoader.loadClassImpl(DynamicClassLoader.java:1289) at com.caucho.loader.SystemClassLoader.loadClassImpl(SystemClassLoader.java:217) at com.caucho.loader.DynamicClassLoader.loadClass(DynamicClassLoader.java:1219) at com.caucho.loader.DynamicClassLoader.loadClass(DynamicClassLoader.java:1203) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) - locked <0x5525c6b0> (a com.caucho.loader.SystemClassLoader) at org.apache.xalan.xsltc.compiler.Stylesheet.setImportPrecedence(Stylesheet.java:324) at org.apache.xalan.xsltc.compiler.Import.parseContents(Import.java:115) at org.apache.xalan.xsltc.compiler.Stylesheet.parseOwnChildren(Stylesheet.java:587) at org.apache.xalan.xsltc.compiler.Stylesheet.parseContents(Stylesheet.java:559) at org.apache.xalan.xsltc.compiler.Parser.createAST(Parser.java:383) at org.apache.xalan.xsltc.compiler.XSLTC.compile(XSLTC.java:361) at org.apache.xalan.xsltc.compiler.XSLTC.compile(XSLTC.java:446) at org.apache.xalan.xsltc.trax.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:799) at ru.sbtc.util.StylesheetManager.loadTemplates(StylesheetManager.java:174) at ru.sbtc.util.StylesheetManager.getTransformer(StylesheetManager.java:161) - locked <0x57067f10> (a ru.sbtc.util.StylesheetManager) at ru.sb
[Resin-interest] 304 Not Modified, Content-Length, and entity headers
Hello *!
For some reason, Resin 3.1, when responding with 304 due to
sendError(SC_NOT_MODIFIED), is going to reply with the header
Content-Length = zero:
0x0030: 068c 94f5 4854 5450 2f31 2e30 2033 3034 HTTP/1.0.304
0x0040: 204e 6f74 204d 6f64 6966 6965 640d 0a53 .Not.Modified..S
0x0050: 6572 7665 723a 2052 6573 696e 2f33 2e31 erver:.Resin/3.1
0x0060: 2e37 610d 0a45 7870 6972 6573 3a20 4672 .7a..Expires:.Fr
0x0070: 692c 2031 3920 4465 6320 3230 3038 2030 i,.19.Dec.2008.0
0x0080: 323a 3036 3a30 3720 474d 540d 0a45 5461 2:06:07.GMT..ETa
0x0090: 673a 2022 3669 566e 4c56 2b66 4958 4922 g:."6iVnLV+fIXI"
0x00a0: 0d0a 436f 6e74 656e 742d 4c65 6e67 7468 ..Content-Length
0x00b0: 3a20 300d 0a44 6174 653a 2054 6875 2c20 :.0..Date:.Thu,.
0x00c0: 3138 2044 6563 2032 3030 3820 3232 3a30 18.Dec.2008.22:0
0x00d0: 363a 3036 2047 4d54 0d0a 0d0a6:06.GMT
In fact, this isn't compliant with HTTP 1.1 specification, which reads:
[10.3.5] If the conditional GET used a strong cache validator (see section
13.3.3),
the response SHOULD NOT include other entity-headers. Otherwise (i.e., the
conditional GET used a weak validator), the response *MUST NOT* include other
entity-headers; this *prevents inconsistencies* between cached entity-bodies and
updated headers.
And, in fact, it broke our mod_accel, which responded to client with 200 OK,
Content-Length: 0, following with full body JFIF, and was very
surprised when
client dropped connection.
I understand that using mod_accel == DINOSAUR! in 2008, but still, why does
resin
do that? There's a special section in
resin/src/com/caucho/server/http/HttpResponse.java
line 365:
else if (statusCode == SC_NOT_MODIFIED || statusCode == SC_NO_CONTENT) {
hasContentLength = true;
os.write(_contentLengthBytes, 0, _contentLengthBytes.length);
os.print(0);
if (debug)
log.fine(_request.dbgId() + "Content-Length: 0");
}
After I've commented that, front-end ceased malfunction and we didn't see the
problem.
Still, is there a reason the above code is included? Maybe there's a useful
client which
fails to work properly when it see 304 without content-length? Or it's just a
rudiment and
can be removed?
Thanks for suggestions!
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] JDBC Basic authentication seems to thrash parameters
В сообщении от Wednesday 02 April 2008 15:22:54 Илья Казначеев написал(а):
> I'm, at the moment, experimenting with resin.form.character.encoding
> parameters and the like, but without much luck.
Also: I can inject nether setAttribute("resin.form.character.encoding") nor
setAttribute("j_use_cookie_auth") because I can't inject anything before
auth, and it's going to trash request parameters.
Also: "j_use_cookie_auth" attribute name is lame and not standard-compliant,
it should be resin.auth.something.
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] JDBC Basic authentication seems to thrash parameters
One should *first* initalize request's characterEncoding before reading http
parameters, otherwise all parameters would be parsed with default (as
in 'natural', not as in 'user-redefinable default') encoding, which is
usually Latin1.
Unfortunately, JDBC authenticator assumes it's the smartest class in the whole
classpath, so it reads request.getParameter("j_use_cookie_auth");
In authenticator, that is, before one could set CharacterEncoding to something
civilised, like UTF-8. This happens before any filter goes in, so you can't
fix it. The result is a weird problem: first request is going to bring
garbled data, subsequent requests would go just fine.
I'm, at the moment, experimenting with resin.form.character.encoding
parameters and the like, but without much luck.
Please tell me if I miss something.
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
