Re: 2 AsynchAppender and a Deadlock
For the sake of completeness, I am using log4cxx 0.10.0. Cheers Stefan -Original Message- Date: Tue, 02 Dec 2008 15:08:53 +0100 Subject: 2 AsynchAppender and a Deadlock From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> To: log4cxx-user@logging.apache.org Hi, I have tried to use two AsyncAppenders, which have some Appenders in common, in parallel. I ended up in a deadlock. Has this never been tested or is it the intention to use one AsyncAppender at a time only?? This is not an offense, just a question!! I can live with the "only one AsyncAppender at a time" version. Cheers Stefan
2 AsynchAppender and a Deadlock
Hi, I have tried to use two AsyncAppenders, which have some Appenders in common, in parallel. I ended up in a deadlock. Has this never been tested or is it the intention to use one AsyncAppender at a time only?? This is not an offense, just a question!! I can live with the "only one AsyncAppender at a time" version. Cheers Stefan
Non thread private MDC values.
Hi, I would like to raise an issue concerning the MDC (in log4cxx 0.10.0 and log4j 1.2). Is it possible to introduce MDC key-value pairs, say generalised MDC values, which are not thread privat? I like the concept of MDC but have the problem of logging many instances of the same application (with many threads) running on many hosts. The messages logged are send to a remote logging instance. Usually, we cannot distinguish between the instances running on the same host. Here I use the MDC. In this situation, a generalisation of the MDC would give me the possibility to add values which help me to distinguish between the instances (without carrying this information within the log-message). The advantage of this generalised MDC is the existing treatment of the MDC values (XMLSocketAppender, XMLSocketReceiver, DBAppender). Perhaps it is sufficient to add a generalised 'put' and 'get' method to a 'global' hash in the MDC. In the moment, I have to look whether the MDC still has values which consumes unnecessary time (and this is rather uncool). Perhaps you have a better clou to this point. If so, please let me know. Cheers Stefan
LOGCXX-282 patch
Hi, I see issues as described in LOGCXX-282. Will there be a release containing the patch soon?? Afaik, the patch isn't in the trunk, is it? I need log4cxx in productivity on remote mashines, thus it should work deterministic. Cheers Stefan
Re: XMLSocketAppender: Reconnection fails
Hi Dale,
thanks a lot. I haven't expected such a bug in a
release. Better switch to the latest head revision
then ..
Stefan
-Original Message-
Date: Tue, 23 Sep 2008 17:04:52 +0200
Subject: Re: XMLSocketAppender: Reconnection fails
From: "Dale King" <[EMAIL PROTECTED]>
To: "Log4CXX User" ,
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
I reported it back in May:
http://issues.apache.org/jira/browse/LOGCXX-277 [1]
It is a bug in 0.10.0, but is fixed in subversion. The fix is to make
that if( !thread.isActive() )
On Tue, Sep 23, 2008 at 9:56 AM, [EMAIL PROTECTED] [2]
wrote:
Hi All,
for some reason, a XMLSocketAppender does not reconnect to
Chainsaw, after some initial events have been sent and then
chainsaw was killed.
What I have figured out is that in the following code snippet
from SocketAppenderSkeleton.cpp
-- schnipp --
void SocketAppenderSkeleton::fireConnector()
{
synchronized sync(mutex);
if (thread.isActive()) {
thread.run(monitor, this);
}
}
schnapp
the method thread.isActive always returns false. It seems that
the methods returns true if there is some (apr) thread object
instantiated. But that does not happen.
The same behaviour is shown when the connection cannot be
established
at the beginning of a session.
Is that a known bug/feature?? I'am using log4cxx 0.10.0. [4]
Cheers
Stefan
--
Dale King
Links:
--
[1] http://issues.apache.org/jira/browse/LOGCXX-277
[2] mailto:[EMAIL PROTECTED]
[3] mailto:[EMAIL PROTECTED]
[4] http://0.10.0.
XMLSocketAppender: Reconnection fails
Hi All,
for some reason, a XMLSocketAppender does not reconnect to
Chainsaw, after some initial events have been sent and then
chainsaw was killed.
What I have figured out is that in the following code snippet
from SocketAppenderSkeleton.cpp
-- schnipp --
void SocketAppenderSkeleton::fireConnector()
{
synchronized sync(mutex);
if (thread.isActive()) {
thread.run(monitor, this);
}
}
schnapp
the method thread.isActive always returns false. It seems that
the methods returns true if there is some (apr) thread object
instantiated. But that does not happen.
The same behaviour is shown when the connection cannot be established
at the beginning of a session.
Is that a known bug/feature?? I'am using log4cxx 0.10.0.
Cheers
Stefan
AsynchAppender, XMLSocketAppender and fast dying application
Hi All,
I'am currently working with log4cxx 0.10.0 on W-XP using MSVC 2005 Group
Edition.
The problem I have is the following. I use an AnsycAppender which uses
an
XMLSocketAppender to publish events.
When my application is going to terminate in the main method and no
event was send to the server
(chainsaw at the moment), the application hangs while performing
"LogManager::shutdown();" and
does not terminate.
What I figured out so far is, that the XMLLayout is using
"log4cxx::helpers::Transform::appendEscapingCDATA"
which initialises some static variables. This initialisation interferes
with an "atexit" handler. The result
is, that appendEscapingCDATA never returns. Hence, the thread of the
AsyncAppender never returns and the
whole application does not terminate.
A remedy is to perform the initialisation in advance, like this:
{
LogString buf;
LogString input;
log4cxx::helpers::Transform::appendEscapingCDATA(buf, input);
}
This helps, but is not very intentional. Are there nicer solutions
available (a sleep also
works, but one needs different periods in RELEASE/DEBUG mode)?
Cheers
Stefan
Socket and XMLSocketReceiver
Hi All,
I'am using log4cxx 0.10.0 and Chainsaw v2 as a server. On the Chainsaw
side I'am
using a SocketReceiver and a XMLSocketReceiver. Now I have three
beginner questions
concerning this setup.
1) The events logged by the XMLSocketReceiver are all written to the
"chainsaw-log" tab.
This is somehow ugly. Is it possible to set the "Application property"
such that the XML
messages are going to a different tab? I have found only vague
descriptions on setting
this property (even on the name of the key).
2) Question (1) is also a problem for the SocketReceiver, well different
tabs are open for
different remote hosts, but an application name is still missing.
3) While it was possible to send the "locationInfo" with the
XMLSocketAppender, the
same does not work on the SocketAppender/SocketReceiver pair, although
the C++ code
suggest that the location info is serialized. Any clou here?
Any help is welcome!
Cheers
Stefan
P.S.: Here is the Chainsaw config.
http://jakarta.apache.org/log4j/";
debug="true">
And here the C++ config on the client side:
// XML socket stuff +++
XMLSocketAppenderPtr myXMLSocketAppender(
new XMLSocketAppender(
LOG4CXX_STR("XXX.XXX.XXX.XXX"),
4448
)
);
XMLLayoutPtr myXMLLayout( new XMLLayout() );
myXMLLayout->setLocationInfo(true);
myXMLSocketAppender->setLayout(myXMLLayout);
myXMLSocketAppender->activateOptions(pool);
// plain socket stuff
+++
SocketAppenderPtr mySocketAppender(
new SocketAppender(
LOG4CXX_STR("XXX.XXX.XXX.XXX"),
4560
)
);
mySocketAppender->activateOptions(pool);
logger->addAppender(mySocketAppender);
logger->addAppender(myXMLSocketAppender);
logger->setLevel(log4cxx::Level::getDebug());
unit test fails
Hi All, I'am planing to use log4cxx 0.10.0 on Windows XP, SP2 and MS VC 8, SP1, Group Edition. I have loaded the necessary packages and compiling them, as described on the website, works perfectly well. When trying to run the unit tests, i.e. 'testsuite' and/or 'testsuite-standalone', the executables crash without any warning right after (or at the end) of 'TimeBasedRollingTest'. Any clou why this happens? Perhaps, is this known issue Cheers Stefan
Could not create an Appender. (Class 'org.apache.log4j.RollingFileAppender' not found)
hello,all : My log4cxx version is 0.9.7,and when i linked my program with dynamic library, it worked fine. But i changed to linking with static log4cxx, i get the info listed below: Could not create an Appender. Reported error follows. Class 'org.apache.log4j.RollingFileAppender' not found I googled and got some advise below: 1/ by not using default configuration and doing an explicit configuration sometime after all the static initializers have completed . (But I don't know how) 2/ try using 0.9.8 (but some user of 0.9.8 got the same bug too, and i am trying ,too) any good suggestion? thanks in advance
Re: RE: log4cxx-CVS with stlport-4.6 application build fails
Hi,David Sewell:
I have successfully intergreted log4cxx-0.9.7 with stlport-4.6 in RH9
>Andreas,
>
>I'm using the following build processes.
>
>With the packages and test app installed in the following directories:
>
>log4cxx-CVS = ./log4cxx
>stlport-4.6 = ./stlport
>test app = ./log4cxx_sample
>
>log4cxx build process (I had to upgrade autoconf to 2.59):
>cd log4cxx; ant build
>
>stlport build process (using gcc.mak file, gcc-linux.mak fails):
>cd ../stlport/src; make -f gcc.mak
>
>I have not successfully integrated stlport with the log4cxx build process,
>I've tried using the automake approach which may allow me to add the stlport
>support via CXXFLAGS the LDFLAGS environment variables but the configure
>process fails in config.status (another problem I can't solve). This is
>probably the root cause of my problems. Does stlport support need to be built
>into the log4cxx libraries?
>
>Once log4cxx and stlport are built I can build the test application. Source
>and makefile are attached below.
>
>e.g.
>cd ../log4cxx_sample; make
>
>Thanks,
>David
>
>/
> * file: main.cpp
> /
>#include
>#include
>#include
>using namespace log4cxx;
>using namespace log4cxx::helpers;
>LoggerPtr logger(Logger::getLogger("Test"));
>int main(int argc, char **argv)
>{
> int result = EXIT_SUCCESS;
> try
> {
> BasicConfigurator::configure();
> LOG4CXX_INFO(logger, "Entering application");
> LOG4CXX_INFO(logger, "Exiting application");
> }
> catch(Exception&)
> {
> result = EXIT_FAILURE;
> }
>
> return result;
>}
>
>#
>
># file: Makefile
>
>#
>
>SHELL=/bin/bash
>
>LOG4CXX_LINK_PREFIX=../log4cxx
>STLPORT_LINK_PREFIX=../stlport
>
>CXX=g++
>CXX_FLAGS=-g -Wall -DLINUX -Wno-ctor-dtor-privacy
>INCLUDES=-I$(LOG4CXX_LINK_PREFIX)/include -I${STLPORT_LINK_PREFIX}/stlport
you have include the headers successful, so your mistakes become:
... _STL::basic_string...
>LIBS=-L$(STLPORT_LINK_PREFIX)/lib -lstlport_gcc
here, maybe you can change to
LIBS=-lstlport_gcc -Wl,--rpath -Wl,$(STLPORT_LINK_PREFIX)/lib
>LOG4CXX_LIBS=-L$(LOG4CXX_LINK_PREFIX)/build/debug/shared -llog4cxx
>SRCS := $(wildcard ./*.cpp)
>OBJS := $(patsubst %.cpp,%.o,$(SRCS))
>
>%.o: %.cpp
> @if [ `uname` = "SunOS" ]; \
>then \
>$(CXX) $(CXX_FLAGS) $(INCLUDES) -o $@ -c $<; \
>else \
>$(CXX) $(CXX_FLAGS) $(INCLUDES) -DLINUX -o $@ -c $<; \
>fi
>
>all: log4cxx_sample
>
>clean_all: clean all
>
>log4cxx_sample: $(OBJS)
> $(CXX) $(CXX_FLAGS) $(INCLUDES) $(LOG4CXX_LIBS) $(LIBS) -o log4cxx_sample
> $(OBJS)
>
>clean:
> rm log4cxx_sample *.o
>
>
>
>
>
>From: Andreas Fester [mailto:[EMAIL PROTECTED]
>Sent: Wed 22/06/2005 16:40
>To: Log4CXX User; David Sewell
>Subject: Re: log4cxx-CVS with stlport-4.6 application build fails
>
>
>
>David,
>
>I would be interested in running a build test :-)
>I run Debian GNU/Linux 3.1, but lets see if I can
>reproduce the issue.
>
>Can you provide some more information how you configured
>log4cxx? Do you use the ant build (and if so, how do you
>integrate stlport) or the automake approach (and also,
>if so, how do you integrate stlport)?
>
>Regards,
>
>Andreas
>
>David Sewell wrote:
>> I am trying to integrate log4cxx-CVS with an application that uses
>> stlport-4.6 on Linux (redhat es3) using g++ (3.2.3), however when I
>> add the stlport support to the compile line, the build fails with
>> "undefined reference" errors from the log4cxx library.
>>
>> I have rebuilt both log4cxx and stlport numerous times, as a test
>> case I have used the BasicConfigurator example from the log4cxx
>> documentation. This compiles and runs without the
>> '-I../stlport/stlport' flag but fails with the below error when the
>> flag is present. I can compile and run other applications using
>> stlport with no problems.
>>
>> I have searched all bug/support archives for both log4cxx and
>> stlport, the only documented issues that reference both libraries
>> don't seem to be relevant. I'm now at a loss as to what to do.
>>
>> Can someone confirm if log4cxx-CVS is known to work with stlport-4.6
>> on Linux?
>>
>> Any suggestions for what may be wrong and how I can resolve the
>> problem would
Re: Re: can log4cxx works fine with stlport?
Hi,Curt Arnold I add D_REENTRANT to the INCLUDES variable in Makefile and it works now > > >On Jun 18, 2005, at 2:36 AM, Forrest Energumen wrote: > >> Hi: >> i want to migrate my project from win32 to linux, i select log4cxx >> as my log system. >> it works fine with stlport 4.6.2 in win32 platform, but it can not >> work in linux. >> >> my log4cxx version is 0.9.7, when i compile it in linux, i build it >> with stlport-4.6 support,when I >> test the examples, it just show "segment fault" when running to >> "xml::DOMConfigurator::configure(LOGGER_CONFIG_FILE_NAME)" >> >> but if i do not compile the log4cxx-0.9.7 with stlport, it works fine >> >> so i just doubt that whether it can work with stlport or not in linux? >> > >log4cxx-0.9.7 had a large number of issues that have been already >resolved in the CVS HEAD. One in particular (http:// >issues.apache.org/jira/browse/LOGCXX-4) is likely the cause of the >problem that you are running into. Please try the CVS HEAD and see >if the problem still persists. >. 致 礼！ energumen [EMAIL PROTECTED] 2005-06-19
Wide Character Support
We are in the process of converting all char * definitions to wchar_t definitions, and this is proving a little more work than a simple cut and paste (We figured it would). Is there any reason log4cxx is wide character lacking, that I have overlooked? Ron mail2web - Check your email from the web at http://mail2web.com/ .
RE: Fwd: Build namespace issues
I don't know if this matters, but I also get the error on the
RollingFileAppender.
Original Message:
-
From: Curt Arnold [EMAIL PROTECTED]
Date: Tue, 15 Mar 2005 18:44:54 -0600
To: log4cxx-user@logging.apache.org
Subject: Fwd: Build namespace issues
Begin forwarded message:
> From: Curt Arnold <[EMAIL PROTECTED]>
> Date: March 15, 2005 4:15:01 PM CST
> To: Log4J Users List
> Subject: Re: Build namespace issues
>
> On Mar 15, 2005, at 3:31 PM, Ron Ohmer wrote:
>
>> I ran into a rather odd error when using SocketAppenders.
>>
>> I have a wrapper that has worked fine, no warnings, nothing until I
>> added functionality for the SocketAppender..
>>
>> Now I get what follows this.. Does anyone know the root of this
>> (Other than SocketAppender.cpp.. :-)) BTW, VS.NET 2k3 is the build
>> tool.
>>
>
> The problem is that pervasively throughout log4cxx (even the CVS
> HEAD), you see a construct like:
>
> class SocketImpl;
> typedef helpers::ObjectPtrT SocketImplPtr;
>
> When one of these smart-pointer templates is used in a publicly
> exposed method on a exported class, you end up with an exported method
> depending on a non-exported class. If the template expansion differs
> in any way from the expansion when the library was build, bad things
> will happen hence the warning.
>
> What should be done is something like:
>
> class SocketImpl;
> class LOG4CXX_EXPORT SocketImplPtr : public
> helpers::ObjectPtrT {
>...
> }
>
> I'll log this as a bug and work on it as soon I finish my current task
> (likely 24-48 hours away).
>
>
mail2web - Check your email from the web at
http://mail2web.com/ .
Re: Building log4cxx 0.9.7 with MinGW and MSYS (no cygwin)
Jwahar Bammi wrote: I cant say that I have compiled for a pure MingW environment, but I would pull the Cygnus libpthread for win32, specify that for thread and it should move the build ahead. That's the right solution. libpthread is intended for use with either Cygwin or Mingw. See their page and install it. The log4cxx configure script should be smart enough to detect all the things he reported though. --joel sherrill Jwahar Bammi Memento, Inc. [EMAIL PROTECTED] -Original Message- From: Enno Borgsteede [mailto:[EMAIL PROTECTED] Sent: Sunday, December 05, 2004 10:20 AM To: log4cxx-user@logging.apache.org Subject: Building log4cxx 0.9.7 with MinGW and MSYS (no cygwin) Hi, I'm trying to build version 0.9.7 under MinGW on XP Home. I'm running MinGW with MSYS and msysDTK, not CYGWIN. Searching the list archive didn't provide a solution, so here's a summury of what I tried. 1. I found that configure can't figure out whether threads are available. It stops with an error, but I can avoid that by specifying --with-threads=no on the command line. 2. Then compilation stops, because the type int64_t is not recognized. I can cure that too, by defining int64_t as __int64 in config.h. 3. I can't easily get past the third hurdle, which is the compiler complaining that the thread() object does not exist. I can't find an easy cure for that, so I'm stuck here. I can think of several options, but maybe someone else has tried this before, and give me directions: 1. Is --with-threads=no the right choice? 2. I use the latest versions of MinGW and MSYS. Would it help if I upgrade the compiler? I prefer not to upgrade to cygwin, because I like the MinGW philosophy better. thanks, Enno -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
