[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, 4 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, 4 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, 4 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, 4 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, 4 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, 4 months
[JBoss JIRA] (DROOLS-1197) concurrency issue when having multiple kie containers
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1197?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-1197.
---------------------------------
Resolution: Rejected
The problem is caused by the fact that you're (implicitly) using 2 KieContainers with the same ReleaseId, while that one is supposed to be unique. This is a fixed version of your test case.
{code}
import org.junit.Test;
import org.kie.api.KieServices;
import org.kie.api.builder.KieBuilder;
import org.kie.api.builder.KieFileSystem;
import org.kie.api.builder.Message;
import org.kie.api.builder.ReleaseId;
import org.kie.api.io.KieResources;
import org.kie.api.io.Resource;
import org.kie.api.runtime.KieContainer;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
import java.util.concurrent.CompletableFuture;
import static org.junit.Assert.assertEquals;
public class ConcurrencyTest {
KieContainer createContainer(String rule, int id) {
KieServices kieServices = KieServices.Factory.get();
KieResources kieResources = kieServices.getResources();
KieFileSystem kieFileSystem = kieServices.newKieFileSystem();
ReleaseId releaseId = kieServices.newReleaseId("org", "test", id + ".0");
Resource resource = kieResources.newByteArrayResource(rule.getBytes());
kieFileSystem.write("src/main/resources/rule.drl", resource);
kieFileSystem.writePomXML(getPom(releaseId));
KieBuilder kb = kieServices.newKieBuilder(kieFileSystem).buildAll();
if (kb.getResults().hasMessages(Message.Level.ERROR)) {
throw new RuntimeException("Build Errors:\n" + releaseId);
}
return kieServices.newKieContainer(releaseId);
}
String returns1 = "import java.util.List;\n" +
"\n" +
"rule \"rule1\"\n" +
"\tdialect \"mvel\"\n" +
"\twhen\n" +
"\t\tres : List( )\n" +
"\tthen\n" +
" res.add(\"1\");\n" +
"end";
String returns2 = "import java.util.List;\n" +
"\n" +
"rule \"rule1\"\n" +
"\tdialect \"mvel\"\n" +
"\twhen\n" +
"\t\tres : List( )\n" +
"\tthen\n" +
" res.add(\"1\");\n" +
" res.add(\"2\");\n" +
"end";
@Test
public void test() throws Exception {
CompletableFuture<?> f1 = CompletableFuture.runAsync(() -> {
for (int i = 0; i < 100; i++) {
List<String> res1 = new ArrayList<>();
createContainer(returns1, 1).newStatelessKieSession().execute(Arrays.asList(res1));
assertEquals(1, res1.size());
}
});
CompletableFuture<?> f2 = CompletableFuture.runAsync(() -> {
for (int i = 0; i < 100; i++) {
List<String> res2 = new ArrayList<>();
createContainer(returns2, 2).newStatelessKieSession().execute(Arrays.asList(res2));
assertEquals(2, res2.size());
}
});
f1.get();
f2.get();
}
private String getPom( ReleaseId releaseId ) {
return
"<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n" +
"<project xmlns=\"http://maven.apache.org/POM/4.0.0\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n" +
" xsi:schemaLocation=\"http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd\">\n" +
" <modelVersion>4.0.0</modelVersion>\n" +
"\n" +
" <groupId>" + releaseId.getGroupId() + "</groupId>\n" +
" <artifactId>" + releaseId.getArtifactId() + "</artifactId>\n" +
" <version>" + releaseId.getVersion() + "</version>\n" +
"</project>\n";
}
}
{code}
> concurrency issue when having multiple kie containers
> -----------------------------------------------------
>
> Key: DROOLS-1197
> URL: https://issues.jboss.org/browse/DROOLS-1197
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Viacheslav Krot
> Assignee: Mario Fusco
>
> It seems there is some bug related to concurrency when creating multiple kie containers in different threads.
> Here is a test, that runs two threads, each has a loop creating a new kie container and running rule with stateless session. I expect this usecase to work, but it fails eventually - at some point in time kie container has loaded rules other than expected.
> Is the test wrong or is there is a bug?
> {{noformat}}
> import static org.hamcrest.Matchers.hasSize;
> import static org.junit.Assert.assertThat;
> import java.util.ArrayList;
> import java.util.Arrays;
> import java.util.List;
> import java.util.concurrent.CompletableFuture;
> import org.junit.Test;
> import org.kie.api.KieServices;
> import org.kie.api.builder.KieBuilder;
> import org.kie.api.builder.KieFileSystem;
> import org.kie.api.builder.Message;
> import org.kie.api.io.KieResources;
> import org.kie.api.io.Resource;
> import org.kie.api.runtime.KieContainer;
> public class ConcurrencyTest {
> KieContainer createContainer(String rule) {
> KieServices kieServices = KieServices.Factory.get();
> KieResources kieResources = kieServices.getResources();
> KieFileSystem kieFileSystem = kieServices.newKieFileSystem();
> Resource resource = kieResources.newByteArrayResource(rule.getBytes());
> kieFileSystem.write("src/main/resources/rule.drl", resource);
> KieBuilder kb = kieServices.newKieBuilder(kieFileSystem).buildAll();
> if (kb.getResults().hasMessages(Message.Level.ERROR)) {
> throw new RuntimeException("Build Errors:\n" + kb.getResults().toString());
> }
> return kieServices.newKieContainer(kb.getKieModule().getReleaseId());
> }
> String returns1 = "import java.util.List;\n" +
> "\n" +
> "rule \"rule1\"\n" +
> "\tdialect \"mvel\"\n" +
> "\twhen\n" +
> "\t\tres : List( )\n" +
> "\tthen\n" +
> " res.add(\"1\");\n" +
> "end";
> String returns2 = "import java.util.List;\n" +
> "\n" +
> "rule \"rule1\"\n" +
> "\tdialect \"mvel\"\n" +
> "\twhen\n" +
> "\t\tres : List( )\n" +
> "\tthen\n" +
> " res.add(\"1\");\n" +
> " res.add(\"2\");\n" +
> "end";
> @Test
> public void test() throws Exception {
> CompletableFuture<?> f1 = CompletableFuture.runAsync(() -> {
> for (int i = 0; i < 100; i++) {
> List<String> res1 = new ArrayList<>();
> createContainer(returns1).newStatelessKieSession().execute(Arrays.asList(res1));
> assertThat(res1, hasSize(1));
> }
> });
> CompletableFuture<?> f2 = CompletableFuture.runAsync(() -> {
> for (int i = 0; i < 100; i++) {
> List<String> res2 = new ArrayList<>();
> createContainer(returns2).newStatelessKieSession().execute(Arrays.asList(res2));
> assertThat(res2, hasSize(2));
> }
> });
> f1.get();
> f2.get();
> }
> }
> {{noformat}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (WFLY-6670) Upgrade Infinispan to 8.2.3.Final
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6670?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-6670:
--------------------------------------
[~matlach] in the meantime you can surely cherry-pick that fix into Infinispan, built it and upgrade the Jar in your WildFly installation.
> Upgrade Infinispan to 8.2.3.Final
> ---------------------------------
>
> Key: WFLY-6670
> URL: https://issues.jboss.org/browse/WFLY-6670
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Mathieu Lachance
> Assignee: Paul Ferraro
>
> We are currently suffering from ISPN-4390.
> Once Infinispan 8.2.3 will be released, it should be incorporated as soon as possible to get rid of the issue.
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months