[JBoss JIRA] (DROOLS-1198) NoClassDefFoundError when using str[endsWith] on a field that matches an imported class name
by Chris Austin (JIRA)
Chris Austin created DROOLS-1198:
------------------------------------
Summary: NoClassDefFoundError when using str[endsWith] on a field that matches an imported class name
Key: DROOLS-1198
URL: https://issues.jboss.org/browse/DROOLS-1198
Project: Drools
Issue Type: Feature Request
Components: core engine
Affects Versions: 6.4.0.Final
Reporter: Chris Austin
Assignee: Mario Fusco
Priority: Minor
This error was triggered when accessing the user field with str[endsWith] when user is null:
java.lang.NoClassDefFoundError: mssp/io/model/user (wrong name: mssp/io/model/User)
Condition that triggers the error:
$a : Alert(user!=null, user str[endsWith] "$")
This does not trigger the error:
$a : Alert(user!=null, user matches ".+\\$")
If I remove the import for the User class the error will not be triggered. As a workaround I've switched to using matches instead of str[endsWith], but I'd prefer to switch back.
I did not experience this issue in 6.3.0-Final, so it appears to be a regression in 6.4.0-Final
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6672) EJB's async methods' Future#get should treat zero timeout as "don't wait"
by Vsevolod Golovanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-6672?page=com.atlassian.jira.plugin.... ]
Vsevolod Golovanov commented on WFLY-6672:
------------------------------------------
The problem seems to be due to {{org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask}}'s implementation:
{code}
@Override
public synchronized Object get(final long timeout, final TimeUnit unit) throws InterruptedException, ExecutionException, TimeoutException {
if (!isDone()) {
wait(unit.toMillis(timeout));
{code}
Unlike {{Future#get}}, {{Object#wait}} does specify special treatment for the zero timeout value:
{quote}
If timeout is zero, however, then real time is not taken into consideration and the thread simply waits until notified.
{quote}
> EJB's async methods' Future#get should treat zero timeout as "don't wait"
> -------------------------------------------------------------------------
>
> Key: WFLY-6672
> URL: https://issues.jboss.org/browse/WFLY-6672
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.2.0.Final
> Reporter: Vsevolod Golovanov
>
> Say there is an asynchronous EJB method:
> {code}
> @Asynchronous
> public Future<Boolean> method() {
> ...
> }
> {code}
> Calling Future#get with a zero timeout:
> {code}
> if (bean.method().get(0, TimeUnit.MILLISECONDS))
> {code}
> results in a block until the task is finished.
> Instead I expected zero waiting, because {{java.util.concurrent.Future.get(long, TimeUnit)}} doesn't specify any special treatment for a zero timeout value.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6672) EJB's async methods' Future#get should treat zero timeout as "don't wait"
by Vsevolod Golovanov (JIRA)
Vsevolod Golovanov created WFLY-6672:
----------------------------------------
Summary: EJB's async methods' Future#get should treat zero timeout as "don't wait"
Key: WFLY-6672
URL: https://issues.jboss.org/browse/WFLY-6672
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 8.2.0.Final
Reporter: Vsevolod Golovanov
Say there is an asynchronous EJB method:
{code}
@Asynchronous
public Future<Boolean> method() {
...
}
{code}
Calling Future#get with a zero timeout:
{code}
if (bean.method().get(0, TimeUnit.MILLISECONDS))
{code}
results in a block until the task is finished.
Instead I expected zero waiting, because {{java.util.concurrent.Future.get(long, TimeUnit)}} doesn't specify any special treatment for a zero timeout value.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6671) ajp connection hangs if a post HTTP request header contains 'Transfer-Encoding: chunked'
by river shen (JIRA)
[ https://issues.jboss.org/browse/WFLY-6671?page=com.atlassian.jira.plugin.... ]
river shen updated WFLY-6671:
-----------------------------
Steps to Reproduce:
PREPERATION
# install Apache HTTP server 2.2.22 and config the mod_jk to route servlet request through ajp:9009
# used the attached standalone.xml
# deploy the attached service.war.
# Install CURL cli utility.
STEPS:
Run the command:
{noformat}
curl -v -X POST --header "Transfer-Encoding: chunked" --header "Content-Type:appliation/octet-stream" http://localhost/service-1.0-SNAPSHOT/servlets/ContentSize -d @CURLS.txt
{noformat}
EXPECTED:
{noformat}
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying ::1...
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> POST /service-1.0-SNAPSHOT/servlets/ContentSize HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.49.1
> Accept: */*
> Transfer-Encoding: chunked
> Content-Type:appliation/octet-stream
> Expect: 100-continue
>
* Done waiting for 100-continue
< HTTP/1.1 200 OK
< Connection: keep-alive
< X-Powered-By: Undertow/1
< Server: WildFly/10
< Content-Length: 30
< Date: Fri, 03 Jun 2016 18:21:30 GMT
<
<html> file size: 1561 </html>* Connection #0 to host localhost left intact
{noformat}
ACTUAL
{noformat}
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying 10.4.18.179...
* Connected to river-v702 (10.4.18.179) port 80 (#0)
> POST /service-1.0-SNAPSHOT/servlets/ContentSize HTTP/1.1
> Host: river-v702
> User-Agent: curl/7.49.1
> Accept: */*
> Transfer-Encoding: chunked
> Content-Type:appliation/octet-stream
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
{noformat}
The curl command will not return until a CTRL-C is issued.
If we append the :8080 to the url, the expected result is returned from server.
was:
PREPERATION
# install Apache HTTP server 2.2.22 and config the mod_jk to route servlet request through ajp:9009
# used the attached standalone.xml
# deploy the attached service.war.
# Install CURL cli utility.
STEPS:
Run the command:
{noformat}
curl -v -X POST --header "Transfer-Encoding: chunked" --header "Content-Type:appliation/octet-stream" http://localhost/service-1.0-SNAPSHOT/servlets/ContentSize -d @CURLS.txt
{noformat}
EXPECTED:
{noformat}
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying ::1...
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> POST /service-1.0-SNAPSHOT/servlets/ContentSize HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.49.1
> Accept: */*
> Transfer-Encoding: chunked
> Content-Type:appliation/octet-stream
> Expect: 100-continue
>
* Done waiting for 100-continue
< HTTP/1.1 200 OK
< Connection: keep-alive
< X-Powered-By: Undertow/1
< Server: WildFly/10
< Content-Length: 30
< Date: Fri, 03 Jun 2016 18:21:30 GMT
<
<html> file size: 1561 </html>* Connection #0 to host localhost left intact
{noformat}
ACTUAL
{noformat}
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying 10.4.18.179...
* Connected to river-v702 (10.4.18.179) port 80 (#0)
> POST /service-1.0-SNAPSHOT/servlets/ContentSize HTTP/1.1
> Host: river-v702
> User-Agent: curl/7.49.1
> Accept: */*
> Transfer-Encoding: chunked
> Content-Type:appliation/octet-stream
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
{noformat}
If we append the :8080 to the url, the expected result is returned from server.
> ajp connection hangs if a post HTTP request header contains 'Transfer-Encoding: chunked'
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-6671
> URL: https://issues.jboss.org/browse/WFLY-6671
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Environment: Apache HTTP server 2.2.22 with mod_jk
> Reporter: river shen
> Assignee: Stuart Douglas
> Attachments: service-1.0-SNAPSHOT.war, src.zip, stacks.txt, standalone.xml, workers.properties
>
>
> When upgrading from JBOSS 7 to WILDFLY10, we observed following behavior:
> if an HTTP post contains 'Transfer-Encoding: chunked' and 'Content-Type:appliation/octet-stream' in its head, A servlet which handles it will hang for ever ( until the client drop the connection) if it calls HttpServletRequest.getInputStream() and tries to read the whole content of the returned InputStream. The InputStream's read() method will block for ever at the end of the stream as opposed to return -1.
> It only happens when the request is routed by apache web server through ajp; it does not happen if the client talks to wildfly directly through its 8080 http port.
> We have attached a minimal web application that reproduce this issue.
> Also attached is the standalone.xml and the apache configuration file.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6671) ajp connection hangs if a post HTTP request header contains 'Transfer-Encoding: chunked'
by river shen (JIRA)
[ https://issues.jboss.org/browse/WFLY-6671?page=com.atlassian.jira.plugin.... ]
river shen updated WFLY-6671:
-----------------------------
Description:
When upgrading from JBOSS 7 to WILDFLY10, we observed following behavior:
if an HTTP post contains 'Transfer-Encoding: chunked' and 'Content-Type:appliation/octet-stream' in its head, A servlet which handles it will hang for ever ( until the client drop the connection) if it calls HttpServletRequest.getInputStream() and tries to read the whole content of the returned InputStream. The InputStream's read() method will block for ever at the end of the stream as opposed to return -1.
It only happens when the request is routed by apache web server through ajp; it does not happen if the client talks to wildfly directly through its 8080 http port.
We have attached a minimal web application that reproduce this issue.
Also attached is the standalone.xml and the apache configuration file.
was:
When upgrading from JBOSS 7 to WILDFLY10, we observed following behavior:
if an HTTP post contains 'Transfer-Encoding: chunked' and 'Content-Type:appliation/octet-stream' in its head, A servlet which handles it will hang for ever ( until the client drop the connection) if it calls HttpServletRequest.getInputStream() and tries to read the whole content of the returned InputStream. The InputStream's read() method will block for ever at the end of the stream as opposed to return -1.
It only happens when the request is routed by apache web server through ajp; it does not
happen if the client talks to wildfly directly through its 8080 http port.
We have attached a minimal web application that reproduce this issue.
Also attached is the standalone.xml and the apache configuration file.
> ajp connection hangs if a post HTTP request header contains 'Transfer-Encoding: chunked'
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-6671
> URL: https://issues.jboss.org/browse/WFLY-6671
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Environment: Apache HTTP server 2.2.22 with mod_jk
> Reporter: river shen
> Assignee: Stuart Douglas
> Attachments: service-1.0-SNAPSHOT.war, src.zip, stacks.txt, standalone.xml, workers.properties
>
>
> When upgrading from JBOSS 7 to WILDFLY10, we observed following behavior:
> if an HTTP post contains 'Transfer-Encoding: chunked' and 'Content-Type:appliation/octet-stream' in its head, A servlet which handles it will hang for ever ( until the client drop the connection) if it calls HttpServletRequest.getInputStream() and tries to read the whole content of the returned InputStream. The InputStream's read() method will block for ever at the end of the stream as opposed to return -1.
> It only happens when the request is routed by apache web server through ajp; it does not happen if the client talks to wildfly directly through its 8080 http port.
> We have attached a minimal web application that reproduce this issue.
> Also attached is the standalone.xml and the apache configuration file.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6671) ajp connection hangs if a post HTTP request header contains 'Transfer-Encoding: chunked'
by river shen (JIRA)
river shen created WFLY-6671:
--------------------------------
Summary: ajp connection hangs if a post HTTP request header contains 'Transfer-Encoding: chunked'
Key: WFLY-6671
URL: https://issues.jboss.org/browse/WFLY-6671
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 10.0.0.Final
Environment: Apache HTTP server 2.2.22 with mod_jk
Reporter: river shen
Assignee: Stuart Douglas
Attachments: service-1.0-SNAPSHOT.war, src.zip, stacks.txt, standalone.xml, workers.properties
When upgrading from JBOSS 7 to WILDFLY10, we observed following behavior:
if an HTTP post contains 'Transfer-Encoding: chunked' and 'Content-Type:appliation/octet-stream' in its head, A servlet which handles it will hang for ever ( until the client drop the connection) if it calls HttpServletRequest.getInputStream() and tries to read the whole content of the returned InputStream. The InputStream's read() method will block for ever at the end of the stream as opposed to return -1.
It only happens when the request is routed by apache web server through ajp; it does not
happen if the client talks to wildfly directly through its 8080 http port.
We have attached a minimal web application that reproduce this issue.
Also attached is the standalone.xml and the apache configuration file.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6355) Error executing command PrepareCommand/GetKeyValueCommand due to replication timeout
by Fernando Freitas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6355?page=com.atlassian.jira.plugin.... ]
Fernando Freitas commented on WFLY-6355:
----------------------------------------
Any suggestion?
> Error executing command PrepareCommand/GetKeyValueCommand due to replication timeout
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6355
> URL: https://issues.jboss.org/browse/WFLY-6355
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
>
> This is a separate issue originally logged as part of JBEAP-794 (#2 in this [comment|https://issues.jboss.org/browse/JBEAP-794?focusedCommentId=131706...]).
> It comes with 2 different messages:
> {code:title=1. Error executing command GetKeyValueCommand}
> [JBossINF] [0m[31m03:23:38,763 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-92) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf19
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:765)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$175(JGroupsTransport.java:612)
> [JBossINF] at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> [JBossINF] at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> [JBossINF] at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> [JBossINF] at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.RspListFuture.call(RspListFuture.java:47)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.RspListFuture.call(RspListFuture.java:16)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> This one appears exactly in the same scenarios and numbers as JBEAP-3696 - see [occurrences report|http://download.eng.brq.redhat.com/scratch/mvinkler/reports/occurr...]
> (ejb-ejbservlet and http-session scenarios with *REPL* cache)
> {code:title=2. Error executing command PrepareCommand}
> [JBossINF] [0m[31m03:23:38,454 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-24) ISPN000136: Error executing command PrepareCommand, writing keys [UOzA9Tq6F40Y0pcaLUpLe6YLgsYPuFE3SZQoH7iW, UOzA9Tq6F40Y0pcaLUpLe6YLgsYPuFE3SZQoH7iW, UOzA9Tq6F40Y0pcaLUpLe6YLgsYPuFE3SZQoH7iW]: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf19
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:765)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$175(JGroupsTransport.java:612)
> [JBossINF] at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> [JBossINF] at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> [JBossINF] at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> [JBossINF] at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.RspListFuture.call(RspListFuture.java:47)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.RspListFuture.call(RspListFuture.java:16)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> This one appears exactly in the same scenarios and numbers as JBEAP-3780, JBEAP-3781 (and partially also JBEAP-3782) - see [occurrences report|http://download.eng.brq.redhat.com/scratch/mvinkler/reports/occurr...]
> (ejb-remote, ejb-ejbservlet and http-session scenarios with *REPL* cache and *SYNC* replication)
> Server link:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http-...
> Occurrences report:
> http://download.eng.brq.redhat.com/scratch/mvinkler/reports/occurrences/E...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6665) clustering-web-infinispan: missing error handling when unmarshalling session
by Kamil Podlešák (JIRA)
[ https://issues.jboss.org/browse/WFLY-6665?page=com.atlassian.jira.plugin.... ]
Kamil Podlešák commented on WFLY-6665:
--------------------------------------
Yes, I have one example at hand: change of declared field type caused this exception
{noformat}
2016-05-31 12:20:42,776 ERROR [io.undertow.request] (default task-2) UT005022: Exception generating error page /generalError: java.lang.RuntimeException: java.lang.IllegalArgumentException: Can not set eu.lmc.wicket.common.IAjaxTarget field eu.lmc.teamio.action.OpenModalAction.source to eu.lmc.teamio.jd.detail.component.ExternalRecruitersPanel
at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:459)
at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:386)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:311)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalArgumentException: Can not set eu.lmc.wicket.common.IAjaxTarget field eu.lmc.teamio.action.OpenModalAction.source to eu.lmc.teamio.jd.detail.component.ExternalRecruitersPanel
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:167)
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:171)
at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:81)
at java.lang.reflect.Field.set(Field.java:764)
at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1658)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1606)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
{noformat}
Arguably, this might be bug in jboss-marshalling-river, because such change should cause InvalidClassException or InvalidObjectException.
Also: I've checked sources of jboss-marshalling and while the "river" format does write serialVersionUID and read it, it is never used (org.jboss.marshalling.ModularClassResolver#resolveClass takes it as argument, but ignores it completely).
I have also analyzed wildly sources to find whether different serialization format can be used by some configuration, but it looks like jboss-marshalling-river is hardcoded.
> clustering-web-infinispan: missing error handling when unmarshalling session
> ----------------------------------------------------------------------------
>
> Key: WFLY-6665
> URL: https://issues.jboss.org/browse/WFLY-6665
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Kamil Podlešák
> Assignee: Paul Ferraro
>
> When unmarshalling of session throws _unexpected_ exception, it is not handled correctly and is propagated to undertow worker, thus causing generic http 500 error to be shown to user. Problem is that each request tries to unmarshall session again and fails... making this session completely broken (for with no recovery until session cookie expires or is removed (ie browser closed).
> Some exceptions are _expected_ and handled correctly by removing session and continuing (usually, new session is created). They are catched in MarshalledValueMarshaller.read, wrapped by InvalidSerializedFormException and then handled in CoarseSessionAttributesFactory.findValue. Expected exceptions are these:
> * java.lang.ClassNotFoundException
> * java.io.InvalidClassException
> * java.io.InvalidObjectException
> This list is sufficient in *most* of the time, but sometimes even jboss-marshalling-river throws some RuntimeException (not to mention IOException).
> Sample stacktrace (there are several possible variants):
> {noformat}
> 14:26:14,366 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-1) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.commons.CacheListenerException: ISPN000280: Caught exception [java.lang.IllegalArgumentException] while invoking method [public void org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.activated(org.infinispan.notifications.cachelistener.event.CacheEntryActivatedEvent)] on listener instance: org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager@25e2eac0
> at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:291)
> at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:21)
> at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1234)
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1229)
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1206)
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryActivated(CacheNotifierImpl.java:522)
> at org.infinispan.interceptors.ActivationInterceptor.sendNotification(ActivationInterceptor.java:33)
> at org.infinispan.interceptors.CacheLoaderInterceptor.loadInContext(CacheLoaderInterceptor.java:392)
> at org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeeded(CacheLoaderInterceptor.java:362)
> at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:183)
> at org.infinispan.interceptors.CacheLoaderInterceptor.visitGetKeyValueCommand(CacheLoaderInterceptor.java:137)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitDataReadCommand(EntryWrappingInterceptor.java:133)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitGetKeyValueCommand(EntryWrappingInterceptor.java:123)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:71)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:77)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:345)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:330)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:403)
> at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.getValue(InfinispanSessionMetaDataFactory.java:92)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:69)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:39)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:61)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:40)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:234)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:140)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:726)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:756)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:69)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalArgumentException: always failing!
> at eu.lmc.experiment.FailingDeserialization2.readObject(FailingDeserialization2.java:36)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:307)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1637)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:149)
> at org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:135)
> at org.jboss.marshalling.MarshallerObjectInputStream.readObjectOverride(MarshallerObjectInputStream.java:53)
> at org.jboss.marshalling.river.RiverObjectInputStream.readObjectOverride(RiverObjectInputStream.java:307)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:365)
> at java.util.HashMap.readObject(HashMap.java:1396)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:307)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1637)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.wildfly.clustering.marshalling.jboss.SimpleMarshalledValue.get(SimpleMarshalledValue.java:101)
> at org.wildfly.clustering.marshalling.jboss.SimpleMarshalledValue.get(SimpleMarshalledValue.java:44)
> at org.wildfly.clustering.marshalling.jboss.MarshalledValueMarshaller.read(MarshalledValueMarshaller.java:45)
> at org.wildfly.clustering.marshalling.jboss.MarshalledValueMarshaller.read(MarshalledValueMarshaller.java:32)
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionAttributesFactory.findValue(CoarseSessionAttributesFactory.java:84)
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionAttributesFactory.findValue(CoarseSessionAttributesFactory.java:48)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:63)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:40)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.lambda$activated$24(InfinispanSessionManager.java:300)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$$Lambda$129/153353148.run(Unknown Source)
> at org.wildfly.clustering.service.concurrent.StampedLockServiceExecutor.execute(StampedLockServiceExecutor.java:42)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.activated(InfinispanSessionManager.java:297)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> ... 62 more
> Caused by: an exception which occurred:
> in object of type eu.lmc.experiment.FailingDeserialization2
> in object of type java.util.HashMap
> {noformat}
> Note 1: application must be marked as "distributable" in web.xml or equivalent.
> Note 2: in 9.0.2, this bug is way more serious because handling of "expected" exceptions is completely broken and ends up in infinite recursion. So in addition to completely broken session, server logs is spammed by 40 megabytes of stacktraces per each request.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6665) clustering-web-infinispan: missing error handling when unmarshalling session
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6665?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6665:
------------------------------------
[~podlesakk] Can you provide an example of an incompatible change to an application? Typically, if the format of a class changes, you would update the serialVersionUID to reflect this. This cause deserialization to trigger an InvalidClassException - and result in a new session instead of an error page.
> clustering-web-infinispan: missing error handling when unmarshalling session
> ----------------------------------------------------------------------------
>
> Key: WFLY-6665
> URL: https://issues.jboss.org/browse/WFLY-6665
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Kamil Podlešák
> Assignee: Paul Ferraro
>
> When unmarshalling of session throws _unexpected_ exception, it is not handled correctly and is propagated to undertow worker, thus causing generic http 500 error to be shown to user. Problem is that each request tries to unmarshall session again and fails... making this session completely broken (for with no recovery until session cookie expires or is removed (ie browser closed).
> Some exceptions are _expected_ and handled correctly by removing session and continuing (usually, new session is created). They are catched in MarshalledValueMarshaller.read, wrapped by InvalidSerializedFormException and then handled in CoarseSessionAttributesFactory.findValue. Expected exceptions are these:
> * java.lang.ClassNotFoundException
> * java.io.InvalidClassException
> * java.io.InvalidObjectException
> This list is sufficient in *most* of the time, but sometimes even jboss-marshalling-river throws some RuntimeException (not to mention IOException).
> Sample stacktrace (there are several possible variants):
> {noformat}
> 14:26:14,366 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-1) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.commons.CacheListenerException: ISPN000280: Caught exception [java.lang.IllegalArgumentException] while invoking method [public void org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.activated(org.infinispan.notifications.cachelistener.event.CacheEntryActivatedEvent)] on listener instance: org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager@25e2eac0
> at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:291)
> at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:21)
> at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1234)
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1229)
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1206)
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryActivated(CacheNotifierImpl.java:522)
> at org.infinispan.interceptors.ActivationInterceptor.sendNotification(ActivationInterceptor.java:33)
> at org.infinispan.interceptors.CacheLoaderInterceptor.loadInContext(CacheLoaderInterceptor.java:392)
> at org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeeded(CacheLoaderInterceptor.java:362)
> at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:183)
> at org.infinispan.interceptors.CacheLoaderInterceptor.visitGetKeyValueCommand(CacheLoaderInterceptor.java:137)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitDataReadCommand(EntryWrappingInterceptor.java:133)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitGetKeyValueCommand(EntryWrappingInterceptor.java:123)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:71)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:77)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:345)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:330)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:403)
> at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.getValue(InfinispanSessionMetaDataFactory.java:92)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:69)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:39)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:61)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:40)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:234)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:140)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:726)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:756)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:69)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalArgumentException: always failing!
> at eu.lmc.experiment.FailingDeserialization2.readObject(FailingDeserialization2.java:36)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:307)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1637)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:149)
> at org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:135)
> at org.jboss.marshalling.MarshallerObjectInputStream.readObjectOverride(MarshallerObjectInputStream.java:53)
> at org.jboss.marshalling.river.RiverObjectInputStream.readObjectOverride(RiverObjectInputStream.java:307)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:365)
> at java.util.HashMap.readObject(HashMap.java:1396)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:307)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1637)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.wildfly.clustering.marshalling.jboss.SimpleMarshalledValue.get(SimpleMarshalledValue.java:101)
> at org.wildfly.clustering.marshalling.jboss.SimpleMarshalledValue.get(SimpleMarshalledValue.java:44)
> at org.wildfly.clustering.marshalling.jboss.MarshalledValueMarshaller.read(MarshalledValueMarshaller.java:45)
> at org.wildfly.clustering.marshalling.jboss.MarshalledValueMarshaller.read(MarshalledValueMarshaller.java:32)
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionAttributesFactory.findValue(CoarseSessionAttributesFactory.java:84)
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionAttributesFactory.findValue(CoarseSessionAttributesFactory.java:48)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:63)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:40)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.lambda$activated$24(InfinispanSessionManager.java:300)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$$Lambda$129/153353148.run(Unknown Source)
> at org.wildfly.clustering.service.concurrent.StampedLockServiceExecutor.execute(StampedLockServiceExecutor.java:42)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.activated(InfinispanSessionManager.java:297)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> ... 62 more
> Caused by: an exception which occurred:
> in object of type eu.lmc.experiment.FailingDeserialization2
> in object of type java.util.HashMap
> {noformat}
> Note 1: application must be marked as "distributable" in web.xml or equivalent.
> Note 2: in 9.0.2, this bug is way more serious because handling of "expected" exceptions is completely broken and ends up in infinite recursion. So in addition to completely broken session, server logs is spammed by 40 megabytes of stacktraces per each request.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months