Mailing-List: contact log4j-user-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Users List" <log4j-user@logging.apache.org>
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
From: <Walter_Marvin@DellTeam.com>
To: <log4j-user@logging.apache.org>
Subject: RE: Web Service Appender
Thread-Topic: Web Service Appender
Thread-Index: 
 AQHPZNNaKheWFfWynU6CqjY0BF+WBJsrODiAgAA4cICAAAGUAIAAp4AAgAAQ7YD//61ogIAAWFCA//+wAbCAAFZugIAAICeAgAWsWjA=
Date: Mon, 5 May 2014 13:42:13 +0000
Message-ID: 
 <C4A4624C5EA472408D8E89555D0E6E52C28F0E@DFWX10HMPTC01.AMER.DELL.COM>
References: 
 <CAOTvRPwHudOtzSVYoBN-528+tP5-JUJ8vO2he28TELkuqPMumA@mail.gmail.com>
	<CAAFrFhSWSbyJdayAbuB8yLyRdmpiyfvF_3FaCKWY8vmSaX-2-Q@mail.gmail.com>
	<CAOTvRPx28L3X_0pZf4VYdHTZk7eVcm0yESLkq-2B5-RLz+OUpg@mail.gmail.com>
	<641BF779-851D-491F-A7A3-FB8901435279@dslextreme.com>
	<CAOTvRPw7Ef8a=pyL8iOvU_zNxzFcC90fRDE6=UcjjxV2ZMkPww@mail.gmail.com>
	<F3FEE39E-D31B-4254-B2F7-6ADFAEECDF9C@dslextreme.com>
	<C4A4624C5EA472408D8E89555D0E6E52C2837E@DFWX10HMPTC01.AMER.DELL.COM>
	<3ECFE551-06A6-4D93-9B9A-0CB98241C680@dslextreme.com>
	<C4A4624C5EA472408D8E89555D0E6E52C283C1@DFWX10HMPTC01.AMER.DELL.COM>
	<6DE89D99-0CF7-4944-90EE-7EAAD9C1EED9@dslextreme.com>
 <CAOTvRPz+SMhOZhHByMbWzELQVT+mMo3_Gyav5V1W5EU1Z-wceA@mail.gmail.com>
In-Reply-To: 
 <CAOTvRPz+SMhOZhHByMbWzELQVT+mMo3_Gyav5V1W5EU1Z-wceA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_C4A4624C5EA472408D8E89555D0E6E52C28F0EDFWX10HMPTC01AMER_"
MIME-Version: 1.0

--_000_C4A4624C5EA472408D8E89555D0E6E52C28F0EDFWX10HMPTC01AMER_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dell - Internal Use - Confidential
Marshalling and unmarshalling is indeed inefficient, being CPU intensive, w=
hich competes for cycles with the main processes. JMS appears to have inter=
nal queuing, persistence to disk, and
Asynchronous transport acknowledgements. It would be good to relieve the CP=
U pressure by using parallel processing in the stream, perhaps tux.

-----Original Message-----
From: Evan J [mailto:maps.this.address@gmail.com]
Sent: Thursday, May 01, 2014 12:54 PM
To: Log4J Users List
Subject: Re: Web Service Appender

This is just gone off the tangent line... in a good way though.

We are going to try to push back and redesign the process to just simply ma=
ke use of JMSAppender to put messages on a queue and have JMS clients consu=
me them (and ultimately insert the logs into a database -- maybe use JSON f=
or messages). The MQ runs within an integration broker, hence an initial id=
ea of routing logging SOAP/service calls through the same broker that handl=
es/routes other web services.

This whole marshalling and unmarshalling is very inefficient, on top of a f=
act that this proposed logging service is entirely internal to begin with.


On Thu, May 1, 2014 at 10:59 AM, Ralph Goers wrote:

> This thread originally started to ask about logging to a web service
> (that term usually implies SOAP). It seems to have gone off into
> another direction and I'm not sure if there is still a question here
> someone wants answered. If you are making a proposal for an
> enhancement to Log4j 2 I am not sure what it is.
>
> Ralph
>
> On May 1, 2014, at 8:51 AM,
> wrote:
>
> > Dell - Internal Use - Confidential
> > I take it we were discussing the possibilities for high speed
> > production
> logging. Previous people have rightly pointed out that a simplistic
> approach using soap might be ineffecient
> >
> > -----Original Message-----
> > From: Ralph Goers [mailto:ralph.goers@dslextreme.com]
> > Sent: Thursday, May 01, 2014 10:36 AM
> > To: Log4J Users List
> > Subject: Re: Web Service Appender
> >
> > Thats fine. I'm just not really sure what the question is any more.
> >
> > Ralph
> >
> > On May 1, 2014, at 8:22 AM, Walter_Marvin@DellTeam.com wrote:
> >
> >> Dell - Internal Use - Confidential
> >> As I say there are a lot of architectural options. We need to
> >> decide on
> one. Having th ability to modify log4j should make whatever
> architecture is chosen cleaner.
> >>
> >> Thanks
> >>
> >> Walter
> >>
> >> -----Original Message-----
> >> From: Ralph Goers [mailto:ralph.goers@dslextreme.com]
> >> Sent: Thursday, May 01, 2014 10:16 AM
> >> To: Log4J Users List
> >> Subject: Re: Web Service Appender
> >>
> >> What you are describing is why I added the integration to Flume. It
> >> is
> very, very good at collecting log events and forwarding them. However,
> you could use a JMS appender to write your events to the MQ queue.
> >>
> >> Ralph
> >>
> >> On May 1, 2014, at 7:15 AM, Evan J wrote:
> >>
> >>> Hi Ralph,
> >>>
> >>> All the request and response messages, some header data, with
> >>> additional information, are placed in an MDC, packaged in an
> >>> Appender and sent to an MQ queue which, ultimately, makes a call
> >>> to the service. It's a centralized logging model for all the
> >>> applications in a cluster. Frankly, I don't like the design nor
> >>> the setup, but I don't
> make such decisions (or requirements).
> >>>
> >>>
> >>> On Wed, Apr 30, 2014 at 11:15 PM, Ralph Goers wrote:
> >>>
> >>>> A web service to do what? Logging via SOAP would be extremely
> >>>> slow if every log event is a single request. Can you elaborate on
> >>>> what you really want to do?
> >>>>
> >>>> Ralph
> >>>>
> >>>> On Apr 30, 2014, at 9:10 PM, Evan J wrote:
> >>>>
> >>>>> Thanks for verifying this. I thought I might be missing an
> >>>>> obvious, and this has already been implemented by at least someone.
> >>>>>
> >>>>>
> >>>>> On Wed, Apr 30, 2014 at 7:48 PM, Remko Popma
> >>>> wrote:
> >>>>>
> >>>>>> Evan, no I'm not aware of any appender that logs to a web service.
> >>>>>>
> >>>>>>
> >>>>>> On Thu, May 1, 2014 at 9:21 AM, Evan J
> >>>>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> I searched around, but I could not find an off-the-shelf
> >>>>>>> Appender that sends logs to a web service. Is there any?
> >>>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>> -----------------------------------------------------------------
> >>>> ---
> >>>> - To unsubscribe, e-mail:
> >>>> log4j-user-unsubscribe@logging.apache.org
> >>>> For additional commands, e-mail:
> >>>> log4j-user-help@logging.apache.org
> >>>>
> >>>>
> >>
> >>
> >> -------------------------------------------------------------------
> >> -- To unsubscribe, e-mail:
> >> log4j-user-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>

--_000_C4A4624C5EA472408D8E89555D0E6E52C28F0EDFWX10HMPTC01AMER_--