Hi,
Assuming you use CGLib:
CGLib classes could cause this problem, it makes sense since:
- It does not occur in a single jvm, the enhanced classes are available
there.
- It does occur when read from a different jvm *or* restarted jvm: The
enhanced classes are no longer available there.
Hi,
I did some more research (since I am intrigued by the subject) with the
following results:
- If you have enhanced cglib classes in your session and they are serialized
and later deserialized by a different jvm (for instance after restart)
you'll get a ClassNotFoundException. Since it can't
Thank you Lars, unfortunately we still haven't found any actual cglib
proxies in our session. So it goes.
- Scott
On Thu, Mar 27, 2008 at 7:41 AM, lars vonk [EMAIL PROTECTED] wrote:
Hi,
I did some more research (since I am intrigued by the subject) with the
following results:
- If you
We just discovered that if we use SecondLevelCacheSessionStore the
problem goes away. From there we determined that the setting
Application.get().getPageSettings().setAutomaticMultiWindowSupport(false);
is the lynch pin. We still don't know why this resolves the problem.
- Scott
On Tue, Mar
what else did you use if you didnt use SLCS?
Because if you use the HttpSessionStore then we dont do anything with
serialization..
Thats all tomcat or app container itself
johan
On Thu, Mar 27, 2008 at 6:01 PM, Scott Swank [EMAIL PROTECTED] wrote:
We just discovered that if we use
So that at least eliminates the possibility that cglib is somehow involved.
On Thu, Mar 27, 2008 at 5:33 PM, Scott Swank [EMAIL PROTECTED] wrote:
Here's a simple example that reproduces the problem on fail-over, also
for 1.2. All we really need is to have something in the session and
we get
Glad it works for you.
Tried what you said below, but doesn't solve my problem.
http://www.nabble.com/Finding-the-cause-of-an-Exception-td16088387.html#a16112402
On Thu, 2008-03-27 at 10:01 -0700, Scott Swank wrote:
We just discovered that if we use SecondLevelCacheSessionStore the
My e-mail with attached an attached test case jar didn't go through.
With the following simple application page we get the exception on
failover.
WicketTestApplication.java
---
package com.vegas.wicket_test;
import org.apache.wicket.protocol.http.HttpSessionStore;
import
That did not take care of our problem. We are examining our session
to see whether it mistakenly contains some sort of cglib proxy -- our
typesafe model, or maybe something from Hibernate.
Thank you again for the help.
Scott
On Tue, Mar 25, 2008 at 9:55 AM, Scott Swank [EMAIL PROTECTED] wrote:
Thank you. We'll give that a try and let you know the results.
On Mon, Mar 24, 2008 at 11:43 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
see WICKET-1445. upgrade wicket to trunk and try again.
-igor
On Mon, Mar 24, 2008 at 3:15 PM, Scott Swank [EMAIL PROTECTED] wrote:
We are trying
We are trying to get clustering working with Wicket 1.3.2 (on JBoss
4.3.0) and we get the following exception when one node fails over to
another node. Has anyone seen anything like this before? Any
suggestions/guesses?
Thank you,
Scott
15:02:17,320 ERROR [RequestCycle] Could not deserialize
Stream corrupt exceptio, invalid type code?
It seems that the byte array on that side isnt correct. Do you have a
setup/testcase for this? Do you get it on other app servers?
On 3/24/08, Scott Swank [EMAIL PROTECTED] wrote:
We are trying to get clustering working with Wicket 1.3.2 (on JBoss
We run JBoss and haven't tried this on other app servers. Could the
fact that we're running Java 6 be relevant? The specific type code in
the exception varies each time, and this occurs every time we fail
over from one node to another.
We don't a test case, but if you have a JBoss cluster we
Using the HttpSessionStore pushes this exception to JBoss. It seems
that something in the session just can't be deserialized by a separate
jvm.
On Mon, Mar 24, 2008 at 3:54 PM, Scott Swank [EMAIL PROTECTED] wrote:
We run JBoss and haven't tried this on other app servers. Could the
fact that
If we use ObjectOutputStream to write the session to disk we can read
it back on the same jvm. However, a separate jvm cannot read the file
-- we get the same StreamCorruptedException. What could be
jvm-specific?
Thank you,
Scott
On Mon, Mar 24, 2008 at 4:35 PM, Scott Swank [EMAIL PROTECTED]
are all the nodes running identical software?
-igor
On Mon, Mar 24, 2008 at 4:52 PM, Scott Swank [EMAIL PROTECTED] wrote:
If we use ObjectOutputStream to write the session to disk we can read
it back on the same jvm. However, a separate jvm cannot read the file
-- we get the same
Seemingly yes. If we write the session to disk, stop the jvm, restart
the jvm, and then read the session from disk on the same server we
get this exception.
- Scott
On Mon, Mar 24, 2008 at 5:10 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
are all the nodes running identical software?
-igor
Couldn't missing SerialVersionUUID cause this? Doesn't seem likely
though, I'd expect much saner exception in that case.
-Matej
On Tue, Mar 25, 2008 at 3:24 AM, Scott Swank [EMAIL PROTECTED] wrote:
Seemingly yes. If we write the session to disk, stop the jvm, restart
the jvm, and then read
Are these nodes on the same machine or are you running different machines?
On Mon, Mar 24, 2008 at 6:15 PM, Scott Swank [EMAIL PROTECTED] wrote:
We are trying to get clustering working with Wicket 1.3.2 (on JBoss
4.3.0) and we get the following exception when one node fails over to
another
19 matches
Mail list logo