[JBoss JIRA] (JGRP-1797) NakackTest testReceptionOfAllMessages fails to receive all messages
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1797?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz resolved JGRP-1797.
---------------------------------------
Resolution: Done
Marking this issue as done as it appears that thread contention in a non synchronized block was the problem.
Will reopen if this proves not to be the case.
> NakackTest testReceptionOfAllMessages fails to receive all messages
> -------------------------------------------------------------------
>
> Key: JGRP-1797
> URL: https://issues.jboss.org/browse/JGRP-1797
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL (5/24), Solaris (6/24), HPUX (1/2) where x/y means x failures over y test executions.
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
> Attachments: stdout.txt
>
>
> This test does the following:
> - involves channels A, B, and C where only B and C are senders and all are receivers
> - B and C send 1000 multicast messages
> - checks that all messages are received and in the correct order
> This test is failing intermittently but quite often.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (JGRP-1799) RpcDispatcher test fails when working with large values
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1799?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz resolved JGRP-1799.
---------------------------------------
Resolution: Done
Marking this issue as resolved as it seems that the additional delay in processing for large values on slow machines was the source of the problem.
If this turns out not to be the case, will reopen.
> RpcDispatcher test fails when working with large values
> -------------------------------------------------------
>
> Key: JGRP-1799
> URL: https://issues.jboss.org/browse/JGRP-1799
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL, Win, Solaris
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> The two tests:
> * testLargeReturnValue
> * testLargeReturnValueUnicastCall
> make RPC calls with values which are increasingly large.
> The values used are in this range:
> {noformat}
> SIZES={10000, 20000, 40000, 80000, 100000, 200000, 400000, 800000,1000000, 2000000, 5000000}
> {noformat}
> The tests have been see to fail with the values 1000000, 2000000 and 5000000, always with the same error in each case.
> In the case of testLargeReturnValue, the test fails because one of the returned values from the RPC is null.
> In the case of testLargeReturnValueUnicastCall, the test fails due to a timeout while sending the RPC.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (JBEE-151) Missing doPrivileged block(s) around getContextClassLoader
by Shelly McGowan (JIRA)
[ https://issues.jboss.org/browse/JBEE-151?page=com.atlassian.jira.plugin.s... ]
Shelly McGowan edited comment on JBEE-151 at 3/13/14 8:55 AM:
--------------------------------------------------------------
Upstream patch committed to jboss-el-api_2.2 branch:
https://github.com/jboss/jboss-el-api_spec/commit/88e00f1d2e901cf6945471c...
EL 2.2 API v1.0.4.Final has been released:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/j...
was (Author: shelly.mcgowan):
Upstream patch committed to jboss-el-api_2.2 branch:
https://github.com/jboss/jboss-el-api_spec/commit/88e00f1d2e901cf6945471c...
> Missing doPrivileged block(s) around getContextClassLoader
> -----------------------------------------------------------
>
> Key: JBEE-151
> URL: https://issues.jboss.org/browse/JBEE-151
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-el-api
> Reporter: Carlo de Wolf
> Assignee: Shelly McGowan
> Fix For: jboss-el-api_2.2_spec-1.0.4.Final, jboss-el-api_3.0_spec-1.0.1.Final
>
>
> jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1
> {code}
> 12:56:34,897 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/read-props].[jsp]] (http-/127.0.0.1:8080-4) JBWEB000236: Servlet.service() for servlet jsp threw exception: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372) [rt.jar:1.7.0_45]
> at java.security.AccessController.checkPermission(AccessController.java:559) [rt.jar:1.7.0_45]
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) [rt.jar:1.7.0_45]
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1561) [rt.jar:1.7.0_45]
> at java.lang.Thread.getContextClassLoader(Thread.java:1472) [rt.jar:1.7.0_45]
> at javax.el.FactoryFinder.find(FactoryFinder.java:130) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:185) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:156) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at org.apache.jasper.runtime.JspApplicationContextImpl.<init>(JspApplicationContextImpl.java:48) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (JGRP-1799) RpcDispatcher test fails when working with large values
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1799?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1799:
-------------------------------------------
The timeout has been increased from 30s to 60s.
PR is here: https://github.com/belaban/JGroups/pull/132
> RpcDispatcher test fails when working with large values
> -------------------------------------------------------
>
> Key: JGRP-1799
> URL: https://issues.jboss.org/browse/JGRP-1799
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL, Win, Solaris
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> The two tests:
> * testLargeReturnValue
> * testLargeReturnValueUnicastCall
> make RPC calls with values which are increasingly large.
> The values used are in this range:
> {noformat}
> SIZES={10000, 20000, 40000, 80000, 100000, 200000, 400000, 800000,1000000, 2000000, 5000000}
> {noformat}
> The tests have been see to fail with the values 1000000, 2000000 and 5000000, always with the same error in each case.
> In the case of testLargeReturnValue, the test fails because one of the returned values from the RPC is null.
> In the case of testLargeReturnValueUnicastCall, the test fails due to a timeout while sending the RPC.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-3044) Mojarra's @ViewScoped implementation is not cluster-aware resulting in NotSerializableException
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3044?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-3044:
--------------------------------------
Do you know what does the actual spec say? Sounds like the test is bad.
> Mojarra's @ViewScoped implementation is not cluster-aware resulting in NotSerializableException
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-3044
> URL: https://issues.jboss.org/browse/WFLY-3044
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF
> Affects Versions: 8.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 8.0.1.Final
>
>
> The problem is in ViewScopeContextManager, namely
> {code}
> getContextMap(facesContext).put(contextual, new ViewScopeContextObject(contextual, creational, name));
> {code}
> probably it needs an artificial ID generated to serve as a key.
> Also the ViewScopeContextObject needs to be serializable as well among other things
> {code}
> class ViewScopeContextObject {
> {code}
> Issue manifests as
> {noformat}[Server:server-one] 19:22:41,564 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-15) ISPN000136: Execution error: org.infinispan.commons.CacheException: java.lang.RuntimeException: Failure to marshal argument(s)
> [Server:server-one] at org.infinispan.commons.util.Util.rewrapAsCacheException(Util.java:581)
> ...
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263)
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312)
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69)
> [Server:server-one] at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80)
> [Server:server-one] at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101)
> [Server:server-one] at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83)
> [Server:server-one] at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64)
> [Server:server-one] at org.infinispan.CacheImpl.endBatch(CacheImpl.java:777)
> [Server:server-one] at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53)
> [Server:server-one] at org.wildfly.clustering.web.infinispan.InfinispanBatcher$1.end(InfinispanBatcher.java:56)
> [Server:server-one] at org.wildfly.clustering.web.infinispan.InfinispanBatcher$1.close(InfinispanBatcher.java:46)
> [Server:server-one] at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:72)
> [Server:server-one] at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:704) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:522) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> [Server:server-one] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> [Server:server-one] Caused by: java.lang.RuntimeException: Failure to marshal argument(s)
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:333)
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:352)
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)
> [Server:server-one] ... 76 more
> [Server:server-one] Caused by: org.infinispan.commons.marshall.NotSerializableException: org.jboss.weld.bean.ManagedBean
> [Server:server-one] Caused by: an exception which occurred:
> [Server:server-one] in object java.util.HashMap@b37422bb
> [Server:server-one] in object org.jboss.as.clustering.marshalling.SimpleMarshalledValue@b37422bb
> [Server:server-one] in object org.infinispan.commands.write.PutKeyValueCommand@db517a36
> [Server:server-one] in object org.infinispan.commands.tx.PrepareCommand@6fa34718
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-2850) AJP connector with external authentication
by Sylvain Brouillat (JIRA)
[ https://issues.jboss.org/browse/WFLY-2850?page=com.atlassian.jira.plugin.... ]
Sylvain Brouillat commented on WFLY-2850:
-----------------------------------------
I agree, this is a critical problem. It prevents me to run applications in production environment.
> AJP connector with external authentication
> ------------------------------------------
>
> Key: WFLY-2850
> URL: https://issues.jboss.org/browse/WFLY-2850
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Reporter: Geert Coelmont
> Assignee: Stuart Douglas
> Priority: Critical
>
> Tomcat allows to set the tomcatAuthentication attribute of the AJP connector to false to allow external web servers (e.g. apache httpd) to handle the authentication and pass that along.
> A similar option was added recently to JBossWeb as well (see WFLY-254), but JBossWeb has been replaced by Undertow. With Undertow this option isn't available as far as I can see.
> For me this is a critical problem as there is currently no way I can do negotiated (SPNEGO) authentication from within WildFly+Undertow. (See also WFLY-2404).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-2850) AJP connector with external authentication
by Sylvain Brouillat (JIRA)
[ https://issues.jboss.org/browse/WFLY-2850?page=com.atlassian.jira.plugin.... ]
Sylvain Brouillat edited comment on WFLY-2850 at 3/13/14 8:32 AM:
------------------------------------------------------------------
I agree, this is a critical problem: I'm not able to use WildFly in production environment because of that.
was (Author: sylvain.b):
I agree, this is a critical problem. It prevents me to run applications in production environment.
> AJP connector with external authentication
> ------------------------------------------
>
> Key: WFLY-2850
> URL: https://issues.jboss.org/browse/WFLY-2850
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Reporter: Geert Coelmont
> Assignee: Stuart Douglas
> Priority: Critical
>
> Tomcat allows to set the tomcatAuthentication attribute of the AJP connector to false to allow external web servers (e.g. apache httpd) to handle the authentication and pass that along.
> A similar option was added recently to JBossWeb as well (see WFLY-254), but JBossWeb has been replaced by Undertow. With Undertow this option isn't available as far as I can see.
> For me this is a critical problem as there is currently no way I can do negotiated (SPNEGO) authentication from within WildFly+Undertow. (See also WFLY-2404).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-3110) Don't copy deployment contents to all hosts when updating an existing deployment
by Emanuel Muckenhuber (JIRA)
Emanuel Muckenhuber created WFLY-3110:
-----------------------------------------
Summary: Don't copy deployment contents to all hosts when updating an existing deployment
Key: WFLY-3110
URL: https://issues.jboss.org/browse/WFLY-3110
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Domain Management
Affects Versions: 8.0.0.Final
Reporter: Emanuel Muckenhuber
Assignee: Emanuel Muckenhuber
Fix For: 8.0.1.Final
In case a deployment gets updated, the full-replace deployment handler on the host-controller retrieves the deployment regardless a local server uses this deployment or not.
This does not seem to be affecting the deployment add operation, which will only get the deployment contents when an actual server requires the contents.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-3109) CloseReason always null for WebSocket onClose methods
by Tom Tom (JIRA)
Tom Tom created WFLY-3109:
-----------------------------
Summary: CloseReason always null for WebSocket onClose methods
Key: WFLY-3109
URL: https://issues.jboss.org/browse/WFLY-3109
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 8.0.0.Final
Environment: WildFly 8.0.0.Final on Windows 7 Pro (64 bits) with JDK 7.0u51 (64 bits)
Reporter: Tom Tom
The onClose method of the websocket endpoints does not receive valid CloseReason, it is always null.
With GlassFish 4.0, the CloseReason is not null and correctly reflects the code and message used to close the wensocket from the client side.
Simplified code sample of the endpoint:
@ServerEndpoint(value = "/test", configurator = MyConfigurator.class)
public class MyEndpoint {
// onOpen, onMessage and onError, LOGGER are omitted
@OnClose
public void onClose(Session session, CloseReason reason) {
LOGGER.debug("onClose(sessionId={}, reason={})", session.getId(), reason);
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months