[JBoss JIRA] (JGRP-1751) State transfer: views installed during state transfer are never installed at the state requester
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1751?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1751:
--------------------------------
SOLUTIONS:
# Ship current view with state and digest
#* This is unnecessary as the above case is an edge case and we'd ship a view that the state requester already has
# After the state has been transferred, let the state requester ask the coordinator for the current view
#* The state requests ships its current view id
#* The coordinator checks if the view id equals the current view-id
#* If the view-ids don't match, the coordinator sends the *full view* (not delta view) to the state requester
#* Else: no-op
#* This requires 2 new messages: a GET_CURRENT_VIEW(view-id) request and a SET_CURRENT_VIEW(full-view) response
#* This could also be used when we receive a delta-view, but don't have the required view-id (investigate this later)
> State transfer: views installed during state transfer are never installed at the state requester
> ------------------------------------------------------------------------------------------------
>
> Key: JGRP-1751
> URL: https://issues.jboss.org/browse/JGRP-1751
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> If a state requester requests state and BARRIER drops all messages at the state requester, then a view V dispatched by the coordinator during the state transfer will never be installed at the state requester:
> * The current view is V1=\{A,B\}
> * B requests the state from A
> * A gets a JOIN from C
> * A mcasts the new view V2=\{A,B,C\}, seqno=6
> * A sends back a unicast state response to B including the state and a digest with A:6 (*including* V2)
> * B receives the unicast state response and installs the state and digest
> ** B's digest for A is 6
> * B receives V2 (A:6), but *drops it as message 6 is already in its digest for A !*
> --> B will never install V2 !
> This applies to all state transfer protocols which use BARRIER (STATE_TRANSFER, STATE, STATE_SOCK).
--
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
12 years, 7 months
[JBoss JIRA] (WFLY-1477) JACC HttpServletRequestPolicyContextHandler removal on single application undeploy impacting all other deployed applications
by Remy Maucherat (JIRA)
[ https://issues.jboss.org/browse/WFLY-1477?page=com.atlassian.jira.plugin.... ]
Remy Maucherat commented on WFLY-1477:
--------------------------------------
It is this PR: https://github.com/jbossas/jboss-eap/pull/625
> JACC HttpServletRequestPolicyContextHandler removal on single application undeploy impacting all other deployed applications
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1477
> URL: https://issues.jboss.org/browse/WFLY-1477
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (JBoss Web)
> Affects Versions: 8.0.0.Alpha1
> Environment: CentOS 6.x, JBoss AS 7.1.1.Final
> Reporter: Steve S
> Assignee: Remy Maucherat
> Labels: domain, jaas, jboss, jbossweb, login, module, security
>
> Please see the following forum post for a detailed explanation and findings(and potential workaround):
> https://community.jboss.org/message/822054#822054
> If multiple WARs are deployed that depend on a login module leveraging:
> HttpServletRequest request = (HttpServletRequest)PolicyContext.getContext("javax.servlet.http.HttpServletRequest");
> then upon undeploy of any web application in the container the HttpServletRequestPolicyContextHandler is removed(deregistered) in the stop() lifecycle method of the JBossWebRealmService, resulting in:
> 13:03:35,335 ERROR [org.jboss.security.authentication.JBossCachedAuthenticationManager] (ajp--0.0.0.0-8009-1) Login failure: javax.security.auth.login.LoginException: java.lang.IllegalArgumentException: No PolicyContextHandler for key=javax.servlet.http.HttpServletRequest at javax.security.jacc.PolicyContext.getContext(PolicyContext.java:117)
> for any webapps still deployed for every subsequent access to them.
> Simply redeploying any ONE of the remaining webapps or the previously undeployed webapp causes this problem to go away for all deployed applications.
--
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
12 years, 7 months
[JBoss JIRA] (JGRP-1751) State transfer: views installed during state transfer are never installed at the state requester
by Bela Ban (JIRA)
Bela Ban created JGRP-1751:
------------------------------
Summary: State transfer: views installed during state transfer are never installed at the state requester
Key: JGRP-1751
URL: https://issues.jboss.org/browse/JGRP-1751
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.5
If a state requester requests state and BARRIER drops all messages at the state requester, then a view V dispatcher by the coordinator during the state transfer will never be installed at the state requester:
* The current view is V1=\{A,B\}
* B requests the state from A
* A gets a JOIN from C
* A mcasts the new view V2=\{A,B,C\}, seqno=6
* A sends back a unicast state response to B including the state and a digest with A:6 (*including* V2)
* B receives the unicast state response and installs the state and digest
** B's digest for A is 6
* B receives V2 (A:6), but *drops it as message 6 is already in its digest for A !*
--> B will never install V2 !
This applies to all state transfer protocols which use BARRIER (STATE_TRANSFER, STATE, STATE_SOCK).
--
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
12 years, 7 months
[JBoss JIRA] (JGRP-1751) State transfer: views installed during state transfer are never installed at the state requester
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1751?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1751:
---------------------------
Description:
If a state requester requests state and BARRIER drops all messages at the state requester, then a view V dispatched by the coordinator during the state transfer will never be installed at the state requester:
* The current view is V1=\{A,B\}
* B requests the state from A
* A gets a JOIN from C
* A mcasts the new view V2=\{A,B,C\}, seqno=6
* A sends back a unicast state response to B including the state and a digest with A:6 (*including* V2)
* B receives the unicast state response and installs the state and digest
** B's digest for A is 6
* B receives V2 (A:6), but *drops it as message 6 is already in its digest for A !*
--> B will never install V2 !
This applies to all state transfer protocols which use BARRIER (STATE_TRANSFER, STATE, STATE_SOCK).
was:
If a state requester requests state and BARRIER drops all messages at the state requester, then a view V dispatcher by the coordinator during the state transfer will never be installed at the state requester:
* The current view is V1=\{A,B\}
* B requests the state from A
* A gets a JOIN from C
* A mcasts the new view V2=\{A,B,C\}, seqno=6
* A sends back a unicast state response to B including the state and a digest with A:6 (*including* V2)
* B receives the unicast state response and installs the state and digest
** B's digest for A is 6
* B receives V2 (A:6), but *drops it as message 6 is already in its digest for A !*
--> B will never install V2 !
This applies to all state transfer protocols which use BARRIER (STATE_TRANSFER, STATE, STATE_SOCK).
> State transfer: views installed during state transfer are never installed at the state requester
> ------------------------------------------------------------------------------------------------
>
> Key: JGRP-1751
> URL: https://issues.jboss.org/browse/JGRP-1751
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> If a state requester requests state and BARRIER drops all messages at the state requester, then a view V dispatched by the coordinator during the state transfer will never be installed at the state requester:
> * The current view is V1=\{A,B\}
> * B requests the state from A
> * A gets a JOIN from C
> * A mcasts the new view V2=\{A,B,C\}, seqno=6
> * A sends back a unicast state response to B including the state and a digest with A:6 (*including* V2)
> * B receives the unicast state response and installs the state and digest
> ** B's digest for A is 6
> * B receives V2 (A:6), but *drops it as message 6 is already in its digest for A !*
> --> B will never install V2 !
> This applies to all state transfer protocols which use BARRIER (STATE_TRANSFER, STATE, STATE_SOCK).
--
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
12 years, 7 months
[JBoss JIRA] (WFLY-409) JPA should allow for a bean validator factory per persistence unit or per application deployment
by Gunnar Morling (JIRA)
[ https://issues.jboss.org/browse/WFLY-409?page=com.atlassian.jira.plugin.s... ]
Gunnar Morling commented on WFLY-409:
-------------------------------------
Is this to say that in applications with multiple persistence units a validator factory is created for each PU? If so, I don't think that's neccessary as I'm not aware of any PU-specific configuration related to validation. Instead the same VF can be used for all the PUs of one application which will save memory.
But with WFLY-1705 done, this should actually be the case, i.e. JPA consistently uses the one and only (in the context of one application) {{LazyValidatorFacotry}} (I think that's what Scott is saying).
> JPA should allow for a bean validator factory per persistence unit or per application deployment
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-409
> URL: https://issues.jboss.org/browse/WFLY-409
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Labels: open_to_community
> Fix For: 8.0.0.Beta1
>
>
> Currently, a new bean validator factory instance is associated with each deployed persistence unit. This jira calls for adding a new PU property that specifies that a 'per app bean validator factory' should be used for a persistence unit (via a persistence unit property).
> This can be controlled by a new persistence unit property (see existing ones [here|https://docs.jboss.org/author/display/AS71/JPA+Reference+Guide#JPARe...]).
> The new property can be something like "org.jboss.as.jpa.shareValidatorFactory" which defaults to false.
> Look at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.deployPersistenceUnit() to make this change.
--
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
12 years, 7 months
[JBoss JIRA] (WFLY-1477) JACC HttpServletRequestPolicyContextHandler removal on single application undeploy impacting all other deployed applications
by Steve S (JIRA)
[ https://issues.jboss.org/browse/WFLY-1477?page=com.atlassian.jira.plugin.... ]
Steve S commented on WFLY-1477:
-------------------------------
[~rmaucher] can you provide more information on the official fix that went into the web subsystem? Thanks.
> JACC HttpServletRequestPolicyContextHandler removal on single application undeploy impacting all other deployed applications
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1477
> URL: https://issues.jboss.org/browse/WFLY-1477
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (JBoss Web)
> Affects Versions: 8.0.0.Alpha1
> Environment: CentOS 6.x, JBoss AS 7.1.1.Final
> Reporter: Steve S
> Assignee: Remy Maucherat
> Labels: domain, jaas, jboss, jbossweb, login, module, security
>
> Please see the following forum post for a detailed explanation and findings(and potential workaround):
> https://community.jboss.org/message/822054#822054
> If multiple WARs are deployed that depend on a login module leveraging:
> HttpServletRequest request = (HttpServletRequest)PolicyContext.getContext("javax.servlet.http.HttpServletRequest");
> then upon undeploy of any web application in the container the HttpServletRequestPolicyContextHandler is removed(deregistered) in the stop() lifecycle method of the JBossWebRealmService, resulting in:
> 13:03:35,335 ERROR [org.jboss.security.authentication.JBossCachedAuthenticationManager] (ajp--0.0.0.0-8009-1) Login failure: javax.security.auth.login.LoginException: java.lang.IllegalArgumentException: No PolicyContextHandler for key=javax.servlet.http.HttpServletRequest at javax.security.jacc.PolicyContext.getContext(PolicyContext.java:117)
> for any webapps still deployed for every subsequent access to them.
> Simply redeploying any ONE of the remaining webapps or the previously undeployed webapp causes this problem to go away for all deployed applications.
--
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
12 years, 7 months
[JBoss JIRA] (WFLY-2398) org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase fails
by Jeff Zhang (JIRA)
[ https://issues.jboss.org/browse/WFLY-2398?page=com.atlassian.jira.plugin.... ]
Jeff Zhang commented on WFLY-2398:
----------------------------------
I insert some log information into:
Set<String> ids = repository.getResourceAdapters(javax.jms.MessageListener.class);
assertNotNull(ids);
assertEquals(1, ids.size());
11:36:54,559 INFO [stdout] (pool-2-thread-1) $$$[org.jboss.as.test.smoke.deployment.rar.inflow.PureInflowResourceAdapter#1, org.hornetq.ra.HornetQResourceAdapter#1]
For full profile, the ids size should be 2 since it includes "HornetQResourceAdapter" also.
I think we need to modify the testcase to check if it is "web-profile" or "full-profile".
If you think this approach is fine, I will submit patch.
> org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase fails
> ------------------------------------------------------------------------
>
> Key: WFLY-2398
> URL: https://issues.jboss.org/browse/WFLY-2398
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA, Test Suite
> Affects Versions: 8.0.0.Beta1
> Environment: Solaris SPARC 10, Oracle Java 1.7.0_45
> Reporter: Frank Langelage
> Assignee: Jeff Zhang
> Attachments: org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase-output.txt, org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase.txt
>
>
> Running a build of current sources with complete testsuite this test is failing with
> testRegistryConfiguration(org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase): expected:<1> but was:<2>
--
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
12 years, 7 months
[JBoss JIRA] (JASSIST-216) A NullPointerException thrown in javassist.bytecode.analysis.ControlFlow
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-216?page=com.atlassian.jira.plugi... ]
Shigeru Chiba resolved JASSIST-216.
-----------------------------------
Fix Version/s: 3.18.2-GA
3.19.0-GA
Resolution: Done
> A NullPointerException thrown in javassist.bytecode.analysis.ControlFlow
> ------------------------------------------------------------------------
>
> Key: JASSIST-216
> URL: https://issues.jboss.org/browse/JASSIST-216
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.18.1-GA
> Reporter: Shigeru Chiba
> Assignee: Shigeru Chiba
> Priority: Minor
> Fix For: 3.18.2-GA, 3.19.0-GA
>
>
> (The original report is Maximilian Scherr.)
> When analyzing a method with exception handler, printing the exception handler block caused a NullPointerException here (line 248):
> protected void toString2(StringBuffer sbuf) {
> super.toString2(sbuf);
> sbuf.append(", incoming{");
> for (int i = 0; i < entrances.length; i++)
> sbuf.append(entrances[i].position).append(", ");
> sbuf.append("}");
> }
> It appears catcher blocks have a single predecessor (instead of 0) that is "null".
--
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
12 years, 7 months
[JBoss JIRA] (JASSIST-216) A NullPointerException thrown in javassist.bytecode.analysis.ControlFlow
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-216?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-216.
---------------------------------
> A NullPointerException thrown in javassist.bytecode.analysis.ControlFlow
> ------------------------------------------------------------------------
>
> Key: JASSIST-216
> URL: https://issues.jboss.org/browse/JASSIST-216
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.18.1-GA
> Reporter: Shigeru Chiba
> Assignee: Shigeru Chiba
> Priority: Minor
> Fix For: 3.18.2-GA, 3.19.0-GA
>
>
> (The original report is Maximilian Scherr.)
> When analyzing a method with exception handler, printing the exception handler block caused a NullPointerException here (line 248):
> protected void toString2(StringBuffer sbuf) {
> super.toString2(sbuf);
> sbuf.append(", incoming{");
> for (int i = 0; i < entrances.length; i++)
> sbuf.append(entrances[i].position).append(", ");
> sbuf.append("}");
> }
> It appears catcher blocks have a single predecessor (instead of 0) that is "null".
--
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
12 years, 7 months