RE: [Tapestry 4.1] UTFDataFormatException in RequestCycle.encodeIdState
In digging into the source of ObjectOutputStream, (1.6.0_11) this appears to be the best option anyway - if writeUnshared() is called with a String, it eventually calls a method writeString() that does the UTF length check and calls a special "writeLongUTF()" method on the backing BlockDataOutputStream. This gets the same performance benefit without the length limitation, or any special handling in the calling code. Just confirming Aaron's fix wouldn't cause any performance hit, or even necessarily the rendered result, except in extreme cases like this where the UTF8 string header in the output stream is 8 bytes instead of 2. ...it turned out to be much simpler for us to replace the calls to objectOutputStream.writeUTF() with calls to objectOutputStream.writeUnshared(). In case anyone else runs into this, the following approach is working well for us. We had to create our own RequestCycleFactoryImpl, RequestCycle and CompressedDataEncoder classes to plumb in the writeUTF -> writeUnshared change. That was done by adding a block to hivemodule.xml to replace the implementation of service-id="tapestry.request.RequestCycleFactory". We were worried about a performance hit with the change but it seems to be at least as fast for us. ... -- View this message in context: http://www.nabble.com/-Tapestry-4.1--UTFDataFormatException-in-RequestCycle.encodeIdState-tp24314990p24990567.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Tapestry 4.1] UTFDataFormatException in RequestCycle.encodeIdState
Glad you're OK. I would still suggest doing some of the changes I
suggested. Or upgrade to T5.1 :-)
On Mon, Jul 6, 2009 at 2:46 PM, Aaron
Kaminsky wrote:
> Hi Howard,
>
> Thanks for the suggestion. In our case we may have been able to get by with
> the workaround you suggested, but it turned out to be much simpler for us to
> replace the calls to objectOutputStream.writeUTF() with calls to
> objectOutputStream.writeUnshared().
>
> In case anyone else runs into this, the following approach is working well
> for us.
>
> We had to create our own RequestCycleFactoryImpl, RequestCycle and
> CompressedDataEncoder classes to plumb in the writeUTF -> writeUnshared
> change. That was done by adding a block to hivemodule.xml to replace the
> implementation of service-id="tapestry.request.RequestCycleFactory". We were
> worried about a performance hit with the change but it seems to be at least
> as fast for us. This approach also removes any possibility of running into
> this limitation in the future.
>
> Regards,
> Aaron
>
>
> -Original Message-
> From: Howard Lewis Ship [mailto:hls...@gmail.com]
> Sent: Thursday, July 02, 2009 4:27 PM
> To: Tapestry users
> Subject: Re: [Tapestry 4.1] UTFDataFormatException in
> RequestCycle.encodeIdState
>
> That's an unexpected limitation!
> In exceptional cases, you can revert to simpler methods; for instance, using
> a simple rather than a TextField component, and handling
> that part of the submission inside your listener method much like a
> traditional servlet.
>
> As a stop-gap, you should give explicit jwcids to ALL of your components, as
> use shorter names ... this will buy you a lot (if you see the repetition in
> the generated element ids string at the root of your problem). This may be a
> time to use less intuitive names (i.e., use abbreviations!).
>
> On Thu, Jul 2, 2009 at 3:31 PM, Aaron Kaminsky
> wrote:
>
>> Hi all,
>>
>> I am having a problem with Tapestry 4.1.6. I have a form with many
>> (>1000) components. I get an exception trying to render the page. It
>> looks like the attempt in RequestCycle to call encodeIdState is
>> hitting a 65k length limit in ObjectOutputStream.writeUTF. Has anyone
>> else encountered this problem? I cannot restructure the page to
>> reduce the number of components, so I need another way to get around
>> this limit. I am thinking that I will need to override RequestCycle
>> so I can call ObjectOutputStream.writeObject instead of .writeUTF when
>> the string is long. Does anyone have a better solution?
>>
>> Exception details follow [[
>> Exception class: org.apache.hivemind.ApplicationRuntimeException
>> Exception message: Unable to encode object
>> ,service$0,page$0,component$0,container$0,session$0,sp$0,layout$1,link
>> 1$
>> 0,shell$0,Insert$2633,Any$9,Insert_0$12,ie6$0,body$0,OnErrorHandler$0,
>> If
>> $6398,ConfirmFunctions$0,DownloadableJavaScript$5,BootstrapJavaScript$
>> 0,
>> homeTab$0,tabAnnouncement$1,RenderBody$728,sheetsTab$0,tabOverview$1,g
>> lo
>> balsTab$0,tabGlobalsOverview$1,sharedFormulasTab$0,tabSharedFormulas$1
>> ,i
>> mportTab$0,tabModelImport$1,exportTab$0,tabExportVersion$1,reportsTab$
>> 0,
>> Else$637,tabReportMenu$1,masterVersionChangeForm$0,apstate$1,apVerSel$
>> 1, subMenuList$1,submenuItem$0,content$1,WarnOnUnsavedChan
>>
>> ... really long string truncated ...
>>
>> enu$0,APPageLink$0,Image_5$0,APPageLink_0$0,Image_6$0,APPageLink_1$0,I
>> ma
>> ge_7$0,APPageLink_2$0,Image_8$0,sampleBalanceSheetReport$1,Image_9$0,s
>> am
>> plePLReport$1,Image_100,addFavoriteSubmitForm$0:java.io.UTFDataFormatE
>> xc eption. This is sometimes caused when classes being serialized to a
>> stream dont implement java.io.Serializable.
>> Stack Trace: {
>> null
>> }
>> Exception class: java.io.UTFDataFormatException Exception message:
>> null Stack Trace: {
>> java.io.ObjectOutputStream$BlockDataOutputStream.writeUTF(Unknown
>> Source)
>> java.io.ObjectOutputStream$BlockDataOutputStream.writeUTF(Unknown
>> Source)
>> java.io.ObjectOutputStream.writeUTF(Unknown Source)
>> org.apache.tapestry.util.io.CompressedDataEncoder.encodeStringCompress
>> ed
>> DataEncoder.java:55
>> org.apache.tapestry.engine.RequestCycle.encodeIdStateRequestCycle.java
>> :6
>> 78
>> org.apache.tapestry.form.FormSupportImpl.renderFormSupportImpl.java:48
>> 2
>> org.apache.tapestry.form.Form.renderComponentForm.java:217
>> org.apache.tapestry.
RE: [Tapestry 4.1] UTFDataFormatException in RequestCycle.encodeIdState
Hi Howard,
Thanks for the suggestion. In our case we may have been able to get by with
the workaround you suggested, but it turned out to be much simpler for us to
replace the calls to objectOutputStream.writeUTF() with calls to
objectOutputStream.writeUnshared().
In case anyone else runs into this, the following approach is working well for
us.
We had to create our own RequestCycleFactoryImpl, RequestCycle and
CompressedDataEncoder classes to plumb in the writeUTF -> writeUnshared change.
That was done by adding a block to hivemodule.xml to replace the
implementation of service-id="tapestry.request.RequestCycleFactory". We were
worried about a performance hit with the change but it seems to be at least as
fast for us. This approach also removes any possibility of running into this
limitation in the future.
Regards,
Aaron
-Original Message-
From: Howard Lewis Ship [mailto:hls...@gmail.com]
Sent: Thursday, July 02, 2009 4:27 PM
To: Tapestry users
Subject: Re: [Tapestry 4.1] UTFDataFormatException in RequestCycle.encodeIdState
That's an unexpected limitation!
In exceptional cases, you can revert to simpler methods; for instance, using a
simple rather than a TextField component, and handling
that part of the submission inside your listener method much like a traditional
servlet.
As a stop-gap, you should give explicit jwcids to ALL of your components, as
use shorter names ... this will buy you a lot (if you see the repetition in the
generated element ids string at the root of your problem). This may be a time
to use less intuitive names (i.e., use abbreviations!).
On Thu, Jul 2, 2009 at 3:31 PM, Aaron Kaminsky
wrote:
> Hi all,
>
> I am having a problem with Tapestry 4.1.6. I have a form with many
> (>1000) components. I get an exception trying to render the page. It
> looks like the attempt in RequestCycle to call encodeIdState is
> hitting a 65k length limit in ObjectOutputStream.writeUTF. Has anyone
> else encountered this problem? I cannot restructure the page to
> reduce the number of components, so I need another way to get around
> this limit. I am thinking that I will need to override RequestCycle
> so I can call ObjectOutputStream.writeObject instead of .writeUTF when
> the string is long. Does anyone have a better solution?
>
> Exception details follow [[
> Exception class: org.apache.hivemind.ApplicationRuntimeException
> Exception message: Unable to encode object
> ,service$0,page$0,component$0,container$0,session$0,sp$0,layout$1,link
> 1$
> 0,shell$0,Insert$2633,Any$9,Insert_0$12,ie6$0,body$0,OnErrorHandler$0,
> If
> $6398,ConfirmFunctions$0,DownloadableJavaScript$5,BootstrapJavaScript$
> 0,
> homeTab$0,tabAnnouncement$1,RenderBody$728,sheetsTab$0,tabOverview$1,g
> lo
> balsTab$0,tabGlobalsOverview$1,sharedFormulasTab$0,tabSharedFormulas$1
> ,i
> mportTab$0,tabModelImport$1,exportTab$0,tabExportVersion$1,reportsTab$
> 0,
> Else$637,tabReportMenu$1,masterVersionChangeForm$0,apstate$1,apVerSel$
> 1, subMenuList$1,submenuItem$0,content$1,WarnOnUnsavedChan
>
> ... really long string truncated ...
>
> enu$0,APPageLink$0,Image_5$0,APPageLink_0$0,Image_6$0,APPageLink_1$0,I
> ma
> ge_7$0,APPageLink_2$0,Image_8$0,sampleBalanceSheetReport$1,Image_9$0,s
> am
> plePLReport$1,Image_100,addFavoriteSubmitForm$0:java.io.UTFDataFormatE
> xc eption. This is sometimes caused when classes being serialized to a
> stream dont implement java.io.Serializable.
> Stack Trace: {
> null
> }
> Exception class: java.io.UTFDataFormatException Exception message:
> null Stack Trace: {
> java.io.ObjectOutputStream$BlockDataOutputStream.writeUTF(Unknown
> Source)
> java.io.ObjectOutputStream$BlockDataOutputStream.writeUTF(Unknown
> Source)
> java.io.ObjectOutputStream.writeUTF(Unknown Source)
> org.apache.tapestry.util.io.CompressedDataEncoder.encodeStringCompress
> ed
> DataEncoder.java:55
> org.apache.tapestry.engine.RequestCycle.encodeIdStateRequestCycle.java
> :6
> 78
> org.apache.tapestry.form.FormSupportImpl.renderFormSupportImpl.java:48
> 2
> org.apache.tapestry.form.Form.renderComponentForm.java:217
> org.apache.tapestry.AbstractComponent.renderAbstractComponent.java:724
> org.apache.tapestry.services.impl.DefaultResponseBuilder.renderDefault
> Re
> sponseBuilder.java:187
> org.apache.tapestry.AbstractComponent.renderBodyAbstractComponent.java
> :5
> 38
> org.apache.tapestry.components.RenderBody.renderComponentRenderBody.ja
> va
> :39
> org.apache.tapestry.AbstractComponent.renderAbstractComponent.java:724
> org.apache.tapestry.services.impl.DefaultResponseBuilder.renderDefault
> Re
> sponseBuilder.java:187
> org.apache.tapestry.AbstractComponent.renderBodyAbstractComponent.java
> :5
> 38
> org.apac
Re: [Tapestry 4.1] UTFDataFormatException in RequestCycle.encodeIdState
That's an unexpected limitation!
In exceptional cases, you can revert to simpler methods; for instance, using
a simple rather than a TextField component, and
handling that part of the submission inside your listener method much like a
traditional servlet.
As a stop-gap, you should give explicit jwcids to ALL of your components, as
use shorter names ... this will buy you a lot
(if you see the repetition in the generated element ids string at the
root of your problem). This
may be a time to use less intuitive names (i.e., use abbreviations!).
On Thu, Jul 2, 2009 at 3:31 PM, Aaron Kaminsky
wrote:
> Hi all,
>
> I am having a problem with Tapestry 4.1.6. I have a form with many
> (>1000) components. I get an exception trying to render the page. It
> looks like the attempt in RequestCycle to call encodeIdState is hitting
> a 65k length limit in ObjectOutputStream.writeUTF. Has anyone else
> encountered this problem? I cannot restructure the page to reduce the
> number of components, so I need another way to get around this limit. I
> am thinking that I will need to override RequestCycle so I can call
> ObjectOutputStream.writeObject instead of .writeUTF when the string is
> long. Does anyone have a better solution?
>
> Exception details follow [[
> Exception class: org.apache.hivemind.ApplicationRuntimeException
> Exception message: Unable to encode object
> ,service$0,page$0,component$0,container$0,session$0,sp$0,layout$1,link1$
> 0,shell$0,Insert$2633,Any$9,Insert_0$12,ie6$0,body$0,OnErrorHandler$0,If
> $6398,ConfirmFunctions$0,DownloadableJavaScript$5,BootstrapJavaScript$0,
> homeTab$0,tabAnnouncement$1,RenderBody$728,sheetsTab$0,tabOverview$1,glo
> balsTab$0,tabGlobalsOverview$1,sharedFormulasTab$0,tabSharedFormulas$1,i
> mportTab$0,tabModelImport$1,exportTab$0,tabExportVersion$1,reportsTab$0,
> Else$637,tabReportMenu$1,masterVersionChangeForm$0,apstate$1,apVerSel$1,
> subMenuList$1,submenuItem$0,content$1,WarnOnUnsavedChan
>
> ... really long string truncated ...
>
> enu$0,APPageLink$0,Image_5$0,APPageLink_0$0,Image_6$0,APPageLink_1$0,Ima
> ge_7$0,APPageLink_2$0,Image_8$0,sampleBalanceSheetReport$1,Image_9$0,sam
> plePLReport$1,Image_100,addFavoriteSubmitForm$0:java.io.UTFDataFormatExc
> eption. This is sometimes caused when classes being serialized to a
> stream dont implement java.io.Serializable.
> Stack Trace: {
> null
> }
> Exception class: java.io.UTFDataFormatException
> Exception message: null
> Stack Trace: {
> java.io.ObjectOutputStream$BlockDataOutputStream.writeUTF(Unknown
> Source)
> java.io.ObjectOutputStream$BlockDataOutputStream.writeUTF(Unknown
> Source)
> java.io.ObjectOutputStream.writeUTF(Unknown Source)
> org.apache.tapestry.util.io.CompressedDataEncoder.encodeStringCompressed
> DataEncoder.java:55
> org.apache.tapestry.engine.RequestCycle.encodeIdStateRequestCycle.java:6
> 78
> org.apache.tapestry.form.FormSupportImpl.renderFormSupportImpl.java:482
> org.apache.tapestry.form.Form.renderComponentForm.java:217
> org.apache.tapestry.AbstractComponent.renderAbstractComponent.java:724
> org.apache.tapestry.services.impl.DefaultResponseBuilder.renderDefaultRe
> sponseBuilder.java:187
> org.apache.tapestry.AbstractComponent.renderBodyAbstractComponent.java:5
> 38
> org.apache.tapestry.components.RenderBody.renderComponentRenderBody.java
> :39
> org.apache.tapestry.AbstractComponent.renderAbstractComponent.java:724
> org.apache.tapestry.services.impl.DefaultResponseBuilder.renderDefaultRe
> sponseBuilder.java:187
> org.apache.tapestry.AbstractComponent.renderBodyAbstractComponent.java:5
> 38
> org.apache.tapestry.components.RenderBody.renderComponentRenderBody.java
> :39
> org.apache.tapestry.AbstractComponent.renderAbstractComponent.java:724
> org.apache.tapestry.services.impl.DefaultResponseBuilder.renderDefaultRe
> sponseBuilder.java:187
> org.apache.tapestry.AbstractComponent.renderBodyAbstractComponent.java:5
> 38
> org.apache.tapestry.html.Body.renderComponentBody.java:38
> org.apache.tapestry.AbstractComponent.renderAbstractComponent.java:724
> org.apache.tapestry.services.impl.DefaultResponseBuilder.renderDefaultRe
> sponseBuilder.java:187
> org.apache.tapestry.AbstractComponent.renderBodyAbstractComponent.java:5
> 38
> org.apache.tapestry.html.Shell.renderComponentShell.java:125
> org.apache.tapestry.AbstractComponent.renderAbstractComponent.java:724
> org.apache.tapestry.services.impl.DefaultResponseBuilder.renderDefaultRe
> sponseBuilder.java:187
> org.apache.tapestry.BaseComponent.renderComponentBaseComponent.java:107
> org.apache.tapestry.AbstractComponent.renderAbstractComponent.java:724
> org.apache.tapestry.services.impl.DefaultResponseBuilder.renderDefaultRe
> sponseBuilder.java:187
> org.apache.tapestry.BaseComponent.renderComponentBaseComponent.java:107
> org.apache.tapestry.AbstractComponent.renderAbstractComponent.java:724
> org.apache.tapestry.services.impl.DefaultResponseBuilder.renderDefaultRe
> sponseBuilder.java:187
> org.apache.tapestry.BaseComponent.rend
