[JBoss JIRA] (WFLY-2632) JGroups drops unicast messages after shutdown/restart (dropping unicast message to wrong destination)
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2632?page=com.atlassian.jira.plugin.... ]
Radoslav Husar resolved WFLY-2632.
----------------------------------
Assignee: Radoslav Husar (was: Richard Achmatowicz)
Fix Version/s: 9.0.0.CR1
(was: 9.0.0.Beta1)
Resolution: Done
This is no longer an issue as of 9.0.0.Alpha2-SNAPSHOT (future 9.0.0.CR1). There are numerous changes since Alpha1 (FORK, component upgrades, etc) one of which fixed the problem.
The message that is being dropped is a leave response ({{GMS: GmsHeader\[LEAVE_RSP\], UNICAST3: DATA, seqno=11, conn_id=11, TCP: \[channel_name=web\]}}). This should not affect cluster formation after restart.
If you are still seeing this issue in standalone JGroups please try upgrading or filing respective https://issues.jboss.org/browse/JGRP Jira with steps to reproduce standalone.
> JGroups drops unicast messages after shutdown/restart (dropping unicast message to wrong destination)
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-2632
> URL: https://issues.jboss.org/browse/WFLY-2632
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Radoslav Husar
> Fix For: 9.0.0.CR1
>
>
> JGroups drops unicast messages (citing wrong destination) after a node in a cluster is shutdown and then restarted.
> The JGroups version in use is 3.4.1.Final.
> Steps to reproduce:
> - start two nodes A, B using the server configuration standalone-ha.xml to create a cluster
> - shutdown A
> - restart A
> - after restart, we see these messages:
> {noformat}
> 13:15:03,227 INFO [stdout] (ServerService Thread Pool -- 63)
> 13:15:03,228 INFO [stdout] (ServerService Thread Pool -- 63) -------------------------------------------------------------------
> 13:15:03,228 INFO [stdout] (ServerService Thread Pool -- 63) GMS: address=lenovo/web, cluster=web, physical address=127.0.0.1:55200
> 13:15:03,229 INFO [stdout] (ServerService Thread Pool -- 63) -------------------------------------------------------------------
> 13:15:03,414 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000094: Received new cluster view: [fred/
> web|3] (2) [fred/web, lenovo/web]
> 13:15:03,422 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000079: Cache local address is lenovo/web
> , physical addresses are [127.0.0.1:55200]
> 13:15:03,427 INFO [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 63) ISPN000128: Infinispan version: Infinispan 'Infinium' 6
> .0.0.CR1
> 13:15:03,533 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5
> -f005-ddb2-b377-46b165e2aa77
> 13:15:03,609 INFO [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 61) ISPN000031: MBeans were successfully registered to the platform
> MBean server.
> 13:15:03,610 INFO [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 62) ISPN000031: MBeans were successfully registered to the platform
> MBean server.
> 13:15:03,765 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 62) JBAS010281: Started default-host/distributable cache from web contain
> er
> 13:15:03,768 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 61) JBAS010281: Started dist cache from web container
> 13:15:03,906 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017534: Register web context: /distributable
> 13:15:03,978 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "distributable.war" (runtime-name : "distributable.war")
> 13:15:04,033 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5
> -f005-ddb2-b377-46b165e2aa77
> 13:15:04,059 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 13:15:04,060 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 13:15:04,060 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.0.Beta2-SNAPSHOT "WildFly" started in 5193ms - Started 293 of 410 services (178 services are lazy, passive or on-demand)
> 13:15:04,533 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5-f005-ddb2-b377-46b165e2aa77
> 13:15:05,034 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5-f005-ddb2-b377-46b165e2aa77
> 13:15:05,534 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5-f005-ddb2-b377-46b165e2aa77
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (WFCORE-208) Expose 'singleton' type information in read-children-types
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-208?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-208:
------------------------------------
Description:
Management clients need a mechanism to disambiguate between cases where a management resource registration exists for a a wildcard PathElement (e.g. PathElement.pathElement("service"), represented in CLI syntax as service=*) versus for a fully specified PathElement (e.g. PathElement.pathElement("service", "remote"), represented as service=remote). In the fully specified case they need to be able to see the full path element when querying for types using the read-children-types operation.
The term we have reached consensus on for describing registrations against a non-wildcard PathElement is a 'singleton'. The registration represents a type, and since within the context of its parent only one address will be valid for that type, that type has a singleton nature.
The task here is to add a new boolean parameter to the read-children-types operation, "include-singletons". The parameter will be optional, default value of 'false', which will result in unchanged default behavior from what exists in WF 8.x and earlier.
If the "include-singletons" parameter is set to "true", the operation result will include the full key/value pair for any singleton registration. So, if a parent registration had children registered under "service=remote" and "service=async", the result for the existing operation would be:
{code}
"result"=> ["service"]
{code}
If the "include-singletons" parameter was set to 'true' it would be:
{code}
"result"=> ["service=remote", "service=async"]
{code}
Note that the elements in the above result list are not ModelType.PROPERTY. They are STRING. The result type for read-children-types is always LIST of STRING.
The '=' char is illegal in the key portion of a PathElement, so a client invoking read-children-types can safely assume that the presence of an '=' char in an element in the result denotes a singleton type, and that the first such char in any element represents the end of the 'key' portion of the registration's PathElement and the portion after that first char represents the value portion of the PathElement.
Note also that there is no simple element "service" in the above result. *If "include-singletons" is "true" a non-fully-qualified type (i.e. just key instead of key=value) will only appear in the result if there is a wildcard registration for that key.*
However, it is possible to have both "key" and one or more "key=xxx" in the same result. This can occur in the case of override registrations, for example what we use with datasources. There is a base type for datasources, but then additional datasource-specific registrations get added to support exposing additional vendor-specific metrics. In such situations, the response with "include-singletons=true" will look like this:
{code}
"result"=> ["datasource", "datasource=ExampleDS"]
{code}
A client that sees both "key" and "key=xxx" in a result can safely assume that "key=xxx" represents an override registration, overriding the basic type registered under "key=*".
Note there is no guarantee as to ordering in the list, i.e. the above example could also look like this:
{code}
"result"=> ["datasource=ExampleDS", "datasource"]
{code}
was:
Management clients need a mechanism to disambiguate between cases where a management resource registration exists for a a wildcard PathElement (e.g. PathElement.pathElement("service"), represented in CLI syntax as service=*) versus for a fully specified PathElement (e.g. PathElement.pathElement("service", "remote"), represented as service=remote). In the fully specified case they need to be able to see the full path element when querying for types using the read-children-types operation.
The term we have reached consensus on for describing registrations against a non-wildcard PathElement is a 'singleton'. The registration represents a type, and since within the context of its parent only one address will be valid for that type, that type has a singleton nature.
The task here is to add a new boolean parameter to the read-children-types operation, "include-singletons". The parameter will be optional, default value of 'false', which will result in unchanged default behavior from what exists in WF 8.x and earlier.
If the "include-singletons" parameter is set to "true", the operation result will include the full key/value pair for any singleton registration. So, if a parent registration had children registered under "service=remote" and "service=async", the result for the existing operation would be:
{code}
"result"=> ["service"]
{code}
If the "include-singletons" parameter was set to 'true' it would be:
{code}
"result"=> ["service=remote", "service=async"]
{code}
Note that the elements in the above result list are not ModelType.PROPERTY. They are STRING. The result type for read-children-types is always LIST of STRING.
The '=' char is illegal in the key portion of a PathElement, so a client invoking read-children-types can safely assume that the presence of an '=' char in an element in the result denotes a singleton type, and that the first such char in any element represents the end of the 'key' portion of the registration's PathElement and the portion after that first char represents the value portion of the PathElement.
Note also that there is no simple element "service" in the above result. *If "include-singletons" is "true" a non-fully-qualified type (i.e. just key instead of key=value) will only appear in the result if there is a wildcard registration for that key.*
However, it is possible to have both "key" and one or more "key=xxx" in the same result. This can occur in the case of override registrations, for example what we use with datasources. There is a base type for datasources, but then additional datasource-specific registrations get added to support exposing additional vendor-specific metrics. In such situations, the response with "include-singletons=true" will look like this:
{code}
"result"=> ["datasource", "datasource=ExampleDS"]
{code}
Note there is no guarantee as to ordering in the list, i.e. the above example could also look like this:
{code}
"result"=> ["datasource=ExampleDS", "datasource"]
{code}
> Expose 'singleton' type information in read-children-types
> ----------------------------------------------------------
>
> Key: WFCORE-208
> URL: https://issues.jboss.org/browse/WFCORE-208
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 1.0.0.Beta1
>
>
> Management clients need a mechanism to disambiguate between cases where a management resource registration exists for a a wildcard PathElement (e.g. PathElement.pathElement("service"), represented in CLI syntax as service=*) versus for a fully specified PathElement (e.g. PathElement.pathElement("service", "remote"), represented as service=remote). In the fully specified case they need to be able to see the full path element when querying for types using the read-children-types operation.
> The term we have reached consensus on for describing registrations against a non-wildcard PathElement is a 'singleton'. The registration represents a type, and since within the context of its parent only one address will be valid for that type, that type has a singleton nature.
> The task here is to add a new boolean parameter to the read-children-types operation, "include-singletons". The parameter will be optional, default value of 'false', which will result in unchanged default behavior from what exists in WF 8.x and earlier.
> If the "include-singletons" parameter is set to "true", the operation result will include the full key/value pair for any singleton registration. So, if a parent registration had children registered under "service=remote" and "service=async", the result for the existing operation would be:
> {code}
> "result"=> ["service"]
> {code}
> If the "include-singletons" parameter was set to 'true' it would be:
> {code}
> "result"=> ["service=remote", "service=async"]
> {code}
> Note that the elements in the above result list are not ModelType.PROPERTY. They are STRING. The result type for read-children-types is always LIST of STRING.
> The '=' char is illegal in the key portion of a PathElement, so a client invoking read-children-types can safely assume that the presence of an '=' char in an element in the result denotes a singleton type, and that the first such char in any element represents the end of the 'key' portion of the registration's PathElement and the portion after that first char represents the value portion of the PathElement.
> Note also that there is no simple element "service" in the above result. *If "include-singletons" is "true" a non-fully-qualified type (i.e. just key instead of key=value) will only appear in the result if there is a wildcard registration for that key.*
> However, it is possible to have both "key" and one or more "key=xxx" in the same result. This can occur in the case of override registrations, for example what we use with datasources. There is a base type for datasources, but then additional datasource-specific registrations get added to support exposing additional vendor-specific metrics. In such situations, the response with "include-singletons=true" will look like this:
> {code}
> "result"=> ["datasource", "datasource=ExampleDS"]
> {code}
> A client that sees both "key" and "key=xxx" in a result can safely assume that "key=xxx" represents an override registration, overriding the basic type registered under "key=*".
> Note there is no guarantee as to ordering in the list, i.e. the above example could also look like this:
> {code}
> "result"=> ["datasource=ExampleDS", "datasource"]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (WFCORE-209) do not export api if excluded within jboss-deployment-structure.xml
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-209?page=com.atlassian.jira.plugin... ]
David Lloyd updated WFCORE-209:
-------------------------------
Assignee: (was: David Lloyd)
> do not export api if excluded within jboss-deployment-structure.xml
> -------------------------------------------------------------------
>
> Key: WFCORE-209
> URL: https://issues.jboss.org/browse/WFCORE-209
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Environment: JBoss EAP 6.3 + Spring 3.2.11.RELEASE
> Reporter: Mathieu Lachance
>
> I'm currently trying to upgrade JPA 2.0 to JPA 2.1 in JBoss EAP 6.3 by leveraging the jboss-deployment-structure.xml:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <deployment>
> <exclude-subsystems>
> <subsystem name="jpa" />
> <subsystem name="webservices" />
> <subsystem name="weld" />
> </exclude-subsystems>
> <exclusions>
> <module name="javax.persistence.api" />
> <module name="org.hibernate" />
> </exclusions>
> </deployment>
> </jboss-deployment-structure>
> {code}
> When trying to deploy my war (containing all hibernate 4.3.6 jars) I get the following error:
> {quote}
> Caused by: java.lang.NoSuchMethodError: javax.persistence.Table.indexes()[Ljavax/persistence/Index;
> at org.hibernate.cfg.annotations.EntityBinder.processComplementaryTableDefinitions(EntityBinder.java:936) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:824) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.cfg.Configuration$MetadataSourceQueue.processAnnotatedClassesQueue(Configuration.java:3788) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.cfg.Configuration$MetadataSourceQueue.processMetadata(Configuration.java:3742) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1410) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1844) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:850) [hibernate-entitymanager-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:843) [hibernate-entitymanager-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:398) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:842) [hibernate-entitymanager-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.jpa.HibernatePersistenceProvider.createContainerEntityManagerFactory(HibernatePersistenceProvider.java:152) [hibernate-entitymanager-4.3.6.Final.jar:4.3.6.Final]
> at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:290) [spring-orm-3.2.11.RELEASE.jar:3.2.11.RELEASE]
> at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:310) [spring-orm-3.2.11.RELEASE.jar:3.2.11.RELEASE]
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1573) [spring-beans-3.2.11.RELEASE.jar:3.2.11.RELEASE]
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1511) [spring-beans-3.2.11.RELEASE.jar:3.2.11.RELEASE]
> ... 23 more
> {quote}
> {{Index}} was introduced with JPA 2.1 and even though:
> 1. my application bundle the correct JPA jar
> 2. my application excluded the javax.persistence.api
> 3. my application excluded the jpa subsystem
> I get a conflict.
> The only way I made it possible to upgrade the JPA version was to explicitely state to not export the javax.persistence.api (see workaround). This way of doing thing though is not portable (as it impacts all other war deployed in the JBoss server) and is critical in our situation.
> The issue might/is probably not be related to jboss-modules component but I was not able to find within the jboss sources the explicit line of code responsible of reading the jboss-deployment-structure.xml.
> If you can point me out the correct component it will be a pleasure to help resolve the issue.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (WFCORE-209) do not export api if excluded within jboss-deployment-structure.xml
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-209?page=com.atlassian.jira.plugin... ]
David Lloyd moved MODULES-203 to WFCORE-209:
--------------------------------------------
Project: WildFly Core (was: JBoss Modules)
Key: WFCORE-209 (was: MODULES-203)
Affects Version/s: (was: 1.3.3.Final)
Component/s: Server
(was: core)
> do not export api if excluded within jboss-deployment-structure.xml
> -------------------------------------------------------------------
>
> Key: WFCORE-209
> URL: https://issues.jboss.org/browse/WFCORE-209
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Environment: JBoss EAP 6.3 + Spring 3.2.11.RELEASE
> Reporter: Mathieu Lachance
> Assignee: David Lloyd
>
> I'm currently trying to upgrade JPA 2.0 to JPA 2.1 in JBoss EAP 6.3 by leveraging the jboss-deployment-structure.xml:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <deployment>
> <exclude-subsystems>
> <subsystem name="jpa" />
> <subsystem name="webservices" />
> <subsystem name="weld" />
> </exclude-subsystems>
> <exclusions>
> <module name="javax.persistence.api" />
> <module name="org.hibernate" />
> </exclusions>
> </deployment>
> </jboss-deployment-structure>
> {code}
> When trying to deploy my war (containing all hibernate 4.3.6 jars) I get the following error:
> {quote}
> Caused by: java.lang.NoSuchMethodError: javax.persistence.Table.indexes()[Ljavax/persistence/Index;
> at org.hibernate.cfg.annotations.EntityBinder.processComplementaryTableDefinitions(EntityBinder.java:936) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:824) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.cfg.Configuration$MetadataSourceQueue.processAnnotatedClassesQueue(Configuration.java:3788) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.cfg.Configuration$MetadataSourceQueue.processMetadata(Configuration.java:3742) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1410) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1844) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:850) [hibernate-entitymanager-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:843) [hibernate-entitymanager-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:398) [hibernate-core-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:842) [hibernate-entitymanager-4.3.6.Final.jar:4.3.6.Final]
> at org.hibernate.jpa.HibernatePersistenceProvider.createContainerEntityManagerFactory(HibernatePersistenceProvider.java:152) [hibernate-entitymanager-4.3.6.Final.jar:4.3.6.Final]
> at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:290) [spring-orm-3.2.11.RELEASE.jar:3.2.11.RELEASE]
> at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:310) [spring-orm-3.2.11.RELEASE.jar:3.2.11.RELEASE]
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1573) [spring-beans-3.2.11.RELEASE.jar:3.2.11.RELEASE]
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1511) [spring-beans-3.2.11.RELEASE.jar:3.2.11.RELEASE]
> ... 23 more
> {quote}
> {{Index}} was introduced with JPA 2.1 and even though:
> 1. my application bundle the correct JPA jar
> 2. my application excluded the javax.persistence.api
> 3. my application excluded the jpa subsystem
> I get a conflict.
> The only way I made it possible to upgrade the JPA version was to explicitely state to not export the javax.persistence.api (see workaround). This way of doing thing though is not portable (as it impacts all other war deployed in the JBoss server) and is critical in our situation.
> The issue might/is probably not be related to jboss-modules component but I was not able to find within the jboss sources the explicit line of code responsible of reading the jboss-deployment-structure.xml.
> If you can point me out the correct component it will be a pleasure to help resolve the issue.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (WFLY-3873) AJP-connector mangles SOAP-request
by Emond Papegaaij (JIRA)
[ https://issues.jboss.org/browse/WFLY-3873?page=com.atlassian.jira.plugin.... ]
Emond Papegaaij commented on WFLY-3873:
---------------------------------------
We are seeing this error on WF 8.2 snapshot build from today. Is this supposed to be fixed in 8.2 as well? If not, is there any chance the fix can be backported?
> AJP-connector mangles SOAP-request
> ----------------------------------
>
> Key: WFLY-3873
> URL: https://issues.jboss.org/browse/WFLY-3873
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: Linux
> reverse-proxy from Apache 2.2 via mod_proxy_ajp to AJP connector on WildFly 8.1.0-Final
> Reporter: Gerke Ephorus
> Assignee: Stuart Douglas
> Labels: .net, ajp, soap
>
> When connecting to WildFly 8.1.0-Final SOAP-service from a .NET application via a reverse-proxy (Apache 2.2 with mod_proxy_ajp to the AJP-connector) it looks like the payload SOAP package gets mangled:
> {noformat}
> 2014-09-19 08:45:05,206 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default task-99) Interceptor for {http://ephorus.com/document-processor/ws/}DocumentProcessor has thrown exception, unwinding now: java.lang.RuntimeException:
> Couldn't parse stream.
> at org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1447)
> at org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:123)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
> at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:241)
> at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:93)
> at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:133)
> at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136)
> at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) [jbossws-spi-2.2.2.Final.jar:2.2.2.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.SessionRestoringHandler.handleRequest(SessionRestoringHandler.java:101) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 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]
> Caused by: com.ctc.wstx.exc.WstxIOException: Invalid UTF-8 start byte 0x95 (at char #4, byte #-1)
> at com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:536)
> at com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:585)
> at com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:610)
> at com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:316)
> at __redirected.__XMLInputFactory.createXMLStreamReader(__XMLInputFactory.java:142) [jboss-modules.jar:1.3.3.Final]
> at org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1445)
> ... 40 more
> Caused by: java.io.CharConversionException: Invalid UTF-8 start byte 0x95 (at char #4, byte #-1)
> at com.ctc.wstx.io.UTF8Reader.reportInvalidInitial(UTF8Reader.java:303)
> at com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:189)
> at com.ctc.wstx.io.ReaderBootstrapper.initialLoad(ReaderBootstrapper.java:250)
> at com.ctc.wstx.io.ReaderBootstrapper.bootstrapInput(ReaderBootstrapper.java:133)
> at com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:531)
> ... 45 more
> {noformat}
> Connecting to the same SOAP-service via the reverse-proxy via the AJP from a different party/client does not show this problem.
> Connecting to the same SOAP-service directly to the http-connector on the same WildFly 8.1.0-Final server does not show this problem.
> Wild guess is that it depends somehow on the HTTP-headers of the .NET client. These are the headers captured via Fiddler-http-proxy on the client-side:
> {noformat}
> POST http://some.host.com/doce/Foo/Bar HTTP/1.1
> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.3082)
> Content-Type: text/xml; charset=utf-8
> SOAPAction: "http://host/some/soap-action/ws/addDocument"
> Host: some.host.com
> Content-Length: 6592
> Expect: 100-continue
> Connection: Keep-Alive
> Accept: application/json, text/plain, */*
> {noformat}
> There is a small change it's the same root-cause as [WFLY-2999]. Maybe I'll find the time to test this on 9.0.0-Beta1.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (WFCORE-208) Expose 'singleton' type information in read-children-types
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-208:
---------------------------------------
Summary: Expose 'singleton' type information in read-children-types
Key: WFCORE-208
URL: https://issues.jboss.org/browse/WFCORE-208
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Reporter: Brian Stansberry
Fix For: 1.0.0.Beta1
Management clients need a mechanism to disambiguate between cases where a management resource registration exists for a a wildcard PathElement (e.g. PathElement.pathElement("service"), represented in CLI syntax as service=*) versus for a fully specified PathElement (e.g. PathElement.pathElement("service", "remote"), represented as service=remote). In the fully specified case they need to be able to see the full path element when querying for types using the read-children-types operation.
The term we have reached consensus on for describing registrations against a non-wildcard PathElement is a 'singleton'. The registration represents a type, and since within the context of its parent only one address will be valid for that type, that type has a singleton nature.
The task here is to add a new boolean parameter to the read-children-types operation, "include-singletons". The parameter will be optional, default value of 'false', which will result in unchanged default behavior from what exists in WF 8.x and earlier.
If the "include-singletons" parameter is set to "true", the operation result will include the full key/value pair for any singleton registration. So, if a parent registration had children registered under "service=remote" and "service=async", the result for the existing operation would be:
{code}
"result"=> ["service"]
{code}
If the "include-singletons" parameter was set to 'true' it would be:
{code}
"result"=> ["service=remote", "service=async"]
{code}
Note that the elements in the above result list are not ModelType.PROPERTY. They are STRING. The result type for read-children-types is always LIST of STRING.
The '=' char is illegal in the key portion of a PathElement, so a client invoking read-children-types can safely assume that the presence of an '=' char in an element in the result denotes a singleton type, and that the first such char in any element represents the end of the 'key' portion of the registration's PathElement and the portion after that first char represents the value portion of the PathElement.
Note also that there is no simple element "service" in the above result. *If "include-singletons" is "true" a non-fully-qualified type (i.e. just key instead of key=value) will only appear in the result if there is a wildcard registration for that key.*
However, it is possible to have both "key" and one or more "key=xxx" in the same result. This can occur in the case of override registrations, for example what we use with datasources. There is a base type for datasources, but then additional datasource-specific registrations get added to support exposing additional vendor-specific metrics. In such situations, the response with "include-singletons=true" will look like this:
{code}
"result"=> ["datasource", "datasource=ExampleDS"]
{code}
Note there is no guarantee as to ordering in the list, i.e. the above example could also look like this:
{code}
"result"=> ["datasource=ExampleDS", "datasource"]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (WFLY-4042) Update JSF based on Mojarra 2.2.9
by Cody Lerum (JIRA)
Cody Lerum created WFLY-4042:
--------------------------------
Summary: Update JSF based on Mojarra 2.2.9
Key: WFLY-4042
URL: https://issues.jboss.org/browse/WFLY-4042
Project: WildFly
Issue Type: Component Upgrade
Components: JSF
Reporter: Cody Lerum
Assignee: Farah Juma
Fix For: 8.2.0.CR1
Release scheduled for Nov 4 2014 and it would be great to pick this up before 8.2.Final
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (WFLY-4036) update EclipseLink/OpenJPA test case to filter out javax.persistence classes
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-4036?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-4036:
-------------------------------
Description:
JBoss modules is improving the case when two modules have bi-directional dependencies (a depends on b and b depends on a). Part of this is ensuring that module level classes are used over classes from dependencies (child first).
This jira is about fixing this for two of our unit tests that willl have this problem (an EclipseLink + OpenJPA static module test).
was:
WildFly-core upgrade is improving the case when two deployments have bi-directional dependencies (a depends on b and b depends on a). Part of this is ensuring that application level classes are used over classes from dependencies.
This introduces an issue for application that include api jars or other jars that previlously used to be overriden by dependency level classes.
This jira is about fixing this for two of our unit tests that willl have this problem (an EclipseLink + OpenJPA test).
> update EclipseLink/OpenJPA test case to filter out javax.persistence classes
> ----------------------------------------------------------------------------
>
> Key: WFLY-4036
> URL: https://issues.jboss.org/browse/WFLY-4036
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Fix For: 9.0.0.Beta1
>
> Attachments: module.xml, module.xml, stacktrace.txt
>
>
> JBoss modules is improving the case when two modules have bi-directional dependencies (a depends on b and b depends on a). Part of this is ensuring that module level classes are used over classes from dependencies (child first).
> This jira is about fixing this for two of our unit tests that willl have this problem (an EclipseLink + OpenJPA static module test).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months