[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2098:
--------------------------------
I attached LESS_PING instead of polluting the message stream here with code... :-)
Yes, the primary goal of discovery is finding the coordinator.
However, a second goal is also to discover all members out there in case of a merge. For instance, consider cluster A,B,C,D,E which falls apart into A,B and C,D,E on a split. Somehow, both sides need to find out who's out there when the network partition heals. MERGE3 delegates this to the discovery protocols as they already have the means of doing this. I don't want to copy this functionality into the merge protocol itself, to prevent duplication of code.
Re MERGE2 and sendInfo(): I don't want discovery to rely on another protocol. Some configs may not even have a merge protocol in it (I've seen that, although I think that's not correct). Also, some new merge protocols may not send an INFO message at all...
> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
> Key: JGRP-2098
> URL: https://issues.jboss.org/browse/JGRP-2098
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: LESS_PING.java
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2098:
---------------------------
Attachment: LESS_PING.java
> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
> Key: JGRP-2098
> URL: https://issues.jboss.org/browse/JGRP-2098
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: LESS_PING.java
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2098:
---------------------------
Comment: was deleted
(was: In our implementation we created:
{{public class LESS_PING extends PING
{
@Override
public void findMembers( List<Address> members, boolean initial_discovery, Responses responses )
{
// no discovery except for the initial request
if ( initial_discovery )
{
try
{
sendDiscoveryRequest( cluster_name, members );
}
catch ( InterruptedIOException ie )
{
;
}
catch ( InterruptedException ex )
{
;
}
catch ( Throwable ex )
{
log.error( Util.getMessage( "FailedSendingDiscoveryRequest" ), ex );
}
}
}
protected void sendDiscoveryResponse(Address logical_addr, PhysicalAddress physical_addr,
String logical_name, final Address sender, boolean coord) {
final PingData data=new PingData(logical_addr, is_server, logical_name, physical_addr).coord(coord);
final Message rsp_msg=new Message(sender).setFlag(Message.Flag.INTERNAL, Message.Flag.OOB,
Message.Flag.DONT_BUNDLE)
.putHeader(this.id, new PingHeader(PingHeader.GET_MBRS_RSP)).setBuffer(marshal(data));
if(stagger_timeout > 0) {
int view_size=view != null? view.size() : 10;
int rank=Util.getRank(view, local_addr); // returns 0 if view or local_addr are null
if( rank > 5 )
{
// there will be plenty of responders
log.trace("%s: received GET_MBRS_REQ from %s, skipping response due to rank %d > max allowed of %d",
local_addr, sender, rank, max_rank_for_response );
}
else
{
long sleep_time = rank == 0 ? Util.random( stagger_timeout )
: stagger_timeout * rank / view_size - (stagger_timeout / view_size);
timer.schedule( new Runnable()
{
@Override
public void run()
{
log.trace( "%s: received GET_MBRS_REQ from %s, sending staggered response %s", local_addr, sender,
data );
down_prot.down( new Event( Event.MSG, rsp_msg ) );
}
}, sleep_time, TimeUnit.MILLISECONDS );
}
}
else
{
log.trace( "%s: received GET_MBRS_REQ from %s, sending response %s", local_addr, sender, data );
down_prot.down( new Event( Event.MSG, rsp_msg ) );
}
}
}
}}
This in effect limits discovery to initial discovery. In addition, discovery only responds if the rank < 5. Both of these changes work together to most eliminate discovery from the channel (because we have the IP address in the UUID))
> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
> Key: JGRP-2098
> URL: https://issues.jboss.org/browse/JGRP-2098
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: LESS_PING.java
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-952) Use WildFly Common for null param checks
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-952?page=com.atlassian.jira.plugin... ]
David Lloyd updated WFCORE-952:
-------------------------------
Fix Version/s: 3.0.0.Alpha8
> Use WildFly Common for null param checks
> ----------------------------------------
>
> Key: WFCORE-952
> URL: https://issues.jboss.org/browse/WFCORE-952
> Project: WildFly Core
> Issue Type: Task
> Reporter: David Lloyd
> Priority: Minor
> Fix For: 3.0.0.Alpha8
>
>
> For each module, do the following:
> * Locate any/all null param check methods in the log msg
> * Replace them with calls to org.wildfly.common.Assert#checkNotNullParam or related method as needed
> * Replace the old null param check method with a comment that reserves the ID and shows that it was previously used for that purpose
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-623) Checking for anonymous principal by name is insufficient
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-623?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse reassigned ELY-623:
------------------------------------
Assignee: Darran Lofthouse
> Checking for anonymous principal by name is insufficient
> --------------------------------------------------------
>
> Key: ELY-623
> URL: https://issues.jboss.org/browse/ELY-623
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: David Lloyd
> Assignee: Darran Lofthouse
>
> In {{src/main/java/org/wildfly/security/auth/server/SecurityIdentity.java}}:
> {noformat}
> + if (AnonymousPrincipal.getInstance().getName().equals(name)) {
> + if (! context.authorizeAnonymous(false)) {
> + throw log.runAsAuthorizationFailed(getPrincipal(), new AnonymousPrincipal(), null);
> + }
> + } else {
> + if (! (context.importIdentity(this) && context.authorize(name, authorize))) {
> + throw log.runAsAuthorizationFailed(getPrincipal(), new NamePrincipal(name), null);
> + }
> }
> {noformat}
> Only a type check is sufficient to determine if a principal is anonymous. In this fix, the string name "anonymous" takes on a special meaning for the first time, which should not be the case.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1668) org.jboss.modules.ModuleNotFoundException when setting annotations=true in jboss-deployment-structure.xml
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1668?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1668:
-------------------------------------------------
Radovan Netuka <rnetuka(a)redhat.com> changed the Status of [bug 1358556|https://bugzilla.redhat.com/show_bug.cgi?id=1358556] from ASSIGNED to POST
> org.jboss.modules.ModuleNotFoundException when setting annotations=true in jboss-deployment-structure.xml
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1668
> URL: https://issues.jboss.org/browse/WFCORE-1668
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Brad Maxwell
> Assignee: Stuart Douglas
> Fix For: 3.0.0.Alpha4
>
> Attachments: reproducer.zip
>
>
> {code}
> helloWorld.ear
> - helloWorld-ejb.jar
> - HelloBean - @Stateless EJB extends AbstractBean
> - lib
> - helloWorld-api.jar
> - META-INF
> - jandex.idx
> - Hello - EJB interface
> - AbstractBean - abstract class which has @PostConstruct and implements Hello
> helloWorld2.ear
> - helloWorld2-ejb.jar
> - HelloBean2 - @Startup @Singleton extends AbstractBean
> - META-INF
> - jboss-deployment-structure.xml depends on deployment.helloWorld.ear export=true annotations=true
> {code}
> To have HelloBean2 pickup the annotations on AbstractBean, jandex.idx was generate for the helloWorld-api.jar and then the j-d-s.xml file dependency has export=true so helloWorld2-ejb.jar sees the classes and annotations=true set to pull in the annotations.
> When annotations is not set or annotations=false the helloWorld2.ear deploys (but the @PostConstruct is not run since annotations are not enabled). When annotations=true is set, helloWorld2.ear fails to deploy with the exception below.
> It looks like the annotations handling is possibly out of order as the j-d-s.xml dependency should ensure the deployment.helloWorld.ear module is there (which it does when annotations=false, but when true it seems the module is not ready)
> {code}
> 19:44:44,659 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."helloWorld2.ear".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."helloWorld2.ear".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "helloWorld2.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 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: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.modules.ModuleNotFoundException: deployment.helloWorld.ear:main
> at org.jboss.as.server.deployment.annotation.CompositeIndexProcessor.deploy(CompositeIndexProcessor.java:91)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> Caused by: org.jboss.modules.ModuleNotFoundException: deployment.helloWorld.ear:main
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223)
> at org.jboss.as.server.deployment.annotation.CompositeIndexProcessor.deploy(CompositeIndexProcessor.java:81)
> ... 6 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1760) Extension initialization handling makes use of PersistentResourceDefinition overly difficult
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1760:
----------------------------------------
Summary: Extension initialization handling makes use of PersistentResourceDefinition overly difficult
Key: WFCORE-1760
URL: https://issues.jboss.org/browse/WFCORE-1760
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Reporter: Brian Stansberry
PersistentResourceXMLBuilder.build() requires a PersistentResourceDefinition as an input. This is a problem because the PersistentResourcXmlDefinition is needed to initialize parsers for Extension.initializeParsers(), which is called *before* Extension.initialize(). And Extension.initialize() is when the PersistentResourceDefinition would normally be constructed.
An Extension implementation could overcome this by maintaining internal state. Construct the PersistentResourceDefinition in initializeParsers() and store it in an instance field for use in initialize(). Or vice versa. That gets messy though as now the Extension impl is needing to worry about the order in which the two methods are called and tracking whether both have been called so it can drop the cached object.
A possible thing to do is the have the ExtensionContext and ExtensionParsingContext offer an attachment API, with the lifecycle of attachments documented as being scoped to a single overall extension initialization. That could work but isn't very elegant.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6192) JAXBUsageTestCase fails with security manager with security manager enabled
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-6192?page=com.atlassian.jira.plugin.... ]
Alessio Soldano commented on WFLY-6192:
---------------------------------------
[~istudens], can't know for sure, but it looks reasonable. The problem is that even if they decide it's ok, it might take years before it's actually merged and release.
> JAXBUsageTestCase fails with security manager with security manager enabled
> ---------------------------------------------------------------------------
>
> Key: WFLY-6192
> URL: https://issues.jboss.org/browse/WFLY-6192
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Hynek Švábek
> Assignee: Ivo Studensky
>
> *org.jboss.as.test.integration.jaxb.unit.JAXBUsageTestCase#testJAXBServlet*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.jaxb.unit.JAXBUsageTestCase#testJAXBServlet}}
> Fails with:
> {code}
> ERROR [io.undertow.request] (default task-46) UT005023: Exception handling request to /jaxb-webapp//jaxbServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/jaxb-webapp.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.Thread.getContextClassLoader(Thread.java:500)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:279)
> at org.jboss.as.test.integration.jaxb.JAXBUsageServlet.doGet(JAXBUsageServlet.java:50)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 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$1.run(ServletInitialHandler.java:180)
> at java.security.AccessController.doPrivileged(AccessController.java:650)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> 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:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6192) JAXBUsageTestCase fails with security manager with security manager enabled
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-6192?page=com.atlassian.jira.plugin.... ]
Ivo Studensky commented on WFLY-6192:
-------------------------------------
[~asoldano] Do you think JAXB might accept a fix like \[1\]. I remember from some issues in the past that they refuse to merge additional privileged blocks.
\[1\] https://github.com/jboss/jaxb/compare/2.2.11-jboss...istudens:WFLY-6192?e...
> JAXBUsageTestCase fails with security manager with security manager enabled
> ---------------------------------------------------------------------------
>
> Key: WFLY-6192
> URL: https://issues.jboss.org/browse/WFLY-6192
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Hynek Švábek
> Assignee: Ivo Studensky
>
> *org.jboss.as.test.integration.jaxb.unit.JAXBUsageTestCase#testJAXBServlet*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.jaxb.unit.JAXBUsageTestCase#testJAXBServlet}}
> Fails with:
> {code}
> ERROR [io.undertow.request] (default task-46) UT005023: Exception handling request to /jaxb-webapp//jaxbServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/jaxb-webapp.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.Thread.getContextClassLoader(Thread.java:500)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:279)
> at org.jboss.as.test.integration.jaxb.JAXBUsageServlet.doGet(JAXBUsageServlet.java:50)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 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$1.run(ServletInitialHandler.java:180)
> at java.security.AccessController.doPrivileged(AccessController.java:650)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> 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:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months