Re: [Resin-interest] java mysql and utf8
Try init-param characterEncoding=utf8 / on the database driver in resin.conf /Mattias - Original Message - Subject: [Resin-interest] java mysql and utf8 Date: Sat, 05 Apr 2008 07:57:21 +0200 From: Riccardo Cohen Hello I have a problem to build a full utf-8 application. I made a little sample that displays a list of items, and let the user edit/add/delete items. This works ok except with utf-8 chars. 1) if I put characters like ꄈ or Щ in the database using phpmyadmin, they display correctly on the html page in the 2) but if I want to change a string or add an item using these utf-8 chars, the mysql db stores ? instead 3) if I search %Щ% I find nothing (while searching for é or £ works all right) to allow utf-8 I've done the following : - uncomment utf-8 encoding in resin.conf - add response.setContentType(text/html;charset=utf-8); in every response and in every jsp page - in mysql change all text fields into utf8 : name char(50) collate utf8_unicode_ci, This does not seams to be enough. As it works all right with phpmyadmin, I suppose this is a jdbc driver issue. I've downloaded the latest mysqljdbc (mysql-connector-java-5.1.6-bin.jar) and tried to set some encoding attribute in the resin.conf database specification ( encoding=utf-8/), but it does not work. Thanks for any help. -- Très cordialement, Riccardo Cohen --- Articque http://www.articque.com 149 av Général de Gaulle 37230 Fondettes - France tel : 02-47-49-90-49 fax : 02-47-49-91-49 ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Is resin-3.1.x compatible with jdk 1.6?
Is resin-3.1.x compatible with jdk 1.6? thanks! ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Is resin-3.1.x compatible with jdk 1.6?
Yeah - Original Message - From: Liao Xuefeng [EMAIL PROTECTED] To: resin-interest@caucho.com Sent: Monday, April 07, 2008 5:20 PM Subject: [Resin-interest] Is resin-3.1.x compatible with jdk 1.6? Is resin-3.1.x compatible with jdk 1.6? 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] java mysql and utf8
Thanks a lot it works perfectly ! Now that I see it, I admit that I should have read mysql connector docs more carefully. But actually everything is working so nice by defaults in general, and there are so many docs to read... Mattias Jiderhamn wrote: Try init-param characterEncoding=utf8 / on the database driver in resin.conf /Mattias - Original Message - Subject: [Resin-interest] java mysql and utf8 Date: Sat, 05 Apr 2008 07:57:21 +0200 From: Riccardo Cohen Hello I have a problem to build a full utf-8 application. I made a little sample that displays a list of items, and let the user edit/add/delete items. This works ok except with utf-8 chars. 1) if I put characters like ꄈ or Щ in the database using phpmyadmin, they display correctly on the html page in the 2) but if I want to change a string or add an item using these utf-8 chars, the mysql db stores ? instead 3) if I search %Щ% I find nothing (while searching for é or £ works all right) to allow utf-8 I've done the following : - uncomment utf-8 encoding in resin.conf - add response.setContentType(text/html;charset=utf-8); in every response and in every jsp page - in mysql change all text fields into utf8 : name char(50) collate utf8_unicode_ci, This does not seams to be enough. As it works all right with phpmyadmin, I suppose this is a jdbc driver issue. I've downloaded the latest mysqljdbc (mysql-connector-java-5.1.6-bin.jar) and tried to set some encoding attribute in the resin.conf database specification ( encoding=utf-8/), but it does not work. Thanks for any help. -- Très cordialement, Riccardo Cohen --- Articque http://www.articque.com 149 av Général de Gaulle 37230 Fondettes - France tel : 02-47-49-90-49 fax : 02-47-49-91-49 ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Memory and slowdown...
We got heap dump working. Didn't have it enabled in the config... I'm spending some time looking through the profiles and heap dump now to see if I can see anything of interest. Andrew Scott Ferguson wrote: On Apr 2, 2008, at 8:21 AM, Andrew Fritz wrote: Our production servers have their maximum memory set to 2048m. Everything is fine for a while. Eventually the java process ends up with all 2048m allocated. At this point server load starts going up and response time gets bad. Eventually request start timing out. Restarting the server fixes the problem instantly and everything is good again. Occasionally one of the servers will do this on its own, presumably because it reaches the 1m free threshold. That appears to be to small a margin and a restart is needed well before there is only 1m left so I adjusted the minimum free memory from 1m to 24m. That seems like a bandage though. The heap dump returned a blank page so I'm not sure what was going on there. I'm just curious if anyone has any theories about what might be eating up memory over time. We are using Hibernate and PHP and of course java. Does the heap dump page work for you in a normal situation, i.e. before you start running out of memory? That's really the first place to start looking. The leaking memory might be obvious from Resin's heap dump page. If it's not enough information, the next step would be to use a more sophisticated memory profiler. -- Scott Andrew ___ 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] Memory and slowdown...
Hi Scott, I work with Andrew and we are still fighting this problem. Thanks for the advice.. we are analyzing the heap dump as you suggest. For added color to the problem, linked is an image of one of our servers load (courtesy of Munin). The other server behaves similarly, but the two do not manifest the problem in concert (this is a cluster environ with 2 servers). You can see that the mem usage climbs to the point where the server begins to encounter high load. The server load will drop dramatically along with mem usage when either the server is restarted (manually or automatically). http://sandeepghael.com/ServerMemoryPattern.jpg I was reading this Caucho resin page on perf tuning of the jvm and have a few questions: http://www.caucho.com/resin-3.0/performance/jvm-tuning.xtp 1) why is it best practice to set -Xms and maximum -Xmx heap sizes to the same value. Currently we are setting -Xmx at 1500m with -Xms undefined. 2) I actually experimented with lowering the max heap size to -1024M, and the problem seems to occur faster. We thought that lowering the JVM heap size might prevent OS swap if that was the problem. 3) if -Xss is 4m, and we have 256 max threads, that mean we should account for the OS to commit 4m*256=1G for stack space. Correct? 4) if our machine has 3.3G ram, what is best practice in terms of mem allocation for the JVM vs the rest of the OS? Our conf file below. regards, Sandeep (clustered environment) !-- - The JVM arguments -- jvm-arg-Xmx1500m/jvm-arg jvm-arg-Xss4m/jvm-arg jvm-arg-Xdebug/jvm-arg jvm-arg-Dcom.sun.management.jmxremote/jvm-arg !-- - Uncomment to enable admin heap dumps - jvm-arg-agentlib:resin/jvm-arg -- watchdog-arg-Dcom.sun.management.jmxremote/watchdog-arg !-- - Configures the minimum free memory allowed before Resin - will force a restart. -- memory-free-min24M/memory-free-min !-- Maximum number of threads. -- thread-max256/thread-max !-- Configures the socket timeout -- socket-timeout65s/socket-timeout !-- Configures the keepalive -- keepalive-max128/keepalive-max keepalive-timeout15s/keepalive-timeout On Thu, Apr 3, 2008 at 11:27 AM, Scott Ferguson [EMAIL PROTECTED] wrote: On Apr 2, 2008, at 8:21 AM, Andrew Fritz wrote: Our production servers have their maximum memory set to 2048m. Everything is fine for a while. Eventually the java process ends up with all 2048m allocated. At this point server load starts going up and response time gets bad. Eventually request start timing out. Restarting the server fixes the problem instantly and everything is good again. Occasionally one of the servers will do this on its own, presumably because it reaches the 1m free threshold. That appears to be to small a margin and a restart is needed well before there is only 1m left so I adjusted the minimum free memory from 1m to 24m. That seems like a bandage though. The heap dump returned a blank page so I'm not sure what was going on there. I'm just curious if anyone has any theories about what might be eating up memory over time. We are using Hibernate and PHP and of course java. Does the heap dump page work for you in a normal situation, i.e. before you start running out of memory? That's really the first place to start looking. The leaking memory might be obvious from Resin's heap dump page. If it's not enough information, the next step would be to use a more sophisticated memory profiler. -- Scott Andrew ___ 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] Memory and slowdown...
So after doing some more research, and comparing the profiles of one server (just restarted) to the other server in the loaded state I've got a lead so to speak, but I'm not sure what it means... On the loaded server about 34% of the time is spent in "readNative" compared to 80%+ on the unloaded server. On the loaded server java.lang.Class.getInterfaces() is using up 27% of the run time. The stack trace is: at java.lang.Class.getInterfaces() at org.hibernate.intercept.FieldInterceptionHelper.extractFieldInterceptor() at org.hibernate.intercept.FieldInterceptionHelper.clearDirty() at org.hibernate.event.def.DefaultFlushEntityEventListener.isUpdateNecessary() at org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity() at org.hibernate.event.def.AbstractFlushingEventListener.flushEntities() at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions() at org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush() at org.hibernate.impl.SessionImpl.autoFlushIfRequired() at org.hibernate.impl.SessionImpl.list() at org.hibernate.impl.QueryImpl.list() at org.mwm.musicmeta.db.MusicMetaDataHibernateReader.readShallowSongsForAlbum() at sun.reflect.GeneratedMethodAccessor704.invoke() at sun.reflect.DelegatingMethodAccessorImpl.invoke() at java.lang.reflect.Method.invoke() at com.caucho.quercus.env.JavaMethod.invoke() Which appears to be Hibernate related. Our "ShallowSongBO" is also the third item on the heap dump, right behind String and char[] (which is pretty insane). I can't conceive of why these might be hanging around, but the ShallowSongBO is loaded regularly from php. Anyone have any thoughts about what in this combination might be causing as persistant object to hang around beyond the requests life time if I'm closing out the hibernate session correctly? Andrew Sandeep Ghael wrote: Hi Scott, I work with Andrew and we are still fighting this problem. Thanks for the advice.. we are analyzing the heap dump as you suggest. For added color to the problem, linked is an image of one of our servers load (courtesy of Munin). The other server behaves similarly, but the two do not manifest the problem in concert (this is a cluster environ with 2 servers). You can see that the mem usage climbs to the point where the server begins to encounter high load. The server load will drop dramatically along with mem usage when either the server is restarted (manually or automatically). http://sandeepghael.com/ServerMemoryPattern.jpg I was reading this Caucho resin page on perf tuning of the jvm and have a few questions: http://www.caucho.com/resin-3.0/performance/jvm-tuning.xtp 1) why is it best practice to set "-Xms and maximum -Xmx heap sizes to the same value". Currently we are setting -Xmx at 1500m with -Xms undefined. 2) I actually experimented with lowering the max heap size to -1024M, and the problem seems to occur faster. We thought that lowering the JVM heap size might prevent OS swap if that was the problem. 3) if -Xss is 4m, and we have 256 max threads, that mean we should account for the OS to commit 4m*256=1G for stack space. Correct? 4) if our machine has 3.3G ram, what is best practice in terms of mem allocation for the JVM vs the rest of the OS? Our conf file below. regards, Sandeep (clustered environment) !-- - The JVM arguments -- jvm-arg-Xmx1500m/jvm-arg jvm-arg-Xss4m/jvm-arg jvm-arg-Xdebug/jvm-arg jvm-arg-Dcom.sun.management.jmxremote/jvm-arg !-- - Uncomment to enable admin heap dumps - jvm-arg-agentlib:resin/jvm-arg -- watchdog-arg-Dcom.sun.management.jmxremote/watchdog-arg !-- - Configures the minimum free memory allowed before Resin - will force a restart. -- memory-free-min24M/memory-free-min !-- Maximum number of threads. -- thread-max256/thread-max !-- Configures the socket timeout -- socket-timeout65s/socket-timeout !-- Configures the keepalive -- keepalive-max128/keepalive-max keepalive-timeout15s/keepalive-timeout On Thu, Apr 3, 2008 at 11:27 AM, Scott Ferguson [EMAIL PROTECTED] wrote: On Apr 2, 2008, at 8:21 AM, Andrew Fritz wrote: Our production servers have their maximum memory set to 2048m. Everything is fine for a while. Eventually the java process ends up with all 2048m allocated. At this point server load starts going up and response time gets bad. Eventually request start timing out. Restarting the server fixes the problem instantly and everything is good again. Occasionally one of the servers will do this on its own, presumably because it reaches the 1m free threshold. That appears to be to small a margin and a restart is needed well before there is only 1m left so I adjusted the minimum free memory from 1m to 24m. That seems like a bandage
Re: [Resin-interest] Memory and slowdown...
On Apr 7, 2008, at 9:18 AM, Sandeep Ghael wrote: Hi Scott, I work with Andrew and we are still fighting this problem. Thanks for the advice.. we are analyzing the heap dump as you suggest. For added color to the problem, linked is an image of one of our servers load (courtesy of Munin). The other server behaves similarly, but the two do not manifest the problem in concert (this is a cluster environ with 2 servers). You can see that the mem usage climbs to the point where the server begins to encounter high load. The server load will drop dramatically along with mem usage when either the server is restarted (manually or automatically). http://sandeepghael.com/ServerMemoryPattern.jpg I was reading this Caucho resin page on perf tuning of the jvm and have a few questions: http://www.caucho.com/resin-3.0/performance/jvm-tuning.xtp 1) why is it best practice to set -Xms and maximum -Xmx heap sizes to the same value. Currently we are setting -Xmx at 1500m with - Xms undefined. I'm not sure this one is a big deal. The GC adaptively increases the minimum value as your application starts. So setting -Xms may improve startup time slightly, but shouldn't affect steady-stage performance. 2) I actually experimented with lowering the max heap size to -1024M, and the problem seems to occur faster. We thought that lowering the JVM heap size might prevent OS swap if that was the problem. That's very possible. You really don't want to be swapping during a GC. 3) if -Xss is 4m, and we have 256 max threads, that mean we should account for the OS to commit 4m*256=1G for stack space. Correct? Right, but 4m should be overkill unless you have a deeply recursive program. 4) if our machine has 3.3G ram, what is best practice in terms of mem allocation for the JVM vs the rest of the OS? I'm not sure, actually. Others might have better suggestions. -- Scott Our conf file below. regards, Sandeep (clustered environment) !-- - The JVM arguments -- jvm-arg-Xmx1500m/jvm-arg jvm-arg-Xss4m/jvm-arg jvm-arg-Xdebug/jvm-arg jvm-arg-Dcom.sun.management.jmxremote/jvm-arg !-- - Uncomment to enable admin heap dumps - jvm-arg-agentlib:resin/jvm-arg -- watchdog-arg-Dcom.sun.management.jmxremote/watchdog- arg !-- - Configures the minimum free memory allowed before Resin - will force a restart. -- memory-free-min24M/memory-free-min !-- Maximum number of threads. -- thread-max256/thread-max !-- Configures the socket timeout -- socket-timeout65s/socket-timeout !-- Configures the keepalive -- keepalive-max128/keepalive-max keepalive-timeout15s/keepalive-timeout On Thu, Apr 3, 2008 at 11:27 AM, Scott Ferguson [EMAIL PROTECTED] wrote: On Apr 2, 2008, at 8:21 AM, Andrew Fritz wrote: Our production servers have their maximum memory set to 2048m. Everything is fine for a while. Eventually the java process ends up with all 2048m allocated. At this point server load starts going up and response time gets bad. Eventually request start timing out. Restarting the server fixes the problem instantly and everything is good again. Occasionally one of the servers will do this on its own, presumably because it reaches the 1m free threshold. That appears to be to small a margin and a restart is needed well before there is only 1m left so I adjusted the minimum free memory from 1m to 24m. That seems like a bandage though. The heap dump returned a blank page so I'm not sure what was going on there. I'm just curious if anyone has any theories about what might be eating up memory over time. We are using Hibernate and PHP and of course java. Does the heap dump page work for you in a normal situation, i.e. before you start running out of memory? That's really the first place to start looking. The leaking memory might be obvious from Resin's heap dump page. If it's not enough information, the next step would be to use a more sophisticated memory profiler. -- Scott Andrew ___ 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
Re: [Resin-interest] resin-pro-3.1.s080331 / Openx / java.lang.ArrayIndexOutOfBoundsException: 12
Scott Ferguson wrote: On Apr 6, 2008, at 2:23 PM, Stargazer wrote: On first installation of openx, either the production version 2.4.4 or beta 2.5.66, a java.lang.ArrayIndexOutOfBoundsException: 12 is thrown immediately. It seems at one point Openads worked as there is a mention of it here: http://wiki.caucho.com/Quercus:_Openads, but making the change mentioned there didn't fix the startup problem. Do you have the full stack trace? Tracking down issues related to 3rd party software is more difficult than just fixing a Quercus bug since we need to install, reproduce, etc. So for something like an ArrayIndexOutOfBoundException, which should point to the Quercus bug directly, it's far more efficient to file the bug with the stack trace. -- Scott Sure, here you go, from the browser as described: 500 Servlet Exception [show] java.lang.ArrayIndexOutOfBoundsException: 12 java.lang.ArrayIndexOutOfBoundsException: 12 at com.caucho.quercus.env.Env.setErrorHandler(Env.java:4270) at com.caucho.quercus.lib.ErrorModule.set_error_handler(ErrorModule.java:474) at _quercus._lib._max._errorhandler__php$quercus_MAX_ErrorHandler$fun_startHandler.callMethod(www/openx/www.example.com/lib/max/ErrorHandler.php:85) at com.caucho.quercus.env.ObjectExtValue.callMethod(ObjectExtValue.java:623) at com.caucho.quercus.env.Var.callMethod(Var.java:1290) at _quercus._init__php$fun_init.call(www/openx/www.example.com/init.php:119) at _quercus._init__php.execute(www/openx/www.example.com/init.php:126) at com.caucho.quercus.env.Env.include(Env.java:3657) at com.caucho.quercus.env.Env.includeOnce(Env.java:3608) at _quercus._www._admin._install__php.execute(www/openx/www.example.com/www/admin/install.php:50) at com.caucho.quercus.page.QuercusPage.executeTop(QuercusPage.java:119) at com.caucho.quercus.servlet.ResinQuercusServlet.service(ResinQuercusServlet.java:146) at com.caucho.quercus.servlet.QuercusServlet.service(QuercusServlet.java:353) at javax.servlet.http.HttpServlet.service(HttpServlet.java:91) at com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:103) at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:187) at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:266) at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:270) at com.caucho.server.port.TcpConnection.run(TcpConnection.java:675) at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:721) at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:643) at java.lang.Thread.run(Thread.java:619) ___ 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-pro-3.1.s080331 / Openx / java.lang.ArrayIndexOutOfBoundsException: 12
Stargazer wrote: Scott Ferguson wrote: On Apr 6, 2008, at 2:23 PM, Stargazer wrote: beta 2.5.66, a java.lang.ArrayIndexOutOfBoundsException: 12 is thrown I have more information - I just ran up a Drupal 6.1 installation and saw the same exception, java.lang.ArrayIndexOutOfBoundsException: 12. So on a hunch I went back to resin-pro-3.1.s080320 and both it and the openx install are fine! ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] NullPointerException on invoking EntityManager.persist()
Okay, I have successfully traced the source of this problem. Firstly, I'm using the current MySQL Connector/J 5.1.5 binary. I was using the recommended MySQL driver (as per all the Resin tutorials) which is: com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource However, if I change this to: com.mysql.jdbc.Driver then the problem I faced resolves itself. So one might think it's a problem with that driver (which it might be - I haven't checked older versions of Connector/J). As a temporary fix I'm leaving this as my driver - unless you have a good reason not to? However, I've gone further and delved into the source for the latest snapshot (31st March). Using the MysqlConnectionPoolDataSource driver, I've traced the problem to the following method: com.caucho.sql.ManagedConnectionImpl.prepareStatement(UserConnection,String,int) and the pair of lines: if(resultType 0) return conn.prepareStatement(sql,resultType); This is returning null since the resultType passed in to the prepareStatement method is 1. If I force resultType=0 in this method, everything works as expected. I guess this is something to do with caching statements (and for a new object being persisted those haven't already been cached?), but I'll leave such inferences up to the experts ;) So in summary, I'm not sure if this is a bug in Resin or Connector/J 5.1.5, but the recommended MySQL pooled driver certainly doesn't work as expected. Cheers, Charles. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Memory and slowdown...
On Apr 7, 2008, at 9:18 AM, Sandeep Ghael wrote: jvm-arg-Xdebug/jvm-arg In my experience the debug switch sometimes causes the JVM to behave erratically under heavy load. I would get rid of it and try again. -Knut ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
