[GLASSFISH-1829] Server log output needs cleanup, filters and a verbosity level Created: 21/Dec/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: logging
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Task Priority: Major
Reporter: pinus Assignee: jielin
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 1,829

 Description   

I'm just coming from a Netbeans discussion about J2EE development with Netbeans
5.5. One issue was the verbose output on the console displayed at nearly every
operation. It is nearly impossible for the IDE to filter the output to show only
the important information the user currently needs.

If I deploy an application I want to know if it was successful or not. If I want
to see my setup I go to setup dialogs. And if I want to debug it I want to see
database statement Toplink creates but not every time I deploy.

The current output format makes it impossible to filter, e.g. for Toplink
messages, if I want to debug a Toplink issue. This is not only hard at
development time it makes debugging of multiple gigabyte log files on a
production server nearly impossible.

What I need is to filter at least the application (e.g. My Ear, My War, My WS,
...), the service (WS, EJB, JPA, ...) and some verbosity levels from errors
only, to warnings, to information, to debugging.



 Comments   
Comment by dpatil [ 11/Apr/07 ]

Reassigning.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-481] add query hint to disable jpql validation Created: 27/Mar/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: tware Assignee: jielin
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 481

 Description   

There are some restrictions to jpql in the EJB 3.0 persistence specification
for the query language that disallow some things that will work on some
databases. As a result, JPQL validation will disallow writing queries that
could provide correct results on certain databases.

An example is: IN

From the spec:

in_expression ::=
state_field_path_expression [NOT] IN ( in_item

{, in_item}

* | subquery)
in_item ::= literal | input_parameter
The state_field_path_expression must have a string, numeric, or enum value

On an Oracle database IN can be used with Dates. With a hint to disable
validation, it would be possible to write a JPQL query that would correctly
return values that used an IN with a Date.



 Comments   
Comment by marina vatkina [ 27/Mar/06 ]

Reassigned

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-136] JPQL validation: Parser not catching invalid type for subquery used with IN expression Created: 10/Jan/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: smcgowan Assignee: jielin
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 136

 Description   

Spec 4.6.8 In Expression states:
The state_field_path_expression must have a string or numeric value. The results
of the subquery must be like the same abstract schema type of the
state_field_expression in type.

The EJB QL parser does not catch the error if the result is not of the correct
type thus instead results in a SQLException.

EJB QL:
"Select c from Customer c WHERE c.aliases IN"
+ "(Select distinct a.alias from c.aliases a where
length(a.alias) = 4 ) ")

ERROR:

> Exception [TOPLINK-4002] (Oracle TopLink Essentials - 10g release 4
(10.1.4.0.0) (Build 051215Dev)): oracle.toplink.essentials.exc
ptions.DatabaseExceptionInternal Exception: java.sql.SQLException: [Oracle] #31
ORA-00936: missing expression
> Error Code: 936
> Call:SELECT DISTINCT t0.ID, t0.NAME, t0.FK5_FOR_CUSTOMER_TABLE, t0.CODE,
t0.COUNTRY, t0.FK6_FOR_CUSTOMER_TABLE FROM CUSTOMER_TABLE
> t0, FKS_ALIAS_CUSTOMER t2, ALIAS_TABLE t1 WHERE (( IN (SELECT DISTINCT
t3.ALIAS FROM FKS_ALIAS_CUSTOMER t4, ALIAS_TABLE t3 WHERE ((
> LENGTH(t3.ALIAS) = 4) AND ((t4.FK_FOR_CUSTOMER_TABLE = t0.ID) AND (t3.ID =
t4.FK_FOR_ALIAS_TABLE))))) AND ((t2.FK_FOR_CUSTOMER_TABL
> E = t0.ID) AND (t1.ID = t2.FK_FOR_ALIAS_TABLE)))
> Query:ReportQuery(mytest.Customer)
> at
oracle.toplink.essentials.exceptions.DatabaseException.sqlException(DatabaseException.java:30



 Comments   
Comment by mb124283 [ 10/Jan/06 ]

Assign it to Michael Bouschen.

Comment by mb124283 [ 17/Mar/06 ]

Updated summary.

Comment by jielin [ 22/Mar/06 ]

assign to jielin

Comment by jielin [ 23/Mar/06 ]

working on it.

Comment by jielin [ 24/Mar/06 ]

The issue is fix and in the review process. Will checkin code today.

Comment by jielin [ 27/Mar/06 ]

I just conferenced Michael and Marina. For issue 136, there are two
parts of validation: first part validates the allowed data type, second
part checks for compatibility of IN expression data type. So to allow
user still use timestamp or other type that supported by databases, the
first part of validation will not be checked in until we fix issue 481 -
add query hint to disable jpql validation :
https://glassfish.dev.java.net/issues/show_bug.cgi?id=481

I already check in the second part of fix. So no tests will be removed.
issue 136 will be adding all the discussion we had and downgrade to p4.

Belows are email threads saved for further discussion.

--------------------------------------------------------------------
I just had a conversation with Michael Bouschen and we have an idea.

I will enter a task in Issue Tracker to add a query hint that allows
validation to be disabled. For the time being we will continue with the
validation as we have it.

Jielin, you can remove the test.

-Tom

Tom Ware wrote:

>>It would be my preference if either validation did not disallow things
>>that will work on some databases or validation could be turned off.
>>
>>What does everyone else think?
>>
>>-Tom
>>
>>jie leng wrote:
>>
>>
>>
>
>>>>I test it agianst oracle, the test is working and the IN with dates
>>>>return the correct values.
>>>>
>>>>Thanks.
>>>>
>>>>Jielin

No, Shelly should not be using types that are not allowed by the
spec (cc-ing Shelly here).

The problem is - do we want to add validation that will reject types
that are not allowed by the spec for this query type, but supported
by some databases (e.g. Oracle)? My vote will be to comply with the spec.
But it's open for discussion.

The cut off date is Monday midnight (though I do not suggest to wait
that long). We can also agree to the decision Michael and Tom come up
with before BOB Monday PT.

What do you think?

thanks,
-marina

Eliot Morrison wrote:

>>
>> Do we need to give Shelly a heads up also if we do this ?
>>
>> Marina, what cutoff time do you recommend - late today ? Tomorrow ?
>> thanks,
>> Eliot
>>
>>
>>
>> Marina Vatkina wrote:
>>
>
>>>> Hi Jielin,
>>>>
>>>> This is an interesting question. Michael, what do you think?
>>>> I tend to disagree with Tom on this one.
>>>>
>>>> Jielin, if we don't come to a quick agreement, I suggest not to
>>>> check in the changes.
>>>>
>>>> thanks,
>>>> -marina
>>>>
>>>> jie leng wrote:
>>>>
>>
>>>>>> Hi, Eliot/Marina,
>>>>>>
>>>>>> I had the fix for issue 136 and Michael also reviewed it. Currently
>>>>>> becuase of my fix, there is one entity test
>>>>>> JUnitEJBQLDateTimeTestSuite.testTimestampIn() failed. The spec stated
>>>>>> clearly that IN expression is only for string, numeric and enum. so
>>>>>> timestamp is not supported by EJB3 spec. But some databases do
>>>>>> support IN for timestamp. I sent email out and Tom thought that since
>>>>>> IN with timestamp works for some databases, we should keep it. I need
>>>>>> some advice here.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Jielin

The spec says the following:

4.6.8 In Expressions
The syntax for the use of the comparison operator [NOT] IN in a
conditional expression is as follows:
in_expression ::=
state_field_path_expression [NOT] IN ( in_item

{, in_item}

* | subquery)
in_item ::= literal | input_parameter
The state_field_path_expression must have a string, numeric, or enum value

So, I guess the test can be removed, but I think the fact that it works
on some databases opens up the debate of whether it should be disallowed
by validation. I know it's a fine line, but, did the test actually
work, or just not fail? (i.e. did the IN with dates return correct values?)

-Tom

jie leng wrote:

>>Hi, Michael, Tom,
>>
>>I ran entity-persistence-tests on the change I made for InNode. The
>>JUnitEJBQLDateTimeTestSuite.testTimestampIn() failed because the
>>validation in InNode.java only allows string, numeric and enum type
>>according to the spec. Is the test for timestamp using IN still valid?
>>Should the test be removed?
>>
>>Thanks.
>>
>>Jielin

Comment by jielin [ 27/Mar/06 ]

downgrade to p4

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-1323] provide log compression Created: 17/Oct/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: logging
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Minor
Reporter: barz26 Assignee: jielin
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,323

 Description   

Besides log rotation GF should be capable of compressing rotated log files



 Comments   
Comment by barz26 [ 17/Oct/06 ]

Is RFE not defect

Comment by dpatil [ 12/Mar/07 ]

not for 9.1 FCS.

Comment by dpatil [ 11/Apr/07 ]

reassigning

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-1322] Provide out of the box JDBC based log handler Created: 17/Oct/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: logging
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Minor
Reporter: barz26 Assignee: jielin
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,322

 Description   

In addition to file based logging a configurable JDBC log handler should be
provided



 Comments   
Comment by dpatil [ 12/Mar/07 ]

not for FCS. downgrading to P4.

Comment by dpatil [ 11/Apr/07 ]

Assigning to jielin

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-1145] SSL debug is broken into many lines in server.log Created: 14/Sep/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: logging
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: Shing Wai Chan Assignee: jielin
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,145

 Description   

While specifying -Djavax.net.debug=ssl,handshake in domain.xml, the ssl debug
output has been broken into many lines.
For instance,
bytes ={ 147, 44, 186, 138, 103, 125, 82, 216
will be displaced as the following in the server.log:
bytes = {
147
,
44
,
186
,
138
,
103
,
125
,
82
,
216

This makes it difficult to understand the log or pass it to JDK team for further
debug.



 Comments   
Comment by gfbugbridge [ 20/Jan/07 ]

<BT6515591>

Comment by jielin [ 09/Apr/07 ]

After discussion with one of logging developer,this bug is a regression after
the fix of dead lock. It is too risky to fix at this time frame. Since there is
no functional broken, Downgrade to p4.

Comment by dpatil [ 11/Apr/07 ]

Assigning to jielin

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-1125] Add an option for GlassFish to rotate log file at every startup Created: 11/Sep/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: logging
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Minor
Reporter: Alexis MP Assignee: jielin
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,125

 Description   

Add an option for GlassFish to rotate log file at every start (and optionnaly
get rid of the old log files). Very useful in development mode. Should only
require an extra ANT task in the startup process.



 Comments   
Comment by dpatil [ 12/Mar/07 ]

downgrading to P4, doesn't see to be useful if log file size is not big enought
and see the usecase.

Comment by dpatil [ 11/Apr/07 ]

Assigning to jielin

Comment by Alexis MP [ 26/May/07 ]
      • Issue 1125 has been confirmed by votes. ***
Comment by Alexis MP [ 26/May/07 ]

IDEs (mainly NetBeans) dump the entire content of server.log in the server
output window on app server startup which is not good for demos and makes
developers thinks older exceptions/errors are happening on this startup.

See also http://www.netbeans.org/issues/show_bug.cgi?id=104905

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-2327] module-log-levels does not permit setting level for "core" Created: 05/Feb/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: logging
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Minor
Reporter: Tim Quinn Assignee: jielin
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 2,327

 Description   

The logging level for the "core" logging component cannot be set using the admin
GUI or by adding the intuitive

core="level"

attribute in the module-log-levels element in domain.xml.

Kedar has suggested the workaround of setting

<property name="javax.enterprise.system.core" value="FINE"/>

as a child of the module-log-levels element in domain.xml, and this works fine
as a workaround. But it's very cumbersome and is inconsistent with how the
other module levels are controlled.



 Comments   
Comment by jielin [ 28/Feb/07 ]

javax.enterprise.system.core is not defined in element module-log-levels in
sun-domain_1_3.dtd. So this is not a bug, it is an enhancement. To add this
enhancement, first the dtd need to be changed.

There is a good enough work around for it. In Admin GUI, add user defined
propery in log level screen.

Comment by jielin [ 26/Mar/07 ]

Since there is good work around, downgrade to p4

Comment by dpatil [ 11/Apr/07 ]

reassigning.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-2182] FindBugs high level errors in logging Created: 22/Jan/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: logging
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: jagadesh Assignee: jielin
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 2,182

 Description   

he following are the findbugs errors in logging area under different glassfish
modules. The errors are prefixed with user-id (who checked in the sources). See
the full report @URL
https://glassfish.dev.java.net/quality/fb-developer-report.html )

In appserv-commons module:
==========================

dpatil: com/sun/enterprise/log/Log.java:39:39 MS: com.sun.enterprise.log.Log.out
isn't final but should be (H)
dpatil: com/sun/enterprise/log/Log.java:40:40 MS: com.sun.enterprise.log.Log.err
isn't final but should be (H)

In appserv-core module:
=======================

dpatil: com/sun/enterprise/server/logging/ServerLogManager.java:106:106 ST:
Write to static field
com.sun.enterprise.server.logging.ServerLogManager.thisInstance from instance
method com.sun.enterprise.server.logging.ServerLogManager.ServerLogManager() (H)
dpatil: com/sun/enterprise/server/logging/LogMBean.java:431:431 ST: Write to
static field com.sun.enterprise.server.logging.LogMBean.mBeanInfo from instance
method com.sun.enterprise.server.logging.LogMBean.initialize() (H)



 Comments   
Comment by jielin [ 06/Mar/07 ]

They are not really bugs. They are findbugs errors. Will not fix at this time frame.

Comment by dpatil [ 11/Apr/07 ]

reassigning

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-2167] <BT6499906>Logging level for "ClientAbortException: java.io.IOException: Broken pipe" need to be changed Created: 20/Jan/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: gfbugbridge Assignee: jielin
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Solaris
Platform: All


Issuezilla Id: 2,167

 Description   

*********READ-ONLY Data from Bugtraq*********************
Inside SWAN :http://swsblweb1.central.sun.com:8080/CrPrint?id=6499906
Outside SWAN :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6499906
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Description The customer is PEERFLIX INC.
"ClientAbortException" should not be thrown by default as "WARNING". It should be thrown at a higher level so that the user will get this exception only if they increase the logging level. Here's the complete stack trace of this exception:

[#|2006-11-29T12:56:00.188-0800|WARNING|sun-appserver-pe9.0|javax.enterprise.resource.webcontainer.jsf.lifecycle|_ThreadID=13;_ThreadName=httpWorkerThread-8080-2;_RequestID=24db5fb3-0e10-462f-a433-2307a9024423;|LifecycleImpl.phase: executePhase(RENDER_RESPONSE 6,com.sun.faces.context.FacesContextImpl@1f91a78) threw exception
javax.faces.FacesException
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:161)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:244)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:140)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:245)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:397)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:184)
at peerflix.jsf.servlet.PfxServletFilter.doFilter(PfxServletFilter.java:90)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:216)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:184)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:276)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:179)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:182)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline.java:120)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:239)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.invokeAdapter(ProcessorTask.java:667)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.processNonBlocked(ProcessorTask.java:574)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:844)
at com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:287)
at com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:212)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252)
at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:75)
Caused by: ClientAbortException: java.io.IOException: Broken pipe
at org.apache.coyote.tomcat5.OutputBuffer.realWriteBytes(OutputBuffer.java:414)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:302)
at org.apache.tomcat.util.buf.IntermediateOutputStream.write(C2BConverter.java:247)
at sun.nio.cs.StreamEncoder$CharsetSE.writeBytes(StreamEncoder.java:336)
at sun.nio.cs.StreamEncoder$CharsetSE.implFlushBuffer(StreamEncoder.java:404)
at sun.nio.cs.StreamEncoder$CharsetSE.implFlush(StreamEncoder.java:408)
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:152)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:213)
at org.apache.tomcat.util.buf.WriteConvertor.flush(C2BConverter.java:196)
at org.apache.tomcat.util.buf.C2BConverter.flushBuffer(C2BConverter.java:139)
at org.apache.coyote.tomcat5.OutputBuffer.realWriteChars(OutputBuffer.java:611)
at org.apache.tomcat.util.buf.CharChunk.flushBuffer(CharChunk.java:438)
at org.apache.coyote.tomcat5.OutputBuffer.doFlush(OutputBuffer.java:355)
at org.apache.coyote.tomcat5.OutputBuffer.flush(OutputBuffer.java:338)
at org.apache.coyote.tomcat5.CoyoteResponse.flushBuffer(CoyoteResponse.java:590)
at org.apache.coyote.tomcat5.CoyoteResponseFacade.flushBuffer(CoyoteResponseFacade.java:277)
at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:217)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:133)
... 32 more
Caused by: java.io.IOException: Broken pipe
at sun.nio.ch.FileDispatcher.write0(Native Method)
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:29)
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:104)
at sun.nio.ch.IOUtil.write(IOUtil.java:75)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:302)
at com.sun.enterprise.web.connector.grizzly.OutputWriter.flushChannel(OutputWriter.java:52)
at com.sun.enterprise.web.connector.grizzly.SocketChannelOutputBuffer.flushChannel(SocketChannelOutputBuffer.java:115)
at com.sun.enterprise.web.connector.grizzly.SocketChannelOutputBuffer.realWriteBytes(SocketChannelOutputBuffer.java:105)
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:404)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:326)
at org.apache.coyote.http11.InternalOutputBuffer$OutputStreamOutputBuffer.doWrite(InternalOutputBuffer.java:789)
at org.apache.coyote.http11.filters.ChunkedOutputFilter.doWrite(ChunkedOutputFilter.java:134)
at org.apache.coyote.http11.InternalOutputBuffer.doWrite(InternalOutputBuffer.java:583)
at org.apache.coyote.Response.doWrite(Response.java:575)
at org.apache.coyote.tomcat5.OutputBuffer.realWriteBytes(OutputBuffer.java:409)
... 49 more

#]

This is filling up the customer logs.

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Justification Priority changed from [] to [3-Medium]The stack trace of this exception is filling up the customer logs when the client terminate the requests. This exception should not be thrown by default as "WARNING". It should be thrown at a higher level so that the user will get this exception only if they increase the logging XXXXXX 2006-12-01 21:10:55 GMT

**********READ-ONLY Data from Bugtraq Ends********



 Comments   
Comment by gfbugbridge [ 24/Jan/07 ]

*********READ-ONLY Data from Bugtraq*********************
Inside SWAN :http://swsblweb1.central.sun.com:8080/CrPrint?id=6499906
Outside SWAN :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6499906
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Description The customer is PEERFLIX INC.
"ClientAbortException" should not be thrown by default as "WARNING". It should be thrown at a higher level so that the user will get this exception only if they increase the logging level. Here's the complete stack trace of this exception:

[#|2006-11-29T12:56:00.188-0800|WARNING|sun-appserver-pe9.0|javax.enterprise.resource.webcontainer.jsf.lifecycle|_ThreadID=13;_ThreadName=httpWorkerThread-8080-2;_RequestID=24db5fb3-0e10-462f-a433-2307a9024423;|LifecycleImpl.phase: executePhase(RENDER_RESPONSE 6,com.sun.faces.context.FacesContextImpl@1f91a78) threw exception
javax.faces.FacesException
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:161)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:244)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:140)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:245)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:397)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:184)
at peerflix.jsf.servlet.PfxServletFilter.doFilter(PfxServletFilter.java:90)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:216)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:184)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:276)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:179)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:182)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline.java:120)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:239)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.invokeAdapter(ProcessorTask.java:667)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.processNonBlocked(ProcessorTask.java:574)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:844)
at com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:287)
at com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:212)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252)
at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:75)
Caused by: ClientAbortException: java.io.IOException: Broken pipe
at org.apache.coyote.tomcat5.OutputBuffer.realWriteBytes(OutputBuffer.java:414)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:302)
at org.apache.tomcat.util.buf.IntermediateOutputStream.write(C2BConverter.java:247)
at sun.nio.cs.StreamEncoder$CharsetSE.writeBytes(StreamEncoder.java:336)
at sun.nio.cs.StreamEncoder$CharsetSE.implFlushBuffer(StreamEncoder.java:404)
at sun.nio.cs.StreamEncoder$CharsetSE.implFlush(StreamEncoder.java:408)
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:152)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:213)
at org.apache.tomcat.util.buf.WriteConvertor.flush(C2BConverter.java:196)
at org.apache.tomcat.util.buf.C2BConverter.flushBuffer(C2BConverter.java:139)
at org.apache.coyote.tomcat5.OutputBuffer.realWriteChars(OutputBuffer.java:611)
at org.apache.tomcat.util.buf.CharChunk.flushBuffer(CharChunk.java:438)
at org.apache.coyote.tomcat5.OutputBuffer.doFlush(OutputBuffer.java:355)
at org.apache.coyote.tomcat5.OutputBuffer.flush(OutputBuffer.java:338)
at org.apache.coyote.tomcat5.CoyoteResponse.flushBuffer(CoyoteResponse.java:590)
at org.apache.coyote.tomcat5.CoyoteResponseFacade.flushBuffer(CoyoteResponseFacade.java:277)
at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:217)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:133)
... 32 more
Caused by: java.io.IOException: Broken pipe
at sun.nio.ch.FileDispatcher.write0(Native Method)
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:29)
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:104)
at sun.nio.ch.IOUtil.write(IOUtil.java:75)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:302)
at com.sun.enterprise.web.connector.grizzly.OutputWriter.flushChannel(OutputWriter.java:52)
at com.sun.enterprise.web.connector.grizzly.SocketChannelOutputBuffer.flushChannel(SocketChannelOutputBuffer.java:115)
at com.sun.enterprise.web.connector.grizzly.SocketChannelOutputBuffer.realWriteBytes(SocketChannelOutputBuffer.java:105)
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:404)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:326)
at org.apache.coyote.http11.InternalOutputBuffer$OutputStreamOutputBuffer.doWrite(InternalOutputBuffer.java:789)
at org.apache.coyote.http11.filters.ChunkedOutputFilter.doWrite(ChunkedOutputFilter.java:134)
at org.apache.coyote.http11.InternalOutputBuffer.doWrite(InternalOutputBuffer.java:583)
at org.apache.coyote.Response.doWrite(Response.java:575)
at org.apache.coyote.tomcat5.OutputBuffer.realWriteBytes(OutputBuffer.java:409)
... 49 more

#]

This is filling up the customer logs.

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Justification Priority changed from [] to [3-Medium]The stack trace of this exception is filling up the customer logs when the client terminate the requests. This exception should not be thrown by default as "WARNING". It should be thrown at a higher level so that the user will get this exception only if they increase the logging XXXXXX 2006-12-01 21:10:55 GMT

**********READ-ONLY Data from Bugtraq Ends********

Comment by gfbugbridge [ 15/Mar/07 ]

*********READ-ONLY Data from Bugtraq*********************
Inside SWAN :http://swsblweb1.central.sun.com:8080/CrPrint?id=6499906
Outside SWAN :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6499906
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Description The customer is PEERFLIX INC.
"ClientAbortException" should not be thrown by default as "WARNING". It should be thrown at a higher level so that the user will get this exception only if they increase the logging level. Here's the complete stack trace of this exception:

[#|2006-11-29T12:56:00.188-0800|WARNING|sun-appserver-pe9.0|javax.enterprise.resource.webcontainer.jsf.lifecycle|_ThreadID=13;_ThreadName=httpWorkerThread-8080-2;_RequestID=24db5fb3-0e10-462f-a433-2307a9024423;|LifecycleImpl.phase: executePhase(RENDER_RESPONSE 6,com.sun.faces.context.FacesContextImpl@1f91a78) threw exception
javax.faces.FacesException
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:161)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:244)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:140)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:245)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:397)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:184)
at peerflix.jsf.servlet.PfxServletFilter.doFilter(PfxServletFilter.java:90)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:216)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:184)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:276)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:179)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:182)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline.java:120)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:239)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.invokeAdapter(ProcessorTask.java:667)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.processNonBlocked(ProcessorTask.java:574)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:844)
at com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:287)
at com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:212)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252)
at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:75)
Caused by: ClientAbortException: java.io.IOException: Broken pipe
at org.apache.coyote.tomcat5.OutputBuffer.realWriteBytes(OutputBuffer.java:414)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:302)
at org.apache.tomcat.util.buf.IntermediateOutputStream.write(C2BConverter.java:247)
at sun.nio.cs.StreamEncoder$CharsetSE.writeBytes(StreamEncoder.java:336)
at sun.nio.cs.StreamEncoder$CharsetSE.implFlushBuffer(StreamEncoder.java:404)
at sun.nio.cs.StreamEncoder$CharsetSE.implFlush(StreamEncoder.java:408)
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:152)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:213)
at org.apache.tomcat.util.buf.WriteConvertor.flush(C2BConverter.java:196)
at org.apache.tomcat.util.buf.C2BConverter.flushBuffer(C2BConverter.java:139)
at org.apache.coyote.tomcat5.OutputBuffer.realWriteChars(OutputBuffer.java:611)
at org.apache.tomcat.util.buf.CharChunk.flushBuffer(CharChunk.java:438)
at org.apache.coyote.tomcat5.OutputBuffer.doFlush(OutputBuffer.java:355)
at org.apache.coyote.tomcat5.OutputBuffer.flush(OutputBuffer.java:338)
at org.apache.coyote.tomcat5.CoyoteResponse.flushBuffer(CoyoteResponse.java:590)
at org.apache.coyote.tomcat5.CoyoteResponseFacade.flushBuffer(CoyoteResponseFacade.java:277)
at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:217)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:133)
... 32 more
Caused by: java.io.IOException: Broken pipe
at sun.nio.ch.FileDispatcher.write0(Native Method)
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:29)
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:104)
at sun.nio.ch.IOUtil.write(IOUtil.java:75)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:302)
at com.sun.enterprise.web.connector.grizzly.OutputWriter.flushChannel(OutputWriter.java:52)
at com.sun.enterprise.web.connector.grizzly.SocketChannelOutputBuffer.flushChannel(SocketChannelOutputBuffer.java:115)
at com.sun.enterprise.web.connector.grizzly.SocketChannelOutputBuffer.realWriteBytes(SocketChannelOutputBuffer.java:105)
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:404)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:326)
at org.apache.coyote.http11.InternalOutputBuffer$OutputStreamOutputBuffer.doWrite(InternalOutputBuffer.java:789)
at org.apache.coyote.http11.filters.ChunkedOutputFilter.doWrite(ChunkedOutputFilter.java:134)
at org.apache.coyote.http11.InternalOutputBuffer.doWrite(InternalOutputBuffer.java:583)
at org.apache.coyote.Response.doWrite(Response.java:575)
at org.apache.coyote.tomcat5.OutputBuffer.realWriteBytes(OutputBuffer.java:409)
... 49 more

#]

This is filling up the customer logs.

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Evaluation It would be more useful to find out why these ClientAbortExceptions are occurringwith such frequency. I'd rather not change the logging levels as it might end up
hiding a real issue.

Who can I contact at peerflix to discuss this further?

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Justification Priority changed from [] to [3-Medium]The stack trace of this exception is filling up the customer logs when the client terminate the requests. This exception should not be thrown by default as "WARNING". It should be thrown at a higher level so that the user will get this exception only if they increase the logging XXXXXX 2006-12-01 21:10:55 GMT

**********READ-ONLY Data from Bugtraq Ends********

Comment by gfbugbridge [ 15/Mar/07 ]

*********READ-ONLY Data from Bugtraq*********************
Inside SWAN :http://swsblweb1.central.sun.com:8080/CrPrint?id=6499906
Outside SWAN :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6499906
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Description The customer is PEERFLIX INC.
"ClientAbortException" should not be thrown by default as "WARNING". It should be thrown at a higher level so that the user will get this exception only if they increase the logging level. Here's the complete stack trace of this exception:

[#|2006-11-29T12:56:00.188-0800|WARNING|sun-appserver-pe9.0|javax.enterprise.resource.webcontainer.jsf.lifecycle|_ThreadID=13;_ThreadName=httpWorkerThread-8080-2;_RequestID=24db5fb3-0e10-462f-a433-2307a9024423;|LifecycleImpl.phase: executePhase(RENDER_RESPONSE 6,com.sun.faces.context.FacesContextImpl@1f91a78) threw exception
javax.faces.FacesException
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:161)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:244)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:140)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:245)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:397)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:184)
at peerflix.jsf.servlet.PfxServletFilter.doFilter(PfxServletFilter.java:90)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:216)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:184)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:276)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:179)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:182)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline.java:120)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:239)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.invokeAdapter(ProcessorTask.java:667)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.processNonBlocked(ProcessorTask.java:574)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:844)
at com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:287)
at com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:212)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252)
at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:75)
Caused by: ClientAbortException: java.io.IOException: Broken pipe
at org.apache.coyote.tomcat5.OutputBuffer.realWriteBytes(OutputBuffer.java:414)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:302)
at org.apache.tomcat.util.buf.IntermediateOutputStream.write(C2BConverter.java:247)
at sun.nio.cs.StreamEncoder$CharsetSE.writeBytes(StreamEncoder.java:336)
at sun.nio.cs.StreamEncoder$CharsetSE.implFlushBuffer(StreamEncoder.java:404)
at sun.nio.cs.StreamEncoder$CharsetSE.implFlush(StreamEncoder.java:408)
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:152)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:213)
at org.apache.tomcat.util.buf.WriteConvertor.flush(C2BConverter.java:196)
at org.apache.tomcat.util.buf.C2BConverter.flushBuffer(C2BConverter.java:139)
at org.apache.coyote.tomcat5.OutputBuffer.realWriteChars(OutputBuffer.java:611)
at org.apache.tomcat.util.buf.CharChunk.flushBuffer(CharChunk.java:438)
at org.apache.coyote.tomcat5.OutputBuffer.doFlush(OutputBuffer.java:355)
at org.apache.coyote.tomcat5.OutputBuffer.flush(OutputBuffer.java:338)
at org.apache.coyote.tomcat5.CoyoteResponse.flushBuffer(CoyoteResponse.java:590)
at org.apache.coyote.tomcat5.CoyoteResponseFacade.flushBuffer(CoyoteResponseFacade.java:277)
at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:217)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:133)
... 32 more
Caused by: java.io.IOException: Broken pipe
at sun.nio.ch.FileDispatcher.write0(Native Method)
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:29)
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:104)
at sun.nio.ch.IOUtil.write(IOUtil.java:75)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:302)
at com.sun.enterprise.web.connector.grizzly.OutputWriter.flushChannel(OutputWriter.java:52)
at com.sun.enterprise.web.connector.grizzly.SocketChannelOutputBuffer.flushChannel(SocketChannelOutputBuffer.java:115)
at com.sun.enterprise.web.connector.grizzly.SocketChannelOutputBuffer.realWriteBytes(SocketChannelOutputBuffer.java:105)
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:404)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:326)
at org.apache.coyote.http11.InternalOutputBuffer$OutputStreamOutputBuffer.doWrite(InternalOutputBuffer.java:789)
at org.apache.coyote.http11.filters.ChunkedOutputFilter.doWrite(ChunkedOutputFilter.java:134)
at org.apache.coyote.http11.InternalOutputBuffer.doWrite(InternalOutputBuffer.java:583)
at org.apache.coyote.Response.doWrite(Response.java:575)
at org.apache.coyote.tomcat5.OutputBuffer.realWriteBytes(OutputBuffer.java:409)
... 49 more

#]

This is filling up the customer logs.

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Evaluation It would be more useful to find out why these ClientAbortExceptions are occurringwith such frequency. I'd rather not change the logging levels as it might end up
hiding a real issue.

Who can I contact at peerflix to discuss this further?

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Justification Priority changed from [] to [3-Medium]The stack trace of this exception is filling up the customer logs when the client terminate the requests. This exception should not be thrown by default as "WARNING". It should be thrown at a higher level so that the user will get this exception only if they increase the logging XXXXXX 2006-12-01 21:10:55 GMT

**********READ-ONLY Data from Bugtraq Ends********

Comment by jielin [ 26/Mar/07 ]

From evaluation provided above, downgrade it to p4.

Comment by dpatil [ 11/Apr/07 ]

reassigning.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-2117] thread-unsafe code in com.sun.enterprise.server.logging.ServerLogManager Created: 19/Jan/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: logging
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: llc Assignee: jielin
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 2,117

 Description   

The variables 'customHandler' and 'customFilter' are not synchronized or volatile, leading to visibility
and/or race condition issues. With both of them being used, any synchronization has to surround the
paired usage:

private static Handler customHandler = null;
private static Filter customFilter = null;
....

private static Filter getCustomFilter( ) {
if(( customFilter != null )

( customFilterError ) ) { return customFilter; }

LogService logService = getLogService( );
if( logService == null )

{ return null; }

String customFilterClassName = null;
try

{ customFilterClassName = logService.getLogFilter( ); customFilter = (Filter) getInstance( customFilterClassName ); }

catch( Exception e )

{ customFilterError = true; new ErrorManager().error( "Error In Instantiating Custom Filter " + customFilterClassName, e, ErrorManager.GENERIC_FAILURE ); }

return customFilter;
}



 Comments   
Comment by gfbugbridge [ 20/Jan/07 ]

<BT6515594>

Comment by sridatta [ 22/Jan/07 ]

will be fixed for FCS.Downgrading to a P3.

Comment by jielin [ 06/Mar/07 ]

They are not reaaly bugs. Will not fix at this time frame.

Comment by llc [ 06/Mar/07 ]

You're claiming they're thread safe?

Or that they're not thread safe, but somehow called in a way that is thread safe?

If "they won't be fixed at this time", then that presumes there is something to fix, so how can they "not be
bugs"?

Comment by dpatil [ 11/Apr/07 ]

reassigning

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





Generated at Wed Jun 03 23:13:06 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.