Re: SQL database and JDBC
At 11:49 AM +1100 11/9/02, Jesus M. Salvo Jr. wrote: My favourite: SAP-DB: http://www.sapdb.org/ http://www.sapdb.org/sap_db_jdbc.htm I am still surprised that not too many people have not taken up SAP-DB, despite being GPL and LPGL, and having some features that other proprietary databases have ( like Oracle's online redo logs ) I looked at sapdb a few months ago. It looks to me like 'dump-ware'. A company decides to try to get more interest in its main product (the rest of SAP, not sapdb) by open-sourcing something that might be useful to people. Sadly, the process involved in getting the system compiled (you must bootstrap their own development environment before you can build), installed and configured is a nightmare. I can't say that I really spent much time working with it (I decided it might be fun to get it ported to OSX) but in the several days I spent with it, I got almost nowhere. Maybe the project has become such a mess that they're hoping that someone or some group out there might come in and clean it up for them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SQL database and JDBC
Don't know about having to compile it, but binary installation is much easier: http://www.sapdb.org/htmhelp/41/03393cddb05357e1000a114084/content.htm unpack the tar.gz file run the installation program then add something to your PATH after which you create the database. Then you have JDBC, Perl, and Python interfaces to sapdb. Granted, though, that I am also not interested in their other products. On Sat, 9 Nov 2002 22:42, Avi Cherry wrote: > At 11:49 AM +1100 11/9/02, Jesus M. Salvo Jr. wrote: > >My favourite: SAP-DB: > > > >http://www.sapdb.org/ > >http://www.sapdb.org/sap_db_jdbc.htm > > > >I am still surprised that not too many people have not taken up SAP-DB, > >despite being GPL and LPGL, and having some features that other > > proprietary databases have ( like Oracle's online redo logs ) > > I looked at sapdb a few months ago. It looks to me like 'dump-ware'. > A company decides to try to get more interest in its main product > (the rest of SAP, not sapdb) by open-sourcing something that might be > useful to people. Sadly, the process involved in getting the system > compiled (you must bootstrap their own development environment before > you can build), installed and configured is a nightmare. I can't say > that I really spent much time working with it (I decided it might be > fun to get it ported to OSX) but in the several days I spent with it, > I got almost nowhere. Maybe the project has become such a mess that > they're hoping that someone or some group out there might come in and > clean it up for them. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
SAP DB -- not GPL!
This is GPL? The following is taken from: http://www.sapdb.org/sap_db_software.htm " SAP DB can be used free of charge in non-SAP environments. There are various Support Models offered for SAP DB. If you use SAPÂ DB as a database system for SAP solutions, a maintenance contract is required. For more information on a maintenance contract please contact your national SAP subsidiary. " That's NOT GPL. This is GPL: http://www.gnu.org/copyleft/gpl.html Dave -- [EMAIL PROTECTED] 813-236-2009 "We earn our living, not turn our living." -- Dave "Microsoft: they put the 'P' on 'OS'. -- Dave "Never confuse talking shit with knowing shit." -- Dave Context. The hard part of configuring "anything" isn't the language used to configure. It is knowing what you're trying to do, why your trying to do it, and how such things are done. The hard part of "configuring" is beholding the CONTEXT of what you're trying to configure. Once you've learned the context, the details make sense. Until you learn the context, you'll bumble at best, and never configure at worse. And your life will be hell while bumbling. Never short-change context. It's the only way to be authoritative over whatever it is you're trying to do. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: intermittent extremely slow GC
The only two memory leaks I know of in the JVM are in Swing. The indeterminate progress bar leaks memory like crazy by creating a zillion Insets and JDialogs can cause memory leaks because the "dispose" method isn't working and so it won't allow them to be garbage collected. Both of these are in the bug list somewhere. Dave A King wrote: i definitely think swap is my issue. I'm kicking myself for not noticing it... What's odd is the only thing that has changed on these servers in many weeks is the java code for our application. We have a fixed heap size if 512MB. Where is all this extra memory coming from? 1GB real memory and 700+MB swap in use. Does the jvm itself leak memory, even with a fixed heap size? -d- -Original Message- From: Matt Avery [mailto:mavery@;einnovation.com] Sent: Friday, November 08, 2002 9:51 AM To: Dave A King Cc: '[EMAIL PROTECTED]' Subject: Re: intermittent extremely slow GC If any memory has paged to swap, garbage collection through the swap will be excruciatingly slow. Is another app consuming memory, forcing the server to use the swap partition heavily? Dave A King wrote: I'm trying to troubleshoot some really bizarre behavior in a recent build of our application. We have changed our memory usage quite a bit, utilizing more caching, etc. Overall performance has unsurprisingly improved and all looked good during QA after we tackled some memory leaks and unbounded caches. In general, we spend 1% or less time in GC. Minor collections happen often but quickly, usually under 100ms. Major collections happen every couple hours, generally taking ~3 seconds. After each major collection, the heap in use is reduced approximately the same each time, so apparently we are leak-free. Everything was looking good... After running this for over a week in production under moderate load (significantly less than we ran in QA scenarios), I started noticing some wild behavior. About 100 hours in to the application's lifetime, major collections started taking much longer then it had in the days prior. 45+ seconds becomes the norm. And on top of that, some minor collections take several seconds, and in some cases as long as 45 seconds. The boggling part is that the application itself isn't doing anything differently 100 hours in than it had in the first few hours of its life. Each app server handles several hundred client connections, that have an average session length of a few hours. Each client has the same type of functions. Why on earth would GC time change so dramatically after the app has been up for a few days? Why would it take so much longer to clear the heap of the same amount and type of data that it had done in a tenth of the time before? Any input would be appreciated... Here is some example output from verbose GC... Normal behavior: 13122: [GC 441755K->382806K(516800K), 0.0547972 secs] 13135: [GC 442710K->383552K(516800K), 0.0621738 secs] 13152: [GC 443456K->384087K(516800K), 0.0714369 secs] 13166: [GC 443991K->385705K(516800K), 0.0968161 secs] 13181: [GC 445609K->385720K(516800K), 0.1021833 secs] 13195: [GC 445622K->385748K(516800K), 0.0390663 secs] 13208: [GC 445648K->387175K(516800K), 0.0490246 secs] 13230: [GC 447075K->388661K(516800K), 0.0740566 secs] 13243: [GC 448787K->389577K(516800K), 0.0829134 secs] 13258: [Full GC 449481K->144520K(516800K), 3.1433411 secs] 13272: [GC 204424K->146891K(516800K), 0.0390291 secs] 13288: [GC 206795K->147522K(516800K), 0.0864487 secs] 13307: [GC 207762K->147822K(516800K), 0.0402269 secs] 13324: [GC 207725K->148218K(516800K), 0.0444241 secs] Abnormal behavior: 617481: [GC 429003K->369069K(516800K), 0.0502329 secs] 617485: [GC 428973K->371054K(516800K), 0.0752230 secs] 617491: [GC 430956K->371764K(516800K), 0.4616861 secs] 617495: [GC 431667K->372278K(516800K), 0.2441826 secs] 617498: [GC 432182K->374942K(516800K), 0.8099241 secs] 617501: [GC 434846K->378277K(516800K), 0.3345280 secs] 617504: [GC 438181K->380583K(516800K), 0.7288399 secs] 617509: [GC 440486K->389948K(516800K), 1.2321482 secs] 617516: [Full GC 449849K->125578K(516800K), 111.9440899 secs] ** 617631: [GC 185482K->134830K(516800K), 0.2384958 secs] 617635: [GC 194734K->138885K(516800K), 17.7584829 secs] ** 617664: [GC 198789K->140709K(516800K), 1.1765528 secs] 617667: [GC 200613K->142999K(516800K), 1.1135330 secs] 617670: [GC 202903K->143896K(516800K), 0.1886063 secs] 617674: [GC 204399K->145748K(516800K), 0.0643682 secs] 617679: [GC 205651K->146747K(516800K), 0.2402821 secs] and 619471: [GC 305211K->244553K(516800K), 0.0485077 secs] 619479: [GC 304566K->245821K(516800K), 0.0509443 secs] 619490: [GC 305722K->246337K(516800K), 42.9122648 secs] 619550: [GC 306238K->251121K(516800K), 0.6206665 secs] 619556: [GC 311023K->252685K(516800K), 1.2239046 secs] History of Full GC's over life of application: 9.53674e-07: [Full GC 17737K->2084K(516800K), 0.1908865 sec
Re: intermittent extremely slow GC
mine was in the GZIP ( i think output ) streams. reading was OK, but an output stream left a leakage, that eventually ate up all my 256meg memory. This was fixed in 1.4, but may still be around in 1.3. Matt Avery wrote: The only two memory leaks I know of in the JVM are in Swing. The indeterminate progress bar leaks memory like crazy by creating a zillion Insets and JDialogs can cause -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: intermittent extremely slow GC
I had a problem in 1.3.1 JDK. There was a leak while reading a 0 length zip file, the native memory grew larger and blows up the machine after a time. There was a fix in 1.4 but it still in 1.3.1 too. Reg Ved -Original Message- From: Uncle George [mailto:gatgul@;voicenet.com] Sent: Saturday, November 09, 2002 5:16 PM To: '[EMAIL PROTECTED]' Subject: Re: intermittent extremely slow GC mine was in the GZIP ( i think output ) streams. reading was OK, but an output stream left a leakage, that eventually ate up all my 256meg memory. This was fixed in 1.4, but may still be around in 1.3. Matt Avery wrote: > The only two memory leaks I know of in the JVM are in Swing. The > indeterminate progress bar leaks memory like crazy by creating a > zillion Insets and JDialogs can cause -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] This e-mail has been captured and archived by the ZANTAZ Digital Safe(tm) service. For more information, visit us at www.zantaz.com. IMPORTANT: This electronic mail message is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone or directly reply to the original message(s) sent. Thank you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
