Re: [DBCP] a question regarding maxActive
Chen Bangzhong wrote: Hi, experts I have one java web application. In the application, several datasource was configured for dbcp. For each datasource, maxActive was set to 100 and max Idle set to 30. Then I used several crawlers to make the web application very busy, until the application reported that it can't get an idle connection to the database server. But strangely enough, I found the connections to database servers was only about 100 using the nestat -an command. so my question is : is the maxActive shared by the whole applications ? In my opinion, the max connection should be the number of datasource times maxActive. For example, 4 datasources, the connections should be 400, not 100. How about different jvm on the same machine? thanks (sorry for sending out this email two times. I revised the title in my second email) I assume you are using BasicDatasource and JNDI in your application server to retrieve the datasource. Is this correct? What version of DBCP and what application server? Can you post the config? Pls also provide the dbcp config. DBCP itself does not share pools across BasicDatasource instances. Phil ___ ???,! http://card.mail.cn.yahoo.com/ - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: log4j NTEventLogAppender.dll for windows 64 bit
On Tue, Sep 1, 2009 at 10:27 PM, Trin Chavalittumrongtri...@microsoft.com wrote: Hi All, The NTEVentLogAPpender.dll that comes with log4j seems to be working with Windows 32-bit only. Has anyone had any solutions for this problem in Windows 64-bit? Wrong list, try http://logging.apache.org/mail-lists.html Niall Thanks, Trin - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [Digester] (solved) re-parsing digest file after modifications yields results prior to modification
i managed to solve this issue. turns out it was user error (on my part). as typical, i spent a bunch of time digging through the digester code to see if there was some problem with the URL being cached---in fact, digester takes this into account and appears to handle it by turning caching off and, after parsing, cleaning up resources. in the end, the problem was with the digest file i was modifying. i have a 'source' version and a 'distribution' version. the latter is copied from the 'source' version on startup and is the file that the digester reads (and re-reads). out of habit, i was modifying the 'source' version. when i realized this mistake, and switched to editing the 'distribution' version, the application worked as expected. On Mon, Aug 24, 2009 at 3:10 PM, NJuk Njuk njuk.n...@gmail.com wrote: i have an application that needs the ability to re-parse the same digest file multiple times. each time the digest file will have been modified, so the resultant object should reflect these modifications. the digest rules are defined via xmlrules. these rules themselves do not change; the modification is only to the digest file. assume below digestRulesURL and digestURL are valid URLs (that never change) pointing to the appropriate files. each time i setup a new digester instance and call parse() via the following... Digester aDigester = DigesterLoader.createDigester(digestRulesURL); aDigester.setNamespaceAware(true); aDigester.setXIncludeAware(true); SomeObject o = (SomeObject) aDigester.parse(digestURL); ...the results of parse() always reflect the first time it was called. that is to say, no matter how many times i change the digest file, create a new digester, and call parse (as above), the resulting object (though seemingly a new instance) has the same state as the original call to parse(). i know from the Digester FAQ, that one should not reuse a digester object, which is why i am recreating each time. there appears to be some sort of caching or state that is maintained. i peeked around the xmlrules DigesterLoader code and related, but not enough to see anything that would tip me off. any help would be appreciated.
Re: [CONFIGURATION] Configuration Interpolates when Web Application is run directly under Glassfish, but not when debugging under Eclipse
Hi Andrew,
what you describe seems really complicated. I am not sure whether I
fully understand the problem, but I hope at least to give you some
hints. Comments inline...
Andrew Thorburn schrieb:
This is something that doesn't make an awful lot of sense to me:
I've got a web application that uses CommonsConfiguration to configure
the logging (first it loads a configuration file as base, then loads
a new configuration from the database), and for some reason it will
not interpolate the various parameters when I try and debug it under
Eclipse (using the Glassfish WTP plugin). It just doesn't happen.
I'm using Java 1.5, Commons Configuration 1.6, Commons Lang 2.2,
Eclipse 3.5 and Glassfish 2.1.
I know that it works when I run it under Glassfish directly as I can
see the log file being created in the right directory and such, and I
can also see it printing out the parameters with everything
successfully interpolated and expanded.
I'm not sure exactly why it's not doing anything, but there we go.
It doesn't even interpolate System parameters, including ones that
I've set my self.
I can't provide the code which is actually causing the problem, and
I'm not entirely sure how to replicate it. The best I can do is show
code which behaves in a similar fashion:
/**
* @param args
*/
public static void main(String[] args)
{
System.setProperty(ProcessID, pid);
System.out.println(java.io.tmpdir [ +
System.getProperty(java.io.tmpdir) + ]);
Configuration c = new BaseConfiguration();
c.setProperty(process.default.logfile_directory,
${java.io.tmpdir});
c.setProperty(logger.default.filename_prefix, PREFIX);
c.setProperty(logger.default.filename_suffix, log);
c.setProperty(logger.default.filename,
${logger.default.filename_prefix}${ProcessID}.${logger.default.filename_suffix});
c.setProperty(logger.log4j.rootLogger, ERROR, APP_ROD,
APP_EMAIL);
c.setProperty(logger.log4j.appender.APP_ROD,
org.apache.log4j.DailyRollingFileAppender);
c.setProperty(logger.log4j.appender.APP_ROD.File,
${process.default.logfile_directory}/${ProcessID}/${logger.default.filename});
c.setProperty(logger.log4j.appender.APP_ROD.DatePattern,
'.'MMdd);
CompositeConfiguration cc = new CompositeConfiguration();
cc.addConfiguration((AbstractConfiguration)c.subset(logger));
System.out.println(cc.getString(log4j.appender.APP_ROD.File));
printProperties(ConfigurationConverter.getProperties(cc));
printProperties(ConfigurationConverter.getProperties(c));
}
private static void printProperties(Properties props)
{
for(EntryObject, Object ent : props.entrySet())
{
System.out.println([ + ent.getKey() + ] [ + ent.getValue() +
]);
}
}
And the output from the above:
java.io.tmpdir [/tmp]
${process.default.logfile_directory}/${ProcessID}/${logger.default.filename}
[log4j.rootLogger] [ERROR,APP_ROD,APP_EMAIL]
[log4j.appender.APP_ROD.DatePattern] ['.'MMdd]
[log4j.appender.APP_ROD] [org.apache.log4j.DailyRollingFileAppender]
[log4j.appender.APP_ROD.File]
[${process.default.logfile_directory}/${ProcessID}/${logger.default.filename}]
[default.filename_prefix] [PREFIX]
[default.filename_suffix] [log]
[default.filename]
[${logger.default.filename_prefix}${ProcessID}.${logger.default.filename_suffix}]
[process.default.logfile_directory] [${java.io.tmpdir}]
[logger.default.filename_prefix] [PREFIX]
[logger.default.filename_suffix] [log]
[logger.log4j.appender.APP_ROD.File]
[${java.io.tmpdir}/${ProcessID}/PREFIX${ProcessID}.log]
[logger.default.filename] [PREFIX${ProcessID}.log]
[logger.log4j.appender.APP_ROD.DatePattern] ['.'MMdd]
[logger.log4j.appender.APP_ROD] [org.apache.log4j.DailyRollingFileAppender]
[logger.log4j.rootLogger] [ERROR,APP_ROD,APP_EMAIL]
Which seems a little... odd... since it left
process.default.logfile_directory as ${java.io.tmpdir} despite the
property definitely being set.
If you work with a plain configuration like BaseConfiguration, system
properties are not interpolated out of the box. You need to prefix the
variable with the sys: prefix. There is an example in the user guide:
http://commons.apache.org/configuration/userguide/howto_basicfeatures.html#Variable_Interpolation
However, when using a CombinedConfiguration that includes a
SystemConfiguration the situation is different as the
SystemConfiguration should make all its properties available.
This differs from my actual problem in that *no* interpolation is
performed when converting to a Properties Object. None at all. Also,
the properties
Need easy way to force all DynaBean property names to lower case
I'm developing functionality that can operate on concrete data beans returned via Hibernate, or DynaBeans returned by using Jakarta Commons/BeanUtils' RowSetDynaClass (which wraps a JDBC result set). RowSetDynaClass by default forces all bean property names to lower case, and I need to convert all my concrete beans from Hibernate to DynaBeans using WrapDynaBean. The default lower casing by RowSetDynaClass seems like a good idea, however I may not know ahead of time how the property names of the concrete beans will be cased; due to Hibernate configuration, they need not be cased identically to their corresponding table column names. Is there built in functionality for forcing property names to lower case using BeanUtils? I can't find it documented other than for RowSetDynaClass. In lieu of something built in to BeanUtils, can anybody suggest the best way to acheive this myself? The above is verbatim from http://stackoverflow.com/questions/1369915/need-easy-way-to-force-all-dynabean-property-names-to-lower-case you can answer there too if you want to accrue some reputation. I've investigated this a bit more and it looks like I might be able to use getMap() and then deal with the case of the string keys. Doesn't seem especially elegant though but I've only scratched the surface of the API. Is extending WrapDynaBean class and overriding introspect() a possibility? Finally, might a patch be in order to add this functionality to WrapDynaBean/Class? It seems like it could be more useful/inter-operable if it behaved in a similar way to RowSetDynaClass, with an option (not the default though) for forcing property names to lower case. Thanks in advance -- Knowledge is of two kinds. We know a subject ourselves, or we know where we can find information upon it. -- Samuel Johnson
Re: [CONFIGURATION] Configuration Interpolates when Web Application is run directly under Glassfish, but not when debugging under Eclipse
Thanks Oliver.
I have no idea why, but it's suddenly started working. I messed about
with a few things, including dumping the combined configuration (but
nothing was interpolated), and removing breakpoints which I had set on
several different copies of my Configurator class.
Absolutely bizarre. All I can do now is hope that it doesn't recur...
Thanks,
- Andrew Thorburn
On Thu, Sep 3, 2009 at 5:05 AM, Oliver
Hegeroliver.he...@oliver-heger.de wrote:
Hi Andrew,
what you describe seems really complicated. I am not sure whether I fully
understand the problem, but I hope at least to give you some hints. Comments
inline...
Andrew Thorburn schrieb:
This is something that doesn't make an awful lot of sense to me:
I've got a web application that uses CommonsConfiguration to configure
the logging (first it loads a configuration file as base, then loads
a new configuration from the database), and for some reason it will
not interpolate the various parameters when I try and debug it under
Eclipse (using the Glassfish WTP plugin). It just doesn't happen.
I'm using Java 1.5, Commons Configuration 1.6, Commons Lang 2.2,
Eclipse 3.5 and Glassfish 2.1.
I know that it works when I run it under Glassfish directly as I can
see the log file being created in the right directory and such, and I
can also see it printing out the parameters with everything
successfully interpolated and expanded.
I'm not sure exactly why it's not doing anything, but there we go.
It doesn't even interpolate System parameters, including ones that
I've set my self.
I can't provide the code which is actually causing the problem, and
I'm not entirely sure how to replicate it. The best I can do is show
code which behaves in a similar fashion:
/**
* @param args
*/
public static void main(String[] args)
{
System.setProperty(ProcessID, pid);
System.out.println(java.io.tmpdir [ +
System.getProperty(java.io.tmpdir) + ]);
Configuration c = new BaseConfiguration();
c.setProperty(process.default.logfile_directory,
${java.io.tmpdir});
c.setProperty(logger.default.filename_prefix, PREFIX);
c.setProperty(logger.default.filename_suffix, log);
c.setProperty(logger.default.filename,
${logger.default.filename_prefix}${ProcessID}.${logger.default.filename_suffix});
c.setProperty(logger.log4j.rootLogger, ERROR, APP_ROD,
APP_EMAIL);
c.setProperty(logger.log4j.appender.APP_ROD,
org.apache.log4j.DailyRollingFileAppender);
c.setProperty(logger.log4j.appender.APP_ROD.File,
${process.default.logfile_directory}/${ProcessID}/${logger.default.filename});
c.setProperty(logger.log4j.appender.APP_ROD.DatePattern,
'.'MMdd);
CompositeConfiguration cc = new CompositeConfiguration();
cc.addConfiguration((AbstractConfiguration)c.subset(logger));
System.out.println(cc.getString(log4j.appender.APP_ROD.File));
printProperties(ConfigurationConverter.getProperties(cc));
printProperties(ConfigurationConverter.getProperties(c));
}
private static void printProperties(Properties props)
{
for(EntryObject, Object ent : props.entrySet())
{
System.out.println([ + ent.getKey() + ] [ +
ent.getValue() + ]);
}
}
And the output from the above:
java.io.tmpdir [/tmp]
${process.default.logfile_directory}/${ProcessID}/${logger.default.filename}
[log4j.rootLogger] [ERROR,APP_ROD,APP_EMAIL]
[log4j.appender.APP_ROD.DatePattern] ['.'MMdd]
[log4j.appender.APP_ROD] [org.apache.log4j.DailyRollingFileAppender]
[log4j.appender.APP_ROD.File]
[${process.default.logfile_directory}/${ProcessID}/${logger.default.filename}]
[default.filename_prefix] [PREFIX]
[default.filename_suffix] [log]
[default.filename]
[${logger.default.filename_prefix}${ProcessID}.${logger.default.filename_suffix}]
[process.default.logfile_directory] [${java.io.tmpdir}]
[logger.default.filename_prefix] [PREFIX]
[logger.default.filename_suffix] [log]
[logger.log4j.appender.APP_ROD.File]
[${java.io.tmpdir}/${ProcessID}/PREFIX${ProcessID}.log]
[logger.default.filename] [PREFIX${ProcessID}.log]
[logger.log4j.appender.APP_ROD.DatePattern] ['.'MMdd]
[logger.log4j.appender.APP_ROD]
[org.apache.log4j.DailyRollingFileAppender]
[logger.log4j.rootLogger] [ERROR,APP_ROD,APP_EMAIL]
Which seems a little... odd... since it left
process.default.logfile_directory as ${java.io.tmpdir} despite the
property definitely being set.
If you work with a plain configuration like BaseConfiguration, system
properties are not interpolated out of the box. You need to prefix the
variable with the sys: prefix. There is an example in the user guide:
Re: [CONFIGURATION] Configuration Interpolates when Web Application is run directly under Glassfish, but not when debugging under Eclipse
Yeah, you know what? I was wrong. I had just loaded up a second copy
of my application into Glassfish without realising it. Go me?
- Andrew
On Thu, Sep 3, 2009 at 1:18 PM, Andrew Thorburnnzi...@gmail.com wrote:
Thanks Oliver.
I have no idea why, but it's suddenly started working. I messed about
with a few things, including dumping the combined configuration (but
nothing was interpolated), and removing breakpoints which I had set on
several different copies of my Configurator class.
Absolutely bizarre. All I can do now is hope that it doesn't recur...
Thanks,
- Andrew Thorburn
On Thu, Sep 3, 2009 at 5:05 AM, Oliver
Hegeroliver.he...@oliver-heger.de wrote:
Hi Andrew,
what you describe seems really complicated. I am not sure whether I fully
understand the problem, but I hope at least to give you some hints. Comments
inline...
Andrew Thorburn schrieb:
This is something that doesn't make an awful lot of sense to me:
I've got a web application that uses CommonsConfiguration to configure
the logging (first it loads a configuration file as base, then loads
a new configuration from the database), and for some reason it will
not interpolate the various parameters when I try and debug it under
Eclipse (using the Glassfish WTP plugin). It just doesn't happen.
I'm using Java 1.5, Commons Configuration 1.6, Commons Lang 2.2,
Eclipse 3.5 and Glassfish 2.1.
I know that it works when I run it under Glassfish directly as I can
see the log file being created in the right directory and such, and I
can also see it printing out the parameters with everything
successfully interpolated and expanded.
I'm not sure exactly why it's not doing anything, but there we go.
It doesn't even interpolate System parameters, including ones that
I've set my self.
I can't provide the code which is actually causing the problem, and
I'm not entirely sure how to replicate it. The best I can do is show
code which behaves in a similar fashion:
/**
* @param args
*/
public static void main(String[] args)
{
System.setProperty(ProcessID, pid);
System.out.println(java.io.tmpdir [ +
System.getProperty(java.io.tmpdir) + ]);
Configuration c = new BaseConfiguration();
c.setProperty(process.default.logfile_directory,
${java.io.tmpdir});
c.setProperty(logger.default.filename_prefix, PREFIX);
c.setProperty(logger.default.filename_suffix, log);
c.setProperty(logger.default.filename,
${logger.default.filename_prefix}${ProcessID}.${logger.default.filename_suffix});
c.setProperty(logger.log4j.rootLogger, ERROR, APP_ROD,
APP_EMAIL);
c.setProperty(logger.log4j.appender.APP_ROD,
org.apache.log4j.DailyRollingFileAppender);
c.setProperty(logger.log4j.appender.APP_ROD.File,
${process.default.logfile_directory}/${ProcessID}/${logger.default.filename});
c.setProperty(logger.log4j.appender.APP_ROD.DatePattern,
'.'MMdd);
CompositeConfiguration cc = new CompositeConfiguration();
cc.addConfiguration((AbstractConfiguration)c.subset(logger));
System.out.println(cc.getString(log4j.appender.APP_ROD.File));
printProperties(ConfigurationConverter.getProperties(cc));
printProperties(ConfigurationConverter.getProperties(c));
}
private static void printProperties(Properties props)
{
for(EntryObject, Object ent : props.entrySet())
{
System.out.println([ + ent.getKey() + ] [ +
ent.getValue() + ]);
}
}
And the output from the above:
java.io.tmpdir [/tmp]
${process.default.logfile_directory}/${ProcessID}/${logger.default.filename}
[log4j.rootLogger] [ERROR,APP_ROD,APP_EMAIL]
[log4j.appender.APP_ROD.DatePattern] ['.'MMdd]
[log4j.appender.APP_ROD] [org.apache.log4j.DailyRollingFileAppender]
[log4j.appender.APP_ROD.File]
[${process.default.logfile_directory}/${ProcessID}/${logger.default.filename}]
[default.filename_prefix] [PREFIX]
[default.filename_suffix] [log]
[default.filename]
[${logger.default.filename_prefix}${ProcessID}.${logger.default.filename_suffix}]
[process.default.logfile_directory] [${java.io.tmpdir}]
[logger.default.filename_prefix] [PREFIX]
[logger.default.filename_suffix] [log]
[logger.log4j.appender.APP_ROD.File]
[${java.io.tmpdir}/${ProcessID}/PREFIX${ProcessID}.log]
[logger.default.filename] [PREFIX${ProcessID}.log]
[logger.log4j.appender.APP_ROD.DatePattern] ['.'MMdd]
[logger.log4j.appender.APP_ROD]
[org.apache.log4j.DailyRollingFileAppender]
[logger.log4j.rootLogger] [ERROR,APP_ROD,APP_EMAIL]
Which seems a little... odd... since it left
process.default.logfile_directory as ${java.io.tmpdir} despite the
property definitely being set.
If you work with a plain configuration like
