[JBoss JIRA] (WFCORE-1029) ManagedSocketFactory doesn't work for client sockets
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1029?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1029:
------------------------------------------
I've linked a PR that moves away from using InetSocketAddress as the map key, eliminating the need for sockets to be bound when registration/deregistration occurs.
> ManagedSocketFactory doesn't work for client sockets
> ----------------------------------------------------
>
> Key: WFCORE-1029
> URL: https://issues.jboss.org/browse/WFCORE-1029
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.CR5
> Reporter: Dennis Reed
> Fix For: 3.0.0.Alpha1
>
>
> SocketBindingManagerImpl does not work with client sockets.
> It adds sockets to a map based on local address. Client sockets that have not been bound yet do not have a local address.
> This breaks the JGroups subsystem's ManagedSocketFactory, which uses SocketBindingManagerImpl for both server and client sockets.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1029) ManagedSocketFactory doesn't work for client sockets
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1029?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1029:
-------------------------------------
Fix Version/s: 3.0.0.Alpha1
> ManagedSocketFactory doesn't work for client sockets
> ----------------------------------------------------
>
> Key: WFCORE-1029
> URL: https://issues.jboss.org/browse/WFCORE-1029
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.CR5
> Reporter: Dennis Reed
> Fix For: 3.0.0.Alpha1
>
>
> SocketBindingManagerImpl does not work with client sockets.
> It adds sockets to a map based on local address. Client sockets that have not been bound yet do not have a local address.
> This breaks the JGroups subsystem's ManagedSocketFactory, which uses SocketBindingManagerImpl for both server and client sockets.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (DROOLS-795) Timers are reset during the serialization process
by David Weir (JIRA)
[ https://issues.jboss.org/browse/DROOLS-795?page=com.atlassian.jira.plugin... ]
David Weir commented on DROOLS-795:
-----------------------------------
This is still broken on 6.3.0 Final if you use a realtime clock, not pseudo clock
> Timers are reset during the serialization process
> -------------------------------------------------
>
> Key: DROOLS-795
> URL: https://issues.jboss.org/browse/DROOLS-795
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.3.0.CR1
>
>
> When the marshall serializes a timer it doesn't take count of how much time it is already passed, so when the timer is deserialized it restart from it start time. The following failing test case reproduces the problem.
> {code}
> @Test
> public void testMarshallWithTimedRule() {
> String drl = "rule \"Rule A Timeout\"\n" +
> "when\n" +
> " String( this == \"ATrigger\" )\n" +
> "then\n" +
> " insert (new String( \"A-Timer\") );\n" +
> "System.out.println(\"+++++++Got ATrigger, started A-Timer with 5s timeout\");\n" +
> "end\n" +
> "\n" +
> "rule \"Timer For rule A Timeout\"\n" +
> " timer ( int: 5s )\n" +
> "when\n" +
> " String( this == \"A-Timer\")\n" +
> "then\n" +
> " delete ( \"A-Timer\" );\n" +
> " delete ( \"ATrigger\" );\n" +
> "System.out.println(\"******* reset rule A based on timer\");\n" +
> "end\n";
> KieBase kbase = new KieHelper().addContent( drl, ResourceType.DRL )
> .build( EqualityBehaviorOption.EQUALITY,
> DeclarativeAgendaOption.ENABLED,
> EventProcessingOption.STREAM );
> KieSessionConfiguration sessionConfig = KnowledgeBaseFactory.newKnowledgeSessionConfiguration();
> sessionConfig.setOption( ClockTypeOption.get( "pseudo" ) );
> KieSession ksession = kbase.newKieSession(sessionConfig, null);
> ksession.insert( new String( "ATrigger" ) );
> assertEquals( 1, ksession.getFactCount() );
> ksession.fireAllRules();
> assertEquals( 2, ksession.getFactCount() );
> SessionPseudoClock clock = ksession.getSessionClock();
> clock.advanceTime( 4, TimeUnit.SECONDS );
> assertEquals( 2, ksession.getFactCount() );
> ksession.fireAllRules();
> assertEquals( 2, ksession.getFactCount() );
> ksession = marshallAndUnmarshall( kbase, ksession, sessionConfig);
> clock = ksession.getSessionClock();
> clock.advanceTime( 4, TimeUnit.SECONDS );
> assertEquals( 2, ksession.getFactCount() );
> ksession.fireAllRules();
> assertEquals( 0, ksession.getFactCount() );
> }
> public static KieSession marshallAndUnmarshall(KieBase kbase, KieSession ksession, KieSessionConfiguration sessionConfig) {
> // Serialize and Deserialize
> try {
> Marshaller marshaller = KieServices.Factory.get().getMarshallers().newMarshaller(kbase);
> ByteArrayOutputStream baos = new ByteArrayOutputStream();
> marshaller.marshall(baos, ksession);
> marshaller = MarshallerFactory.newMarshaller( kbase );
> ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray());
> baos.close();
> ksession = marshaller.unmarshall(bais, sessionConfig, null);
> bais.close();
> } catch (Exception e) {
> e.printStackTrace();
> fail("unexpected exception :" + e.getMessage());
> }
> return ksession;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5178) Intermittent failure: NullPointerException during undeployment
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-5178?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-5178:
-------------------------------------------
Two possible options come to mind:
- extend the suspend mechanism and control points to also cover deployments and undeployments. That may be a large undertaking through
- introduce logic in StatefulSessionComponent.createSessionRemote() to check if (StatefulSessionComponent.getCache() == null), in which case the component is known to have called stop() and we can return an exception similar to what is done with ShutdownInterceptor. Unfortunately, when a component shuts down, it does not hold any kind of status such as (starting, started, shuttingDown) which could make the check more precise.
> Intermittent failure: NullPointerException during undeployment
> --------------------------------------------------------------
>
> Key: WFLY-5178
> URL: https://issues.jboss.org/browse/WFLY-5178
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.Beta1
> Reporter: Michal Vinkler
> Assignee: Richard Achmatowicz
> Labels: clean_undeploy
>
> Intermittent failure, so far seen in only one failover test for remote stateful EJBs:
> scenario ejb-ejbremote-undeploy-dist-async
> Setup: 4 node cluster, one node at time undeploys application (clusterbench-ee7.ear), while standalone clients keep calling the application.
> Just before server perf19 finished undeployment of the application, it logged this error 50 times:
> {code}
> [JBossINF] [0m[31m14:50:41,136 ERROR [org.jboss.as.ejb3.remote] (EJB default - 9) WFLYEJB0151: Exception while generating session id for component RemoteStatefulSBImpl with invocation id: -28551 on channel Channel ID 1ca843e6 (inbound) of Remoting connection 4b2907f9 to /10.16.90.52:58920: javax.ejb.EJBException: java.lang.NullPointerException
> [JBossINF] at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSessionRemote(StatefulSessionComponent.java:263)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.SessionOpenRequestHandler$SessionIDGeneratorTask.run(SessionOpenRequestHandler.java:145)
> [JBossINF] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [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)
> [JBossINF] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> [JBossINF] Caused by: java.lang.NullPointerException
> [JBossINF] at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> [JBossINF] at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSessionRemote(StatefulSessionComponent.java:258)
> [JBossINF] ... 7 more
> {code}
> The other nodes did not log this error.
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5663) Default authentication behavior vulnerable to session fixation attacks
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5663?page=com.atlassian.jira.plugin.... ]
Paul Ferraro moved UNDERTOW-583 to WFLY-5663:
---------------------------------------------
Project: WildFly (was: Undertow)
Key: WFLY-5663 (was: UNDERTOW-583)
Component/s: Security
Web (Undertow)
(was: Core)
(was: Security)
Affects Version/s: 10.0.0.CR4
(was: 1.3.4.Final)
> Default authentication behavior vulnerable to session fixation attacks
> ----------------------------------------------------------------------
>
> Key: WFLY-5663
> URL: https://issues.jboss.org/browse/WFLY-5663
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 10.0.0.CR4
> Reporter: Paul Ferraro
> Assignee: Stuart Douglas
> Priority: Critical
>
> See: https://www.owasp.org/index.php/Session_Fixation
> In JBossWeb, there was a system property to enable this behavior: org.apache.catalina.authenticator.AuthenticatorBase.CHANGE_SESSIONID_ON_AUTH
> Undertow does not seem to have an equivalent. I don't see any reason not to always force a session ID change following successful authentication when HttpSession.isNew() returns false.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5664) Default authentication behavior vulnerable to session fixation attacks
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-5664:
----------------------------------
Summary: Default authentication behavior vulnerable to session fixation attacks
Key: WFLY-5664
URL: https://issues.jboss.org/browse/WFLY-5664
Project: WildFly
Issue Type: Bug
Components: Security, Web (Undertow)
Affects Versions: 10.0.0.CR4
Reporter: Paul Ferraro
Assignee: Stuart Douglas
Priority: Critical
See: https://www.owasp.org/index.php/Session_Fixation
In JBossWeb, there was a system property to enable this behavior: org.apache.catalina.authenticator.AuthenticatorBase.CHANGE_SESSIONID_ON_AUTH
Undertow does not seem to have an equivalent. I don't see any reason not to always force a session ID change following successful authentication when HttpSession.isNew() returns false.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5178) Intermittent failure: NullPointerException during undeployment
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-5178?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-5178:
-------------------------------------------
FYI: This is a repeat of the issue with RemoteFailoverTestCase in the Wildfly testsuite, where we have problems with EJBClient exceptions during undeployment of an application. So this is in some sense a duplicate.
When we deploy an application which makes use of EJBs, we create an entry in the deployment repository to represent the deployment and its EJB components. Also, for each application which contains a SFSB, we create a cache which backs sessions for that SFSB component. When an EJBClient message arrives at a server, the deployment repository is used to lookup the component mentioned in the EJBClient message and get access to the required components.
In the case of an EJBClient invocation request, after the message is unpacked, we call findEJB(...) to locate the EJB component to which the invocation applies. If that component is found in the deployment repository(*), an instance of the component's interface is obtained, and the invocation starts to proceed through the interface's interceptors. One of these is the EJBSuspendInterceptor, which will check to see if we the server is in the process of being suspended (part of clean shutdown); if we are, then the invocation will return an exception indicating this. This interceptor only has effect during shutown, and not during undeploy. After the EJBSuspendInterceptor comes the ShutdownInterceptor. This interceptor is controlled by EJBComponent.start() and EJBComponent.stop(). When EJBComponent.stop() is called, this causes the interceptor to return an exception indicating that the component is shutting down. This interceptor is triggered during undeployment of a component, as well as clean shutdown (because the component will be undeployed as part of shutdown).
In the logs, as the undeploy takes place, you can see the effects of the ShutdownInterceptor on EJBClient method invocations:
{noformat}
[JBossINF] [31m23:52:48,178 ERROR [org.jboss.as.ejb3.invocation] (EJB default - 5) WFLYEJB0034: EJB Invocation failed on component RemoteStatefulSBImpl for method public abstract int org.jboss.test.clusterbench.common.ejb.CommonStatefulSB.getSerialAndIncrement(): org.jboss.as.ejb3.component.EJBComponentUnavailableException: WFLYEJB0421: Invocation cannot proceed as component is shutting down
[JBossINF] at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:59)
[JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
[JBossINF] at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
[JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
[JBossINF] at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
[JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
[JBossINF] at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
[JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
[JBossINF] at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
[JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
[JBossINF] at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
[JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
[JBossINF] at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
[JBossINF] at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
[JBossINF] at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
[JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
[JBossINF] at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
[JBossINF] at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
[JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
[JBossINF] at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
[JBossINF] at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
[JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:331)
[JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:69)
[JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202)
[JBossINF] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[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)
[JBossINF] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{noformat}
In the case of EJB message requests to create a new session, the situation is different. The message request comes in, is unpacked, and then the SessionOpenRequestHandler is called to create a new session and return the session id. This method looks up the EJB component in the deploymentRepository using findEJB(...) as before, but this time, instead of looking up the component's interface and running through the interceptors, it calls a method on the SFSB to create a new cache entry for the session. The method is StatefulSessionComponent.createSessionRemote(). This method also includes logic to check to see of the server is being suspended, and will generate an exception if it is, just as in the case of EjbSuspendInterceptor. However, in the case of undeployment, this method does nothing in particular. It doesn't receive the protection that ShutdownInterceptor provides. This means that even if the application is being undeployed, the request processing will still get to call cache.create().getSessionId() on the cache instance backing the session bean's session instances, whether that cache has been stopped by the time the invocation arrives or not. This is the problem. The exceptions seen in the log reflect this fact:
{noformat}
[JBossINF] [31m23:52:48,224 ERROR [org.jboss.as.ejb3.remote] (EJB default - 6) WFLYEJB0151: Exception while generating session id for component RemoteStatefulSBImpl with invocation id: 5942 on channel Channel ID 6309fce9 (inbound) of Remoting connection 6dfa1b19 to /10.16.90.52:41631: javax.ejb.EJBException: java.lang.NullPointerException
[JBossINF] at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSessionRemote(StatefulSessionComponent.java:263)
[JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.SessionOpenRequestHandler$SessionIDGeneratorTask.run(SessionOpenRequestHandler.java:145)
[JBossINF] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[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)
[JBossINF] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
[JBossINF] Caused by: java.lang.NullPointerException
[JBossINF] at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
[JBossINF] at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSessionRemote(StatefulSessionComponent.java:258)
[JBossINF] ... 7 more
{noformat}
In fact, these two exceptions above are right next to each other in the logs.
(*) it can and does happen that if an EJBClient request arrives very late, after shutdown has progressed considerably, we can get NPEs on the lookups in the deployment repository.
> Intermittent failure: NullPointerException during undeployment
> --------------------------------------------------------------
>
> Key: WFLY-5178
> URL: https://issues.jboss.org/browse/WFLY-5178
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.Beta1
> Reporter: Michal Vinkler
> Assignee: Richard Achmatowicz
> Labels: clean_undeploy
>
> Intermittent failure, so far seen in only one failover test for remote stateful EJBs:
> scenario ejb-ejbremote-undeploy-dist-async
> Setup: 4 node cluster, one node at time undeploys application (clusterbench-ee7.ear), while standalone clients keep calling the application.
> Just before server perf19 finished undeployment of the application, it logged this error 50 times:
> {code}
> [JBossINF] [0m[31m14:50:41,136 ERROR [org.jboss.as.ejb3.remote] (EJB default - 9) WFLYEJB0151: Exception while generating session id for component RemoteStatefulSBImpl with invocation id: -28551 on channel Channel ID 1ca843e6 (inbound) of Remoting connection 4b2907f9 to /10.16.90.52:58920: javax.ejb.EJBException: java.lang.NullPointerException
> [JBossINF] at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSessionRemote(StatefulSessionComponent.java:263)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.SessionOpenRequestHandler$SessionIDGeneratorTask.run(SessionOpenRequestHandler.java:145)
> [JBossINF] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [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)
> [JBossINF] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> [JBossINF] Caused by: java.lang.NullPointerException
> [JBossINF] at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> [JBossINF] at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSessionRemote(StatefulSessionComponent.java:258)
> [JBossINF] ... 7 more
> {code}
> The other nodes did not log this error.
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months