[JBoss JIRA] (WFLY-5113) [Migration operation] [Web to Undertow] Migration fails with java.lang.NoClassDefFoundError
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5113?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-5113.
----------------------------
> [Migration operation] [Web to Undertow] Migration fails with java.lang.NoClassDefFoundError
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-5113
> URL: https://issues.jboss.org/browse/WFLY-5113
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Radim Hatlapatka
> Assignee: Stuart Douglas
> Priority: Blocker
> Fix For: 10.0.0.Beta2
>
>
> Unable to migrate web subsystem due java.lang.NoClassDefFoundError [1]
> [1]
> {noformat}
> 13:01:52,134 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("migrate") failed - address: ([("subsystem" => "web")]): java.lang.NoClassDefFoundError: org/wildfly/extension/undertow/UndertowExtension
> at org.jboss.as.web.WebMigrateOperation.migrateVirtualHost(WebMigrateOperation.java:572)
> at org.jboss.as.web.WebMigrateOperation.transformResources(WebMigrateOperation.java:493)
> at org.jboss.as.web.WebMigrateOperation.access$300(WebMigrateOperation.java:109)
> at org.jboss.as.web.WebMigrateOperation$2.execute(WebMigrateOperation.java:180)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:846) [wildfly-controller-2.0.0.Beta1.jar:2.0.0.Beta1]
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:637) [wildfly-controller-2.0.0.Beta1.jar:2.0.0.Beta1]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:362) [wildfly-controller-2.0.0.Beta1.jar:2.0.0.Beta1]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1272) [wildfly-controller-2.0.0.Beta1.jar:2.0.0.Beta1]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:394) [wildfly-controller-2.0.0.Beta1.jar:2.0.0.Beta1]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:225) [wildfly-controller-2.0.0.Beta1.jar:2.0.0.Beta1]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:207) [wildfly-controller-2.0.0.Beta1.jar:2.0.0.Beta1]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:129) [wildfly-controller-2.0.0.Beta1.jar:2.0.0.Beta1]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:151) [wildfly-controller-2.0.0.Beta1.jar:2.0.0.Beta1]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:147) [wildfly-controller-2.0.0.Beta1.jar:2.0.0.Beta1]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_45]
> at javax.security.auth.Subject.doAs(Subject.java:422) [rt.jar:1.8.0_45]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92) [wildfly-controller-2.0.0.Beta1.jar:2.0.0.Beta1]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:147) [wildfly-controller-2.0.0.Beta1.jar:2.0.0.Beta1]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:298) [wildfly-protocol-2.0.0.Beta1.jar:2.0.0.Beta1]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-2.0.0.Beta1.jar:2.0.0.Beta1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
> at org.jboss.threads.JBossThread.run(JBossThread.java:320) [jboss-threads-2.2.1.Final.jar:2.2.1.Final]
> Caused by: java.lang.ClassNotFoundException: org.wildfly.extension.undertow.UndertowExtension from [Module "org.jboss.as.web:main" from local module loader @2f333739 (finder: local module finder @77468bd9 (roots: /home/rhatlapa/projects/redhat_projects/migration/jboss-eap-7.0/modules,/home/rhatlapa/projects/redhat_projects/migration/jboss-eap-7.0/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205) [jboss-modules.jar:1.4.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455) [jboss-modules.jar:1.4.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404) [jboss-modules.jar:1.4.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385) [jboss-modules.jar:1.4.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130) [jboss-modules.jar:1.4.3.Final]
> ... 24 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-4696) OutOfMemory DirectByteBuffer XNIO
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4696?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-4696.
----------------------------
> OutOfMemory DirectByteBuffer XNIO
> ---------------------------------
>
> Key: WFLY-4696
> URL: https://issues.jboss.org/browse/WFLY-4696
> Project: WildFly
> Issue Type: Bug
> Components: IO, Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final, 9.0.0.Final
> Reporter: Carlos Rodríguez Aguado
> Assignee: Stuart Douglas
> Priority: Blocker
> Fix For: 10.0.0.CR1
>
> Attachments: wfly9_0_0_final.mp4, wlfy.mp4
>
>
> I get this errors constantly in my server when a web connection is interrupted from the browser for instance:
> 11:50:45,301 ERROR [stderr] (default task-339) Exception in thread "default task-339" java.nio.BufferOverflowException
> 11:50:45,301 ERROR [stderr] (default task-339) at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:363)
> 11:50:45,301 ERROR [stderr] (default task-339) at java.nio.ByteBuffer.put(ByteBuffer.java:859)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.util.HttpString.appendTo(HttpString.java:204)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.server.protocol.http.HttpResponseConduit.processWrite(HttpResponseConduit.java:150)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.server.protocol.http.HttpResponseConduit.flush(HttpResponseConduit.java:629)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(AbstractFixedLengthStreamSinkConduit.java:205)
> 11:50:45,301 ERROR [stderr] (default task-339) at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1489)
> 11:50:45,317 ERROR [stderr] (default task-339) at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1470)
> 11:50:45,317 ERROR [stderr] (default task-339) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:201)
> 11:50:45,317 ERROR [stderr] (default task-339) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> 11:50:45,317 ERROR [stderr] (default task-339) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 11:50:45,317 ERROR [stderr] (default task-339) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 11:50:45,317 ERROR [stderr] (default task-339) at java.lang.Thread.run(Thread.java:745)
> And then, I think this errors lead to a OutOfMemory crash:
> 14:23:09,592 ERROR [org.xnio.listener] (default I/O-3) XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError
> at sun.misc.Unsafe.allocateMemory(Native Method) [rt.jar:1.8.0_20]
> at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:127) [rt.jar:1.8.0_20]
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) [rt.jar:1.8.0_20]
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:149) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.JsseSslConduitEngine.<init>(JsseSslConduitEngine.java:143) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.JsseSslStreamConnection.<init>(JsseSslStreamConnection.java:71) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.JsseAcceptingSslStreamConnection.accept(JsseAcceptingSslStreamConnection.java:45) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.JsseAcceptingSslStreamConnection.accept(JsseAcceptingSslStreamConnection.java:37) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.AbstractAcceptingSslChannel.accept(AbstractAcceptingSslChannel.java:187) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:289) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.NioTcpServerHandle.handleReady(NioTcpServerHandle.java:53) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> This is the trace for version 8.2 of WildFly:
> 17:17:16,957 ERROR [io.undertow.request] (default task-49) Undertow request failed HttpServerExchange{ GET /modulab/servlet/ShowPDFReportServlet}: java.nio.BufferOverflowException
> at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:363) [rt.jar:1.8.0_20]
> at java.nio.ByteBuffer.put(ByteBuffer.java:859) [rt.jar:1.8.0_20]
> at io.undertow.util.HttpString.appendTo(HttpString.java:204)
> at io.undertow.server.protocol.http.HttpResponseConduit.processWrite(HttpResponseConduit.java:166)
> at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:564)
> at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.write(AbstractFixedLengthStreamSinkConduit.java:106)
> at org.xnio.conduits.Conduits.writeFinalBasic(Conduits.java:132) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.writeFinal(AbstractFixedLengthStreamSinkConduit.java:175)
> at org.xnio.conduits.ConduitStreamSinkChannel.writeFinal(ConduitStreamSinkChannel.java:104) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at io.undertow.channels.DetachableStreamSinkChannel.writeFinal(DetachableStreamSinkChannel.java:194)
> at io.undertow.server.HttpServerExchange$WriteDispatchChannel.writeFinal(HttpServerExchange.java:1829)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.writeBufferBlocking(ServletOutputStreamImpl.java:565)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:600)
> at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:497)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:581)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:308)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> 10:57:12,389 ERROR [org.xnio.listener] (default I/O-4) XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError
> at sun.misc.Unsafe.allocateMemory(Native Method) [rt.jar:1.8.0_20]
> at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:127) [rt.jar:1.8.0_20]
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) [rt.jar:1.8.0_20]
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:143) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ssl.JsseSslConduitEngine.<init>(JsseSslConduitEngine.java:146) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ssl.JsseSslStreamConnection.<init>(JsseSslStreamConnection.java:71) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ssl.JsseAcceptingSslStreamConnection.accept(JsseAcceptingSslStreamConnection.java:45) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ssl.JsseAcceptingSslStreamConnection.accept(JsseAcceptingSslStreamConnection.java:37) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ssl.AbstractAcceptingSslChannel.accept(AbstractAcceptingSslChannel.java:187) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:289) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.nio.NioTcpServerHandle.handleReady(NioTcpServerHandle.java:53) [xnio-nio-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.3.0.Final.jar:3.3.0.Final]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-5105) [Migration operation] Attribute discovery-group in cluster-connection is not migrated
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5105?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-5105.
----------------------------
> [Migration operation] Attribute discovery-group in cluster-connection is not migrated
> -------------------------------------------------------------------------------------
>
> Key: WFLY-5105
> URL: https://issues.jboss.org/browse/WFLY-5105
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Beta1
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Critical
> Fix For: 10.0.0.Beta2
>
>
> Attribute discovery-group-ref in cluster-connection is not migrated. For example:
> {code}
> <cluster-connection name="cc3">
> <address>cc3-address</address>
> <connector-ref>netty</connector-ref>
> <discovery-group-ref discovery-group-name="groupC"/>
> </cluster-connection>
> {code}
> migrates as:
> {code}
> <cluster-connection name="cc3" connector-name="netty" address="cc3-address"/>
> {code}
> I'm setting higher priority as discovery group is by default in configuration in EAP 6.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-4932) Ehcache dependency version clash in the testsuite
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4932?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-4932.
----------------------------
> Ehcache dependency version clash in the testsuite
> -------------------------------------------------
>
> Key: WFLY-4932
> URL: https://issues.jboss.org/browse/WFLY-4932
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 10.0.0.Beta1
>
>
> We currently have a problem with the transitive ehcache dependency in the WidFly integration testsuite.
> The dependency comes from:
> {noformat}
> [INFO] +- org.wildfly:wildfly-testsuite-shared:jar:10.0.0.Alpha6-SNAPSHOT:test
> ...
> [INFO] | +- org.apache.directory.server:apacheds-core-annotations:jar:2.0.0-M15:test
> [INFO] | | +- org.apache.directory.server:apacheds-core:jar:2.0.0-M15:test
> [INFO] | | | +- org.apache.directory.server:apacheds-core-shared:jar:2.0.0-M15:test
> [INFO] | | | +- org.apache.directory.server:apacheds-interceptors-admin:jar:2.0.0-M15:test
> [INFO] | | | +- org.apache.directory.server:apacheds-interceptors-authn:jar:2.0.0-M15:test
> [INFO] | | | +- org.apache.directory.server:apacheds-interceptors-authz:jar:2.0.0-M15:test
> [INFO] | | | +- org.apache.directory.server:apacheds-interceptors-changelog:jar:2.0.0-M15:test
> [INFO] | | | +- org.apache.directory.server:apacheds-interceptors-collective:jar:2.0.0-M15:test
> [INFO] | | | +- org.apache.directory.server:apacheds-interceptors-event:jar:2.0.0-M15:test
> [INFO] | | | +- org.apache.directory.server:apacheds-interceptors-exception:jar:2.0.0-M15:test
> [INFO] | | | +- org.apache.directory.server:apacheds-interceptors-journal:jar:2.0.0-M15:test
> [INFO] | | | +- org.apache.directory.server:apacheds-interceptors-normalization:jar:2.0.0-M15:test
> [INFO] | | | +- org.apache.directory.server:apacheds-interceptors-operational:jar:2.0.0-M15:test
> [INFO] | | | +- org.apache.directory.server:apacheds-interceptors-referral:jar:2.0.0-M15:test
> [INFO] | | | +- org.apache.directory.server:apacheds-interceptors-schema:jar:2.0.0-M15:test
> [INFO] | | | +- org.apache.directory.server:apacheds-interceptors-subtree:jar:2.0.0-M15:test
> [INFO] | | | +- org.apache.directory.server:apacheds-interceptors-trigger:jar:2.0.0-M15:test
> [INFO] | | | | \- org.apache.directory.api:api-ldap-extras-trigger:jar:1.0.0-M20:test
> [INFO] | | | +- org.apache.directory.api:api-ldap-extras-util:jar:1.0.0-M20:test
> [INFO] | | | \- bouncycastle:bcprov-jdk15:jar:140:test
> [INFO] | | +- org.apache.directory.server:apacheds-core-api:jar:2.0.0-M15:test
> [INFO] | | | +- org.apache.directory.server:apacheds-core-constants:jar:2.0.0-M15:test
> [INFO] | | | +- org.apache.directory.api:api-ldap-client-api:jar:1.0.0-M20:test
> [INFO] | | | +- org.apache.directory.api:api-ldap-extras-aci:jar:1.0.0-M20:test
> [INFO] | | | \- net.sf.ehcache:ehcache-core:jar:2.4.4:test
> ...
> {noformat}
> Now, the issue is that Apache CXF needs EHCache 2.7.1 or greater for WS-Security functionalites. Alternatively, it can properly work *without* EHCache, but in that case EHCache must not be available in the test classpath.
> I tried upgrading the ehcache dependency, but I could not find a version that actually works. Version 2.7.1 is not usable because it pulls a bunch of terracotta components that are not on the jboss maven repository.
> With more recent versions, instead, it looks like some ldap / login functionality do not work; the following tests fail:
> org.jboss.as.test.integration.security.loginmodules.LdapLoginModuleTestCase
> org.jboss.as.test.integration.security.loginmodules.LdapExtLikeAdvancedLdapLMTestCase
> org.jboss.as.test.integration.security.loginmodules.LdapExtLoginModuleTestCase
> org.jboss.as.test.integration.security.loginmodules.LdapExtPasswordCachingTestCase
> with an error message saying
> {noformat}
> 16:49:58,610 ERROR [org.jboss.as.arquillian.container.ServerSetupObserver] (main) Setup task failed during setup. Offending class 'org.jboss.as.test.integration.security.loginmodules.LdapExtLDAPServerSetupTask@5871a482': net.sf.ehcache.CacheException: Another unnamed CacheManager already exists in the same VM. Please provide unique names for each CacheManager in the config or do one of following:
> 1. Use one of the CacheManager.create() static factory methods to reuse same CacheManager with same name or create one if necessary
> 2. Shutdown the earlier cacheManager before creating new one with same name.
> The source of the existing CacheManager is: [Programmatically configured]
> at net.sf.ehcache.CacheManager.assertNoCacheManagerExistsWithSameName(CacheManager.java:628)
> at net.sf.ehcache.CacheManager.init(CacheManager.java:392)
> at net.sf.ehcache.CacheManager.<init>(CacheManager.java:270)
> at org.jboss.as.test.integration.ldap.InMemoryDirectoryServiceFactory.init(InMemoryDirectoryServiceFactory.java:119)
> at org.apache.directory.server.core.factory.DSAnnotationProcessor.createDS(DSAnnotationProcessor.java:87)
> at org.apache.directory.server.core.factory.DSAnnotationProcessor.getDirectoryService(DSAnnotationProcessor.java:318)
> at org.jboss.as.test.integration.security.loginmodules.LdapExtLDAPServerSetupTask.createLdap2(LdapExtLDAPServerSetupTask.java:238)
> at org.jboss.as.test.integration.security.loginmodules.LdapExtLDAPServerSetupTask.setup(LdapExtLDAPServerSetupTask.java:125)
> at org.jboss.as.arquillian.container.ServerSetupObserver.handleBeforeDeployment(ServerSetupObserver.java:116)
> 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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:155)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-5233) Optimize marshalled size of web sessions
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5233?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-5233.
----------------------------
> Optimize marshalled size of web sessions
> ----------------------------------------
>
> Key: WFLY-5233
> URL: https://issues.jboss.org/browse/WFLY-5233
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 10.0.0.Beta2
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 10.0.0.CR1
>
>
> There are a couple of marshalling optimizations that we can make in the current web session clustering code:
> * We currently marshal session identifiers as UTF-8 strings. For the default session id length, this result in 42 bytes for each cache key. Since session ids use a limited alphabet (modified base64) we can easily reduce this to 30 bytes (31 to support variable length).
> * We currently store the metadata of a session in a single cache entry. The metadata is composed of:
> *# Creation timestamp (long)
> *# Last access timestamp (long)
> *# Max inactive interval (int)
> #1 is static. #2 updates every request. #3 is "effectively" static. If we split the metadata cache entry into two: one containing static metadata, the other dynamic metadata; we can reduce the size of the data that needs to be replicated for a read-only request. Additionally, #2 can be represented as a duration of time since #1, and thus can be expressed as a short or integer instead of a long. Thus, for requests that do not modify the session, we only need to replicate 4 bytes or less instead of 20.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-5206) Intermittent NPE when invoking method requestDestroyed
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5206?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-5206.
----------------------------
> Intermittent NPE when invoking method requestDestroyed
> ------------------------------------------------------
>
> Key: WFLY-5206
> URL: https://issues.jboss.org/browse/WFLY-5206
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.0.0.Beta1
> Reporter: Michal Vinkler
> Assignee: Stuart Douglas
> Fix For: 10.0.0.CR1
>
>
> Setup: 4-node cluster, one node at time undeploys application (clusterbench-ee7.ear), while standalone clients keep calling the application.
> This error was seen during clustering failover testing in the following scenario:
> ejb-ejbservlet-repl-sync (failover of HTTP traffic accessing a servlet that locally invokes a stateful clustered EJB, with synchronously replicated cache)
> After undeploying application on perf19 (second node in the cluster), NullPointerException was logged 31 times in the server log.
> Stacktrace:
> {code}
> 2015/08/18 20:01:40:973 EDT [DEBUG][RMI TCP Connection(14)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Going to undeploy: 'clusterbench-ee7.ear' from 'perf19' now.
> 2015/08/18 20:01:41:265 EDT [DEBUG][RMI TCP Connection(14)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Requesting: {
> "operation" : "undeploy",
> "address" : [{
> "deployment" : "clusterbench-ee7.ear"
> }]
> }
> 20:01:41,706 INFO [org.xnio] (RMI TCP Connection(14)-10.16.90.52) XNIO version 3.3.1.Final
> 20:01:41,918 INFO [org.xnio.nio] (RMI TCP Connection(14)-10.16.90.52) XNIO NIO Implementation Version 3.3.1.Final
> 20:01:41,969 INFO [org.jboss.remoting] (RMI TCP Connection(14)-10.16.90.52) JBoss Remoting version 4.0.9.Final
> [JBossINF] [0m[0m20:01:42,603 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 79) WFLYUT0022: Unregistered web context: /clusterbench
> [JBossINF] [0m[0m20:01:42,603 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 78) WFLYUT0022: Unregistered web context: /clusterbench-passivating
> [JBossINF] [0m[0m20:01:42,679 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 78) ISPN000029: Passivating all entries to disk
> [JBossINF] [0m[0m20:01:42,679 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 81) ISPN000029: Passivating all entries to disk
> [JBossINF] [0m[31m20:01:42,681 ERROR [io.undertow.servlet.request] (default task-46) UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldInitialListener: java.lang.NullPointerException
> [JBossINF] at org.jboss.weld.servlet.WeldInitialListener.requestDestroyed(WeldInitialListener.java:135)
> [JBossINF] at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:225)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:325)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:778)
> [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}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
> We also see the very same error in the scenario where the nodes shutdown instead of undeploying application - right after the server shutdown has been requested (we do not use graceful shutdown yet).
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
> May be relevant to https://issues.jboss.org/browse/JBEAP-863 as both errors come together, under the same conditions.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months