Advice on where to start with garbled/junk page output for some requests

dev google-group-archive
1

Hi everyone,

I’ve been working on converting an application from ACF9 to Lucee 4 and
there is something very odd going on. Our testers are reporting that every
so often they receive page output that is just a bunch of mangled/garbage
characters. I have seen it myself once or twice (out of hundreds of
requests) so I know it’s not a false report; just rare. Reloading the page
will result in the correct output. I’m going to be collecting more
information as I can but any direction or ideas on where to even begin
would be very much appreciated!

A little info about our environment:

2

Hi Jordan,

Thanks for your reply!

To answer your question; no, we aren’t using any custom fonts in this
application. Let me try to elaborate on some details about the request
(hopefully I can actually post an example of the output soon).

  • I mean to say that the “output” of the page is garbled/mangled. The
    characters appearing in the output are plainly text but have no meaning. Think
    something like “Q9%h!2JJ~0#cRp&” but much longer.
  • There is absolutely no rendered output by the browser (no icons, text,
    tables, etc) other than the large string of random characters.
  • The request takes an unusually long amount of time to load.
  • I do not have the status code returned to the browser yet.
  • Nothing appears in the exception.log.On Monday, November 2, 2015 at 1:27:04 PM UTC-7, AWDSOFT wrote:

Hi everyone,

I’ve been working on converting an application from ACF9 to Lucee 4 and
there is something very odd going on. Our testers are reporting that every
so often they receive page output that is just a bunch of mangled/garbage
characters. I have seen it myself once or twice (out of hundreds of
requests) so I know it’s not a false report; just rare. Reloading the page
will result in the correct output. I’m going to be collecting more
information as I can but any direction or ideas on where to even begin
would be very much appreciated!

A little info about our environment:

3

More information about the ‘garbled characters’ would be helpful, however, I’ve had experiences recently that could be similar. In my own recent experiences, I had a web application firewall that was filtering out some custom font files. This caused custom icons to change to “garbled characters” instead of the font icons that they were supposed to be. Do you use custom font icons in your application? Are you certain these custom fonts (the actual font files and their related CSS) are coming through properly and being referenced properly? If not, this can lead to ‘garbled characters’.

Cross-site scripting protections (CORS) can also be a cause of this issue. Try viewing your site through an external proxy to help identify issues like these.

Hope this helps!

Kind regards,
Jordan Michaels----- Original Message -----
From: “AWDSOFT” <@AWDSOFT>
To: “Lucee” lucee@googlegroups.com
Sent: Monday, November 2, 2015 12:27:03 PM
Subject: [Lucee] Advice on where to start with garbled/junk page output for some requests

Hi everyone,

I’ve been working on converting an application from ACF9 to Lucee 4 and
there is something very odd going on. Our testers are reporting that every
so often they receive page output that is just a bunch of mangled/garbage
characters. I have seen it myself once or twice (out of hundreds of
requests) so I know it’s not a false report; just rare. Reloading the page
will result in the correct output. I’m going to be collecting more
information as I can but any direction or ideas on where to even begin
would be very much appreciated!

A little info about our environment:

–
You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/b554f5b5-c03e-4d85-a582-7f9f4d2a5b26%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

4

If the data for the garbled pages is coming from a database it could be an
issue with the character encoding settings. I’ve seen similar issues when
the data in the database is stored with a different charset than the
original source of the data. Hope that helps.

MikeOn Mon, Nov 2, 2015 at 4:57 PM, AWDSOFT <@AWDSOFT> wrote:

Hi Jordan,

Thanks for your reply!

To answer your question; no, we aren’t using any custom fonts in this
application. Let me try to elaborate on some details about the request
(hopefully I can actually post an example of the output soon).

  • I mean to say that the “output” of the page is garbled/mangled. The
    characters appearing in the output are plainly text but have no meaning. Think
    something like “Q9%h!2JJ~0#cRp&” but much longer.
  • There is absolutely no rendered output by the browser (no icons,
    text, tables, etc) other than the large string of random characters.
  • The request takes an unusually long amount of time to load.
  • I do not have the status code returned to the browser yet.
  • Nothing appears in the exception.log.

On Monday, November 2, 2015 at 1:27:04 PM UTC-7, AWDSOFT wrote:

Hi everyone,

I’ve been working on converting an application from ACF9 to Lucee 4 and
there is something very odd going on. Our testers are reporting that every
so often they receive page output that is just a bunch of mangled/garbage
characters. I have seen it myself once or twice (out of hundreds of
requests) so I know it’s not a false report; just rare. Reloading the page
will result in the correct output. I’m going to be collecting more
information as I can but any direction or ideas on where to even begin
would be very much appreciated!

A little info about our environment:

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/6a13bfb5-b732-4a75-bb82-3c0c0771ea22%40googlegroups.com
https://groups.google.com/d/msgid/lucee/6a13bfb5-b732-4a75-bb82-3c0c0771ea22%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

5

Could it be that those pages are encrypted in acf?.

GertSent from somewhere on the road

Am 02.11.2015 um 19:03 schrieb AWDSOFT <@AWDSOFT>:

Thanks for the reply Mike!

In this case, I don’t think that would be the issue since the page is a “standard” CFML page with a mixture of HTML elements and CFML markup. Also, reloading the page will show the correct content which I would expect not to be the case if it were a database content encoding issue. Good idea though!

On Monday, November 2, 2015 at 3:06:04 PM UTC-7, Michael Sprague wrote:
If the data for the garbled pages is coming from a database it could be an issue with the character encoding settings. I’ve seen similar issues when the data in the database is stored with a different charset than the original source of the data. Hope that helps.

Mike

On Mon, Nov 2, 2015 at 4:57 PM, AWDSOFT awd...@gmail.com wrote:
Hi Jordan,

Thanks for your reply!

To answer your question; no, we aren’t using any custom fonts in this application. Let me try to elaborate on some details about the request (hopefully I can actually post an example of the output soon).
I mean to say that the “output” of the page is garbled/mangled. The characters appearing in the output are plainly text but have no meaning. Think something like “Q9%h!2JJ~0#cRp&” but much longer.
There is absolutely no rendered output by the browser (no icons, text, tables, etc) other than the large string of random characters.
The request takes an unusually long amount of time to load.
I do not have the status code returned to the browser yet.
Nothing appears in the exception.log.

On Monday, November 2, 2015 at 1:27:04 PM UTC-7, AWDSOFT wrote:
Hi everyone,

I’ve been working on converting an application from ACF9 to Lucee 4 and there is something very odd going on. Our testers are reporting that every so often they receive page output that is just a bunch of mangled/garbage characters. I have seen it myself once or twice (out of hundreds of requests) so I know it’s not a false report; just rare. Reloading the page will result in the correct output. I’m going to be collecting more information as I can but any direction or ideas on where to even begin would be very much appreciated!

A little info about our environment:
Lucee 4.5.1.024 / Apache Tomcat/8.0.24 / 1.8.0_45 (Oracle Corporation) 64bit
Windows Server 2008 R2
Using multi-instance installation following modified instruction from here: http://utdream.org/assets/content/files/railo_multi-instance-howto.pdf
Basically running full installer with custom ports and manual config of the BonCode IIS connector.

–
You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/6a13bfb5-b732-4a75-bb82-3c0c0771ea22%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/5d50371c-28b4-4f5d-a23c-df312633a849%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

6

Hi - what if what you see is binary stuff, that the gzip compression is not working as it should… ?

AWDSOFT wrote on 2015-11-02:> Hi Jordan,

Thanks for your reply!

To answer your question; no, we aren’t using any custom fonts in this
application. Let me try to elaborate on some details about the request
(hopefully I can actually post an example of the output soon).

  • I mean to say that the “output” of the page is garbled/mangled.
    The characters appearing in the output are plainly text but have no
    meaning. Think something like “Q9%h!2JJ~0#cRp&” but much longer.
  • There is absolutely no rendered output by the browser (no icons,
    text, tables, etc) other than the large string of random characters.
  • The request takes an unusually long amount of time to load.
  • I do not have the status code returned to the browser yet.
  • Nothing appears in the exception.log.

On Monday, November 2, 2015 at 1:27:04 PM UTC-7, AWDSOFT wrote:

Hi everyone,

I’ve been working on converting an application from ACF9 to
Lucee 4 and there is something very odd going on. Our testers are
reporting that every so often they receive page output that is just a
bunch of mangled/garbage characters. I have seen it myself once or twice
(out of hundreds of requests) so I know it’s not a false report; just
rare. Reloading the page will result in the correct output. I’m going to
be collecting more information as I can but any direction or ideas on
where to even begin would be very much appreciated!

A little info about our environment:

7

Thanks for the reply Mike!

In this case, I don’t think that would be the issue since the page is a
“standard” CFML page with a mixture of HTML elements and CFML markup. Also,
reloading the page will show the correct content which I would expect not
to be the case if it were a database content encoding issue. Good idea
though!On Monday, November 2, 2015 at 3:06:04 PM UTC-7, Michael Sprague wrote:

If the data for the garbled pages is coming from a database it could be an
issue with the character encoding settings. I’ve seen similar issues when
the data in the database is stored with a different charset than the
original source of the data. Hope that helps.

Mike

On Mon, Nov 2, 2015 at 4:57 PM, AWDSOFT <awd...@gmail.com <javascript:>> wrote:

Hi Jordan,

Thanks for your reply!

To answer your question; no, we aren’t using any custom fonts in this
application. Let me try to elaborate on some details about the request
(hopefully I can actually post an example of the output soon).

  • I mean to say that the “output” of the page is garbled/mangled. The
    characters appearing in the output are plainly text but have no meaning. Think
    something like “Q9%h!2JJ~0#cRp&” but much longer.
  • There is absolutely no rendered output by the browser (no icons,
    text, tables, etc) other than the large string of random characters.
  • The request takes an unusually long amount of time to load.
  • I do not have the status code returned to the browser yet.
  • Nothing appears in the exception.log.

On Monday, November 2, 2015 at 1:27:04 PM UTC-7, AWDSOFT wrote:

Hi everyone,

I’ve been working on converting an application from ACF9 to Lucee 4 and
there is something very odd going on. Our testers are reporting that every
so often they receive page output that is just a bunch of mangled/garbage
characters. I have seen it myself once or twice (out of hundreds of
requests) so I know it’s not a false report; just rare. Reloading the page
will result in the correct output. I’m going to be collecting more
information as I can but any direction or ideas on where to even begin
would be very much appreciated!

A little info about our environment:

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+un...@googlegroups.com <javascript:>.
To post to this group, send email to lu...@googlegroups.com <javascript:>
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/6a13bfb5-b732-4a75-bb82-3c0c0771ea22%40googlegroups.com
https://groups.google.com/d/msgid/lucee/6a13bfb5-b732-4a75-bb82-3c0c0771ea22%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

8

Hi Gert,

Thanks for your reply!

No, these pages are not ACF encrypted files. They aren’t special in any
way; just plain text “.cfm” files on the local file system which can be
opened in Notepad, etc.On Monday, November 2, 2015 at 5:20:41 PM UTC-7, Gert Franz wrote:

Could it be that those pages are encrypted in acf?.

Gert

Sent from somewhere on the road

Am 02.11.2015 um 19:03 schrieb AWDSOFT <awd...@gmail.com <javascript:>>:

Thanks for the reply Mike!

In this case, I don’t think that would be the issue since the page is a
“standard” CFML page with a mixture of HTML elements and CFML markup. Also,
reloading the page will show the correct content which I would expect not
to be the case if it were a database content encoding issue. Good idea
though!

On Monday, November 2, 2015 at 3:06:04 PM UTC-7, Michael Sprague wrote:

If the data for the garbled pages is coming from a database it could be
an issue with the character encoding settings. I’ve seen similar issues
when the data in the database is stored with a different charset than the
original source of the data. Hope that helps.

Mike

On Mon, Nov 2, 2015 at 4:57 PM, AWDSOFT awd...@gmail.com wrote:

Hi Jordan,

Thanks for your reply!

To answer your question; no, we aren’t using any custom fonts in this
application. Let me try to elaborate on some details about the request
(hopefully I can actually post an example of the output soon).

  • I mean to say that the “output” of the page is garbled/mangled.
    The characters appearing in the output are plainly text but have no
    meaning. Think something like “Q9%h!2JJ~0#cRp&” but much longer.
  • There is absolutely no rendered output by the browser (no icons,
    text, tables, etc) other than the large string of random characters.
  • The request takes an unusually long amount of time to load.
  • I do not have the status code returned to the browser yet.
  • Nothing appears in the exception.log.

On Monday, November 2, 2015 at 1:27:04 PM UTC-7, AWDSOFT wrote:

Hi everyone,

I’ve been working on converting an application from ACF9 to Lucee 4 and
there is something very odd going on. Our testers are reporting that every
so often they receive page output that is just a bunch of mangled/garbage
characters. I have seen it myself once or twice (out of hundreds of
requests) so I know it’s not a false report; just rare. Reloading the page
will result in the correct output. I’m going to be collecting more
information as I can but any direction or ideas on where to even begin
would be very much appreciated!

A little info about our environment:

–
You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/6a13bfb5-b732-4a75-bb82-3c0c0771ea22%40googlegroups.com
https://groups.google.com/d/msgid/lucee/6a13bfb5-b732-4a75-bb82-3c0c0771ea22%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+un...@googlegroups.com <javascript:>.
To post to this group, send email to lu...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/5d50371c-28b4-4f5d-a23c-df312633a849%40googlegroups.com
https://groups.google.com/d/msgid/lucee/5d50371c-28b4-4f5d-a23c-df312633a849%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

9

Hi Hugo,

That’s an interesting idea… I noticed in the Lucee admin there is a
setting for GZIP compression which I thought was interesting since I’m sure
our IIS is already setup to use GZIP. How does that work if both are set to
use GZIP? Maybe my issue is “double-zip” (but only rarely)?On Tuesday, November 3, 2015 at 12:17:41 AM UTC-7, Hugo Ahlenius wrote:

Hi - what if what you see is binary stuff, that the gzip compression is
not working as it should… ?

AWDSOFT wrote on 2015-11-02:

Hi Jordan,

Thanks for your reply!

To answer your question; no, we aren’t using any custom fonts in this
application. Let me try to elaborate on some details about the request
(hopefully I can actually post an example of the output soon).

  •    I mean to say that the "output" of the page is garbled/mangled.

The characters appearing in the output are plainly text but have no
meaning. Think something like “Q9%h!2JJ~0#cRp&” but much longer.

  •    There is absolutely no rendered output by the browser (no

icons,

text, tables, etc) other than the large string of random characters.

  •    The request takes an unusually long amount of time to load. 

  •    I do not have the status code returned to the browser yet. 

  •    Nothing appears in the exception.log.

On Monday, November 2, 2015 at 1:27:04 PM UTC-7, AWDSOFT wrote:

    Hi everyone, 

    I've been working on converting an application from ACF9 to

Lucee 4 and there is something very odd going on. Our testers are
reporting that every so often they receive page output that is just a
bunch of mangled/garbage characters. I have seen it myself once or twice
(out of hundreds of requests) so I know it’s not a false report; just
rare. Reloading the page will result in the correct output. I’m going to
be collecting more information as I can but any direction or ideas on
where to even begin would be very much appreciated!

    A little info about our environment: 

    *        Lucee 4.5.1.024 / Apache Tomcat/8.0.24 / 1.8.0_45

(Oracle

Corporation) 64bit * Windows Server 2008 R2
* Using multi-instance
installation following modified instruction from here:
http://utdream.org/assets/content/files/railo_multi-instance-howto.pdf
http://utdream.org/assets/content/files/railo_multi-instance-howto.pdf

  •    Basically running full installer with custom ports and manual

config

of the BonCode IIS connector.

10

Aliens intercepting the web request trying to communicate with you (or your
users)? :wink:

Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamediaOn Tue, Nov 3, 2015 at 8:16 AM, Hugo Ahlenius <@Hugo_Ahlenius> wrote:

Hi - what if what you see is binary stuff, that the gzip compression is
not working as it should… ?

AWDSOFT wrote on 2015-11-02:

Hi Jordan,

Thanks for your reply!

To answer your question; no, we aren’t using any custom fonts in this
application. Let me try to elaborate on some details about the request
(hopefully I can actually post an example of the output soon).

  • I mean to say that the "output" of the page is garbled/mangled.

The characters appearing in the output are plainly text but have no
meaning. Think something like “Q9%h!2JJ~0#cRp&” but much longer.

  • There is absolutely no rendered output by the browser (no icons,

text, tables, etc) other than the large string of random characters.

  • The request takes an unusually long amount of time to load.

  • I do not have the status code returned to the browser yet.

  • Nothing appears in the exception.log.

On Monday, November 2, 2015 at 1:27:04 PM UTC-7, AWDSOFT wrote:

  Hi everyone,

  I've been working on converting an application from ACF9 to

Lucee 4 and there is something very odd going on. Our testers are
reporting that every so often they receive page output that is just a
bunch of mangled/garbage characters. I have seen it myself once or twice
(out of hundreds of requests) so I know it’s not a false report; just
rare. Reloading the page will result in the correct output. I’m going to
be collecting more information as I can but any direction or ideas on
where to even begin would be very much appreciated!

  A little info about our environment:

  *       Lucee 4.5.1.024 / Apache Tomcat/8.0.24 / 1.8.0_45 (Oracle

Corporation) 64bit * Windows Server 2008 R2 * Using
multi-instance
installation following modified instruction from here:
http://utdream.org/assets/content/files/railo_multi-instance-howto.pdf
http://utdream.org/assets/content/files/railo_multi-instance-howto.pdf

  • Basically running full installer with custom ports and manual

config

of the BonCode IIS connector.

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/017001d11607%249512e280%24bf38a780%24%40oxel.net
.
For more options, visit https://groups.google.com/d/optout.

11

AWDSOFT wrote on 2015-11-03:

That’s an interesting idea… I noticed in the Lucee admin there is a
setting for GZIP compression which I thought was interesting since I’m
sure our IIS is already setup to use GZIP. How does that work if both
are set to use GZIP? Maybe my issue is “double-zip” (but only rarely)?

If this is gzip-related: More likely is that the headers get bungled or the connection gets interrupted.> On Tuesday, November 3, 2015 at 12:17:41 AM UTC-7, Hugo Ahlenius wrote:

Hi - what if what you see is binary stuff, that the gzip
compression is not working as it should… ?

AWDSOFT wrote on 2015-11-02: > Hi Jordan, > > Thanks for your reply!

To answer your question; no, we aren’t using any custom fonts in
this > application. Let me try to elaborate on some details about the
request > (hopefully I can actually post an example of the output soon).

  •    I mean to say that the "output" of the page is

garbled/mangled. > The characters appearing in the output are plainly
text but have no > meaning. Think something like “Q9%h!2JJ~0#cRp&” but
much longer. > * There is absolutely no rendered output by the
browser (no icons, > text, tables, etc) other than the large string of
random characters. > * The request takes an unusually long
amount of time to load. > * I do not have the status code
returned to the browser yet. > * Nothing appears in the
exception.log. > > > On Monday, November 2, 2015 at 1:27:04 PM UTC-7,
AWDSOFT wrote: > > Hi everyone, > > I’ve been
working on converting an application from ACF9 to > Lucee 4 and there
is something very odd going on. Our testers are > reporting that every
so often they receive page output that is just a > bunch of
mangled/garbage characters. I have seen it myself once or twice > (out
of hundreds of requests) so I know it’s not a false report; just >
rare. Reloading the page will result in the correct output. I’m going to

be collecting more information as I can but any direction or ideas on
where to even begin would be very much appreciated! > > A
little info about our environment: > > * Lucee
4.5.1.024 / Apache Tomcat/8.0.24 / 1.8.0_45 (Oracle > Corporation)
64bit * Windows Server 2008 R2 * Using
multi-instance > installation following modified instruction from here:

http://utdream.org/assets/content/files/railo_multi-instance-howto.pdf
http://utdream.org/assets/content/files/railo_multi-instance-howto.pdf

<http://utdream.org/assets/content/files/railo_multi-instance-howto.pdf
http://utdream.org/assets/content/files/railo_multi-instance-howto.pdf

  •    Basically running full installer with custom ports

and manual config

of the BonCode IIS connector.

12

Update time! This continues to happen rarely but I did finally get a sample
of the output and a little more information. Since the original post we
have updated to 4.5.2.018. Here is an example of the output by the browser
(there are hundreds of lines, this is just some of the first):

‹½YmSÛHþýŠA—ZÙ‰,Y†0˜”±Í†Tx)0›»¢R[ƒ4¶adɍ0.–ÿ¾Ý3’-Ù†lî’ •

M÷ôû<Ý£ìotÏ:ýÿœ÷ÈHŽCr~uøù¸CÌšë~Ùì¸n·ß%ÿþØ?ùL<§Nú‚F —<Žh躽S“˜#)'MםN§ÎtÓ‰ÅÐí_¸(ËÃÍÙcMv:
Ìc_)|‡

This time, I also received an error for the the request in our logs. Here
is the stack trace:

java.lang.ThreadDeath at java.lang.Thread.stop(Thread.java:850):850 at
lucee.commons.io.StopThread.run(SystemUtil.java:1091):1091 at
lucee.runtime.exp.NativeException.(NativeException.java:51):51 at
lucee.runtime.op.Caster.toPageException(Caster.java:3046):3046 at
lucee.runtime.type.UDFImpl._call(UDFImpl.java:338):338 at
lucee.runtime.type.UDFImpl.call(UDFImpl.java:229):229 at
lucee.runtime.ComponentImpl._call(ComponentImpl.java:642):642 at
lucee.runtime.ComponentImpl._call(ComponentImpl.java:524):524 at
lucee.runtime.ComponentImpl.call(ComponentImpl.java:1761):1761 at
lucee.runtime.util.VariableUtilImpl.callFunctionWithoutNamedValues(
VariableUtilImpl.java:742):742 at
lucee.runtime.PageContextImpl.getFunction(PageContextImpl.java:1590):1590
at
{subFolder}.{myFile}_cfm$cf.call(D:\Webs{myFile}.cfm:495):495 at
lucee.runtime.PageContextImpl.doInclude(PageContextImpl.java:951):951 at
lucee.runtime.PageContextImpl.doInclude(PageContextImpl.java:903):903 at
lucee.runtime.listener.ModernAppListener._onRequest(ModernAppListener.java:
223):223 at
lucee.runtime.listener.MixedAppListener.onRequest(MixedAppListener.java:35):
35 at
lucee.runtime.PageContextImpl.execute(PageContextImpl.java:2262):2262 at
lucee.runtime.PageContextImpl.execute(PageContextImpl.java:2225):2225 at
lucee.runtime.engine.CFMLEngineImpl.serviceCFML(CFMLEngineImpl.java:456):456
at
lucee.loader.servlet.CFMLServlet.service(CFMLServlet.java:47):47 at
javax.servlet.http.HttpServlet.service(HttpServlet.java:729):729 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:291):291 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:206):206 at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52):52
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:239):239 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:206):206 at
sun.reflect.GeneratedMethodAccessor200.invoke(Unknown Source):-1 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:43):43 at
java.lang.reflect.Method.invoke(Method.java:497):497 at
com.intergral.fusionreactor.j2ee.filterchain.WrappedFilterChain.doFilter(
WrappedFilterChain.java:97):97 at
com.intergral.fusionreactor.j2ee.filter.FusionReactorRequestHandler.doNext(
FusionReactorRequestHandler.java:472):472 at
com.intergral.fusionreactor.j2ee.filter.FusionReactorRequestHandler.
doHttpServletRequest(FusionReactorRequestHandler.java:312):312 at
com.intergral.fusionreactor.j2ee.filter.FusionReactorRequestHandler.
doFusionRequest(FusionReactorRequestHandler.java:192):192 at
com.intergral.fusionreactor.j2ee.filter.FusionReactorRequestHandler.handle(
FusionReactorRequestHandler.java:507):507 at
com.intergral.fusionreactor.j2ee.filter.FusionReactorCoreFilter.doFilter(
FusionReactorCoreFilter.java:36):36 at
sun.reflect.GeneratedMethodAccessor199.invoke(Unknown Source):-1 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:43):43 at
java.lang.reflect.Method.invoke(Method.java:497):497 at
com.intergral.fusionreactor.j2ee.filterchain.WrappedFilterChain.doFilter(
WrappedFilterChain.java:79):79 at
sun.reflect.GeneratedMethodAccessor198.invoke(Unknown Source):-1 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:43):43 at
java.lang.reflect.Method.invoke(Method.java:497):497 at
com.intergral.fusionreactor.agent.filter.FusionReactorStaticFilter.doFilter(
FusionReactorStaticFilter.java:53):53 at
com.intergral.fusionreactor.agent.pointcuts.NewFilterChainPointCut$1.invoke(
NewFilterChainPointCut.java:41):41 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java):-1 at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.
java:219):219 at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.
java:106):106 at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase
.java:502):502 at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142
):142 at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79
):79 at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:88):88 at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:518):
518 at
org.apache.coyote.ajp.AbstractAjpProcessor.process(AbstractAjpProcessor.java
:844):844 at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(
AbstractProtocol.java:668):668 at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.
java:1527):1527 at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:
1484):1484 at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:
1142):1142 at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:
617):617 at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.
java:61):61 at
java.lang.Thread.run(Thread.java:745):745On Monday, November 2, 2015 at 1:27:04 PM UTC-7, AWDSOFT wrote:

Hi everyone,

I’ve been working on converting an application from ACF9 to Lucee 4 and
there is something very odd going on. Our testers are reporting that every
so often they receive page output that is just a bunch of mangled/garbage
characters. I have seen it myself once or twice (out of hundreds of
requests) so I know it’s not a false report; just rare. Reloading the page
will result in the correct output. I’m going to be collecting more
information as I can but any direction or ideas on where to even begin
would be very much appreciated!

A little info about our environment:

13

Hi Paul,

Thanks for your reply!

I’m not sure I could live without FusionReactor; it’s such a great tool for
debugging/monitoring. Since this issue crops up so rarely I have not been
able to view the request in FR as it happens (or even in the history since
we commonly have 30+ requests per second). We have a separate error logging
system and that’s how I was able to provide the stack trace. I don’t
actually have FR setup to use “WebRequest Runtime Protection” so there
shouldn’t be any killing (by FR anyway) going on.

Good idea looking at the Tomcat logs for this most recent case; might turn
up something interesting there.

The line in that file is using cfsavecontent to build a potentially large
string of CSV data. It is frequently used though and does not consistently
fail in this way.

Do you suppose that this issue could simply be timeouts that sometimes bomb
out with binary dumps? Our error handling is supposed to display a nice
error page but in these cases it’s not happening.On Thursday, November 19, 2015 at 3:07:19 AM UTC-7, Paul Klinkenberg wrote:

… I did not read the full email thread before replying. Sorry 'bout that.
I see you wrote “The request takes an unusually long amount of time to
load.” That kind of indicates a timeout caused the problem. Please check
the Fusionreactor settings for request timeout handling; it probably says
“abort on timeout”.
If that is the case, you could change it to “warn by email”, to allow for
debugging.

As to why it took so long, Fusionreactor is probably your friend again.

Kind regards,

Paul Klinkenberg

Op 19 nov. 2015, om 10:44 heeft Paul Klinkenberg < pa…@ongevraagdadvies.nl <javascript:>> het volgende geschreven:

Hi there,

I see in the ST you are using Fusionreactor. Good choice :slight_smile:
What does fusionreactor say about these requests?

Also, can you post the line D:\Webs{myFile}.cfm:495 and surrounding code?

The junk characters are probably partial binary data. What was the page in
question supposed to output? a pdf file? Image?

Also, you might want to check the Tomcat error logs; they might give you
an idea to what’s going on.

Kind regards,

Paul Klinkenberg

Op 18 nov. 2015, om 18:37 heeft AWDSOFT <awd...@gmail.com <javascript:>> het volgende geschreven:

Update time! This continues to happen rarely but I did finally get a
sample of the output and a little more information. Since the original post
we have updated to 4.5.2.018. Here is an example of the output by the
browser (there are hundreds of lines, this is just some of the first):

‹ ½YmSÛH þ ýŠA—ZÙ‰,Y† 0˜”±Í†Tx)0›»¢R[ƒ4¶ dÉ 0.–ÿ¾Ý3’-Ù†lî’ •
M÷ôû<Ý£ìotÏ:ýÿœ÷ÈHŽCr~uøù¸CÌšë~Ùì¸n·ß%ÿþØ?ùL<§Nú‚F —<Žh躽S“˜#)'M×
N§ÎtÓ‰ÅÐí_¸ (ËÃÍÙcM v: Ì c_)| ‡

This time, I also received an error for the the request in our logs. Here
is the stack trace:

java.lang.ThreadDeath at java.lang.Thread.stop(Thread.java:850):850 at
lucee.commons.io.StopThread.run(SystemUtil.java:1091):1091 at
lucee.runtime.exp.NativeException.(NativeException.java:51):51 at
lucee.runtime.op.Caster.toPageException(Caster.java:3046):3046 at
lucee.runtime.type.UDFImpl._call(UDFImpl.java:338):338 at
lucee.runtime.type.UDFImpl.call(UDFImpl.java:229):229 at
lucee.runtime.ComponentImpl._call(ComponentImpl.java:642):642 at
lucee.runtime.ComponentImpl._call(ComponentImpl.java:524):524 at
lucee.runtime.ComponentImpl.call(ComponentImpl.java:1761):1761 at
lucee.runtime.util.VariableUtilImpl.callFunctionWithoutNamedValues(
VariableUtilImpl.java:742):742 at
lucee.runtime.PageContextImpl.getFunction(PageContextImpl.java:1590):1590
at
{subFolder}.{myFile}_cfm$cf.call(D:\Webs{myFile}.cfm:495):495 at
lucee.runtime.PageContextImpl.doInclude(PageContextImpl.java:951):951 at
lucee.runtime.PageContextImpl.doInclude(PageContextImpl.java:903):903 at
lucee.runtime.listener.ModernAppListener._onRequest(ModernAppListener.java
:223):223 at
lucee.runtime.listener.MixedAppListener.onRequest(MixedAppListener.java:35
):35 at
lucee.runtime.PageContextImpl.execute(PageContextImpl.java:2262):2262 at
lucee.runtime.PageContextImpl.execute(PageContextImpl.java:2225):2225 at
lucee.runtime.engine.CFMLEngineImpl.serviceCFML(CFMLEngineImpl.java:456):
456 at
lucee.loader.servlet.CFMLServlet.service(CFMLServlet.java:47):47 at
javax.servlet.http.HttpServlet.service(HttpServlet.java:729):729 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:291):291 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:206):206 at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52):52
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:239):239 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:206):206 at
sun.reflect.GeneratedMethodAccessor200.invoke(Unknown Source):-1 at
…

14

… I did not read the full email thread before replying. Sorry 'bout that.
I see you wrote “The request takes an unusually long amount of time to load.” That kind of indicates a timeout caused the problem. Please check the Fusionreactor settings for request timeout handling; it probably says “abort on timeout”.
If that is the case, you could change it to “warn by email”, to allow for debugging.

As to why it took so long, Fusionreactor is probably your friend again.

Kind regards,

Paul KlinkenbergOp 19 nov. 2015, om 10:44 heeft Paul Klinkenberg <@Paul_Klinkenberg> het volgende geschreven:

Hi there,

I see in the ST you are using Fusionreactor. Good choice :slight_smile:
What does fusionreactor say about these requests?

Also, can you post the line D:\Webs{myFile}.cfm:495 and surrounding code?

The junk characters are probably partial binary data. What was the page in question supposed to output? a pdf file? Image?

Also, you might want to check the Tomcat error logs; they might give you an idea to what’s going on.

Kind regards,

Paul Klinkenberg

Op 18 nov. 2015, om 18:37 heeft AWDSOFT <@AWDSOFT mailto:AWDSOFT> het volgende geschreven:

Update time! This continues to happen rarely but I did finally get a sample of the output and a little more information. Since the original post we have updated to 4.5.2.018. Here is an example of the output by the browser (there are hundreds of lines, this is just some of the first):

‹ ½YmSÛH þ ýŠA—ZÙ‰,Y† 0˜”±Í†Tx)0›»¢R[ƒ4¶ dÉ 0.–ÿ¾Ý3’-Ù†lî’ • M÷ôû<Ý£ìotÏ:ýÿœ÷ÈHŽCr~uøù¸CÌšë~Ùì¸n·ß%ÿþØ?ùL<§Nú‚F —<Žh躽S“˜#)'M× N§ÎtÓ‰ÅÐí_¸ (ËÃÍÙcM v: Ì c_)| ‡

This time, I also received an error for the the request in our logs. Here is the stack trace:

java.lang.ThreadDeath at java.lang.Thread.stop(Thread.java:850):850 at
lucee.commons.io.StopThread.run(SystemUtil.java:1091):1091 at
lucee.runtime.exp.NativeException.(NativeException.java:51):51 at
lucee.runtime.op.Caster.toPageException(Caster.java:3046):3046 at
lucee.runtime.type.UDFImpl._call(UDFImpl.java:338):338 at
lucee.runtime.type.UDFImpl.call(UDFImpl.java:229):229 at
lucee.runtime.ComponentImpl._call(ComponentImpl.java:642):642 at
lucee.runtime.ComponentImpl._call(ComponentImpl.java:524):524 at
lucee.runtime.ComponentImpl.call(ComponentImpl.java:1761):1761 at
lucee.runtime.util.VariableUtilImpl.callFunctionWithoutNamedValues(VariableUtilImpl.java:742):742 at
lucee.runtime.PageContextImpl.getFunction(PageContextImpl.java:1590):1590 at
{subFolder}.{myFile}_cfm$cf.call(D:\Webs{myFile}.cfm:495):495 at
lucee.runtime.PageContextImpl.doInclude(PageContextImpl.java:951):951 at lucee.runtime.PageContextImpl.doInclude(PageContextImpl.java:903):903 at
lucee.runtime.listener.ModernAppListener._onRequest(ModernAppListener.java:223):223 at
lucee.runtime.listener.MixedAppListener.onRequest(MixedAppListener.java:35):35 at
lucee.runtime.PageContextImpl.execute(PageContextImpl.java:2262):2262 at
lucee.runtime.PageContextImpl.execute(PageContextImpl.java:2225):2225 at
lucee.runtime.engine.CFMLEngineImpl.serviceCFML(CFMLEngineImpl.java:456):456 at
lucee.loader.servlet.CFMLServlet.service(CFMLServlet.java:47):47 at
javax.servlet.http.HttpServlet.service(HttpServlet.java:729):729 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291):291 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206):206 at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52):52 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239):239 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206):206 at
sun.reflect.GeneratedMethodAccessor200.invoke(Unknown Source):-1 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43):43 at
java.lang.reflect.Method.invoke(Method.java:497):497 at
com.intergral.fusionreactor.j2ee.filterchain.WrappedFilterChain.doFilter(WrappedFilterChain.java:97):97 at
com.intergral.fusionreactor.j2ee.filter.FusionReactorRequestHandler.doNext(FusionReactorRequestHandler.java:472):472 at
com.intergral.fusionreactor.j2ee.filter.FusionReactorRequestHandler.doHttpServletRequest(FusionReactorRequestHandler.java:312):312 at
com.intergral.fusionreactor.j2ee.filter.FusionReactorRequestHandler.doFusionRequest(FusionReactorRequestHandler.java:192):192 at
com.intergral.fusionreactor.j2ee.filter.FusionReactorRequestHandler.handle(FusionReactorRequestHandler.java:507):507 at
com.intergral.fusionreactor.j2ee.filter.FusionReactorCoreFilter.doFilter(FusionReactorCoreFilter.java:36):36 at
sun.reflect.GeneratedMethodAccessor199.invoke(Unknown Source):-1 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43):43 at
java.lang.reflect.Method.invoke(Method.java:497):497 at
com.intergral.fusionreactor.j2ee.filterchain.WrappedFilterChain.doFilter(WrappedFilterChain.java:79):79 at
sun.reflect.GeneratedMethodAccessor198.invoke(Unknown Source):-1 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43):43 at
java.lang.reflect.Method.invoke(Method.java:497):497 at
com.intergral.fusionreactor.agent.filter.FusionReactorStaticFilter.doFilter(FusionReactorStaticFilter.java:53):53 at
com.intergral.fusionreactor.agent.pointcuts.NewFilterChainPointCut$1.invoke(NewFilterChainPointCut.java:41):41 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java):-1 at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219):219 at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106):106 at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502):502 at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142):142 at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79):79 at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88):88 at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:518):518 at
org.apache.coyote.ajp.AbstractAjpProcessor.process(AbstractAjpProcessor.java:844):844 at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:668):668at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1527):1527 at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1484):1484 at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142):1142 at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617):617 at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61):61 at
java.lang.Thread.run(Thread.java:745):745

On Monday, November 2, 2015 at 1:27:04 PM UTC-7, AWDSOFT wrote:
Hi everyone,

I’ve been working on converting an application from ACF9 to Lucee 4 and there is something very odd going on. Our testers are reporting that every so often they receive page output that is just a bunch of mangled/garbage characters. I have seen it myself once or twice (out of hundreds of requests) so I know it’s not a false report; just rare. Reloading the page will result in the correct output. I’m going to be collecting more information as I can but any direction or ideas on where to even begin would be very much appreciated!

A little info about our environment:
Lucee 4.5.1.024 / Apache Tomcat/8.0.24 / 1.8.0_45 (Oracle Corporation) 64bit
Windows Server 2008 R2
Using multi-instance installation following modified instruction from here: http://utdream.org/assets/content/files/railo_multi-instance-howto.pdf http://utdream.org/assets/content/files/railo_multi-instance-howto.pdf
Basically running full installer with custom ports and manual config of the BonCode IIS connector.

–
Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html http://lucee.org/supporters/become-a-supporter.html

You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com mailto:lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/35138272-252b-49f3-aa1c-23177f86a040%40googlegroups.com https://groups.google.com/d/msgid/lucee/35138272-252b-49f3-aa1c-23177f86a040%40googlegroups.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.

15

Hi there,

I see in the ST you are using Fusionreactor. Good choice :slight_smile:
What does fusionreactor say about these requests?

Also, can you post the line D:\Webs{myFile}.cfm:495 and surrounding code?

The junk characters are probably partial binary data. What was the page in question supposed to output? a pdf file? Image?

Also, you might want to check the Tomcat error logs; they might give you an idea to what’s going on.

Kind regards,

Paul KlinkenbergOp 18 nov. 2015, om 18:37 heeft AWDSOFT <@AWDSOFT> het volgende geschreven:

Update time! This continues to happen rarely but I did finally get a sample of the output and a little more information. Since the original post we have updated to 4.5.2.018. Here is an example of the output by the browser (there are hundreds of lines, this is just some of the first):

‹ ½YmSÛH þ ýŠA—ZÙ‰,Y† 0˜”±Í†Tx)0›»¢R[ƒ4¶ dÉ 0.–ÿ¾Ý3’-Ù†lî’ • M÷ôû<Ý£ìotÏ:ýÿœ÷ÈHŽCr~uøù¸CÌšë~Ùì¸n·ß%ÿþØ?ùL<§Nú‚F —<Žh躽S“˜#)'M× N§ÎtÓ‰ÅÐí_¸ (ËÃÍÙcM v: Ì c_)| ‡

This time, I also received an error for the the request in our logs. Here is the stack trace:

java.lang.ThreadDeath at java.lang.Thread.stop(Thread.java:850):850 at
lucee.commons.io.StopThread.run(SystemUtil.java:1091):1091 at
lucee.runtime.exp.NativeException.(NativeException.java:51):51 at
lucee.runtime.op.Caster.toPageException(Caster.java:3046):3046 at
lucee.runtime.type.UDFImpl._call(UDFImpl.java:338):338 at
lucee.runtime.type.UDFImpl.call(UDFImpl.java:229):229 at
lucee.runtime.ComponentImpl._call(ComponentImpl.java:642):642 at
lucee.runtime.ComponentImpl._call(ComponentImpl.java:524):524 at
lucee.runtime.ComponentImpl.call(ComponentImpl.java:1761):1761 at
lucee.runtime.util.VariableUtilImpl.callFunctionWithoutNamedValues(VariableUtilImpl.java:742):742 at
lucee.runtime.PageContextImpl.getFunction(PageContextImpl.java:1590):1590 at
{subFolder}.{myFile}_cfm$cf.call(D:\Webs{myFile}.cfm:495):495 at
lucee.runtime.PageContextImpl.doInclude(PageContextImpl.java:951):951 at lucee.runtime.PageContextImpl.doInclude(PageContextImpl.java:903):903 at
lucee.runtime.listener.ModernAppListener._onRequest(ModernAppListener.java:223):223 at
lucee.runtime.listener.MixedAppListener.onRequest(MixedAppListener.java:35):35 at
lucee.runtime.PageContextImpl.execute(PageContextImpl.java:2262):2262 at
lucee.runtime.PageContextImpl.execute(PageContextImpl.java:2225):2225 at
lucee.runtime.engine.CFMLEngineImpl.serviceCFML(CFMLEngineImpl.java:456):456 at
lucee.loader.servlet.CFMLServlet.service(CFMLServlet.java:47):47 at
javax.servlet.http.HttpServlet.service(HttpServlet.java:729):729 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291):291 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206):206 at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52):52 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239):239 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206):206 at
sun.reflect.GeneratedMethodAccessor200.invoke(Unknown Source):-1 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43):43 at
java.lang.reflect.Method.invoke(Method.java:497):497 at
com.intergral.fusionreactor.j2ee.filterchain.WrappedFilterChain.doFilter(WrappedFilterChain.java:97):97 at
com.intergral.fusionreactor.j2ee.filter.FusionReactorRequestHandler.doNext(FusionReactorRequestHandler.java:472):472 at
com.intergral.fusionreactor.j2ee.filter.FusionReactorRequestHandler.doHttpServletRequest(FusionReactorRequestHandler.java:312):312 at
com.intergral.fusionreactor.j2ee.filter.FusionReactorRequestHandler.doFusionRequest(FusionReactorRequestHandler.java:192):192 at
com.intergral.fusionreactor.j2ee.filter.FusionReactorRequestHandler.handle(FusionReactorRequestHandler.java:507):507 at
com.intergral.fusionreactor.j2ee.filter.FusionReactorCoreFilter.doFilter(FusionReactorCoreFilter.java:36):36 at
sun.reflect.GeneratedMethodAccessor199.invoke(Unknown Source):-1 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43):43 at
java.lang.reflect.Method.invoke(Method.java:497):497 at
com.intergral.fusionreactor.j2ee.filterchain.WrappedFilterChain.doFilter(WrappedFilterChain.java:79):79 at
sun.reflect.GeneratedMethodAccessor198.invoke(Unknown Source):-1 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43):43 at
java.lang.reflect.Method.invoke(Method.java:497):497 at
com.intergral.fusionreactor.agent.filter.FusionReactorStaticFilter.doFilter(FusionReactorStaticFilter.java:53):53 at
com.intergral.fusionreactor.agent.pointcuts.NewFilterChainPointCut$1.invoke(NewFilterChainPointCut.java:41):41 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java):-1 at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219):219 at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106):106 at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502):502 at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142):142 at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79):79 at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88):88 at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:518):518 at
org.apache.coyote.ajp.AbstractAjpProcessor.process(AbstractAjpProcessor.java:844):844 at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:668):668at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1527):1527 at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1484):1484 at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142):1142 at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617):617 at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61):61 at
java.lang.Thread.run(Thread.java:745):745

On Monday, November 2, 2015 at 1:27:04 PM UTC-7, AWDSOFT wrote:
Hi everyone,

I’ve been working on converting an application from ACF9 to Lucee 4 and there is something very odd going on. Our testers are reporting that every so often they receive page output that is just a bunch of mangled/garbage characters. I have seen it myself once or twice (out of hundreds of requests) so I know it’s not a false report; just rare. Reloading the page will result in the correct output. I’m going to be collecting more information as I can but any direction or ideas on where to even begin would be very much appreciated!

A little info about our environment:
Lucee 4.5.1.024 / Apache Tomcat/8.0.24 / 1.8.0_45 (Oracle Corporation) 64bit
Windows Server 2008 R2
Using multi-instance installation following modified instruction from here: http://utdream.org/assets/content/files/railo_multi-instance-howto.pdf http://utdream.org/assets/content/files/railo_multi-instance-howto.pdf
Basically running full installer with custom ports and manual config of the BonCode IIS connector.

–
Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html http://lucee.org/supporters/become-a-supporter.html

You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com mailto:lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/35138272-252b-49f3-aa1c-23177f86a040%40googlegroups.com https://groups.google.com/d/msgid/lucee/35138272-252b-49f3-aa1c-23177f86a040%40googlegroups.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.