[JBoss JIRA] (WFLY-8247) Unable to send large message if JDBC-persistance-store is used
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-8247?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil moved JBEAP-9145 to WFLY-8247:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8247 (was: JBEAP-9145)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JMS
(was: ActiveMQ)
(was: JMS)
Affects Version/s: (was: 7.1.0.DR8)
(was: 7.1.0.DR9)
(was: 7.1.0.DR10)
(was: 7.1.0.DR11)
(was: 7.1.0.DR12)
Affects Testing: (was: Blocks Testing)
> Unable to send large message if JDBC-persistance-store is used
> --------------------------------------------------------------
>
> Key: WFLY-8247
> URL: https://issues.jboss.org/browse/WFLY-8247
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Environment: The issue was hit with Oracle 12c database
> Reporter: Jeff Mesnil
> Assignee: Martyn Taylor
> Priority: Blocker
>
> If producer sends large message to EAP with JDBC-persistance store, the following error arises on the server.
> {code}
> 11:49:34,248 ERROR [org.apache.activemq.artemis.core.server] (default I/O-9) AMQ224016: Caught exception: ActiveMQInternalErrorException[errorType=INTERNAL_ERROR message=Invalid conversion requested]
> at org.apache.activemq.artemis.core.persistence.impl.journal.LargeServerMessageImpl.validateFile(LargeServerMessageImpl.java:376)
> at org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.createLargeMessage(JournalStorageManager.java:458)
> at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.sendLarge(ServerSessionImpl.java:1189)
> at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.handlePacket(ServerSessionPacketHandler.java:436)
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:624)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:373)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:356)
> at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:621)
> at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
> at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:277)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:264)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:962)
> at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:435)
> at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:371)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [xnio-nio-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) [xnio-nio-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> Caused by: java.sql.SQLException: Invalid conversion requested
> at oracle.jdbc.driver.T4CVarcharAccessor.StringToNUMBER(T4CVarcharAccessor.java:832)
> at oracle.jdbc.driver.T4CVarcharAccessor.getNUMBER(T4CVarcharAccessor.java:239)
> at oracle.jdbc.driver.T4CVarcharAccessor.getInt(T4CVarcharAccessor.java:527)
> at oracle.jdbc.driver.GeneratedStatement.getInt(GeneratedStatement.java:217)
> at oracle.jdbc.driver.GeneratedScrollableResultSet.getInt(GeneratedScrollableResultSet.java:573)
> at org.jboss.jca.adapters.jdbc.WrappedResultSet.getInt(WrappedResultSet.java:1490)
> at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFileFactoryDriver.createFile(JDBCSequentialFileFactoryDriver.java:165)
> at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFileFactoryDriver.openFile(JDBCSequentialFileFactoryDriver.java:102)
> at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFile.open(JDBCSequentialFile.java:98)
> at org.apache.activemq.artemis.core.persistence.impl.journal.LargeServerMessageImpl.openFile(LargeServerMessageImpl.java:391)
> at org.apache.activemq.artemis.core.persistence.impl.journal.LargeServerMessageImpl.validateFile(LargeServerMessageImpl.java:370)
> ... 21 more
> Caused by: java.lang.NumberFormatException
> at java.math.BigDecimal.<init>(BigDecimal.java:494) [rt.jar:1.8.0_111]
> at java.math.BigDecimal.<init>(BigDecimal.java:383) [rt.jar:1.8.0_111]
> at java.math.BigDecimal.<init>(BigDecimal.java:806) [rt.jar:1.8.0_111]
> at oracle.jdbc.driver.T4CVarcharAccessor.StringToNUMBER(T4CVarcharAccessor.java:825)
> ... 31 more
> {code}
> *Customer impact*: Clients are not able to send large messages. Sending/receiving large messages is common customer use case. This blocks RFE EAP7-591.
> There is no workaround.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8247) Unable to send large message if JDBC-persistance-store is used
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-8247?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil reassigned WFLY-8247:
---------------------------------
Assignee: Jeff Mesnil (was: Martyn Taylor)
> Unable to send large message if JDBC-persistance-store is used
> --------------------------------------------------------------
>
> Key: WFLY-8247
> URL: https://issues.jboss.org/browse/WFLY-8247
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Environment: The issue was hit with Oracle 12c database
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> If producer sends large message to EAP with JDBC-persistance store, the following error arises on the server.
> {code}
> 11:49:34,248 ERROR [org.apache.activemq.artemis.core.server] (default I/O-9) AMQ224016: Caught exception: ActiveMQInternalErrorException[errorType=INTERNAL_ERROR message=Invalid conversion requested]
> at org.apache.activemq.artemis.core.persistence.impl.journal.LargeServerMessageImpl.validateFile(LargeServerMessageImpl.java:376)
> at org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.createLargeMessage(JournalStorageManager.java:458)
> at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.sendLarge(ServerSessionImpl.java:1189)
> at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.handlePacket(ServerSessionPacketHandler.java:436)
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:624)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:373)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:356)
> at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:621)
> at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
> at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:277)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:264)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:962)
> at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:435)
> at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:371)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [xnio-nio-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) [xnio-nio-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> Caused by: java.sql.SQLException: Invalid conversion requested
> at oracle.jdbc.driver.T4CVarcharAccessor.StringToNUMBER(T4CVarcharAccessor.java:832)
> at oracle.jdbc.driver.T4CVarcharAccessor.getNUMBER(T4CVarcharAccessor.java:239)
> at oracle.jdbc.driver.T4CVarcharAccessor.getInt(T4CVarcharAccessor.java:527)
> at oracle.jdbc.driver.GeneratedStatement.getInt(GeneratedStatement.java:217)
> at oracle.jdbc.driver.GeneratedScrollableResultSet.getInt(GeneratedScrollableResultSet.java:573)
> at org.jboss.jca.adapters.jdbc.WrappedResultSet.getInt(WrappedResultSet.java:1490)
> at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFileFactoryDriver.createFile(JDBCSequentialFileFactoryDriver.java:165)
> at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFileFactoryDriver.openFile(JDBCSequentialFileFactoryDriver.java:102)
> at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFile.open(JDBCSequentialFile.java:98)
> at org.apache.activemq.artemis.core.persistence.impl.journal.LargeServerMessageImpl.openFile(LargeServerMessageImpl.java:391)
> at org.apache.activemq.artemis.core.persistence.impl.journal.LargeServerMessageImpl.validateFile(LargeServerMessageImpl.java:370)
> ... 21 more
> Caused by: java.lang.NumberFormatException
> at java.math.BigDecimal.<init>(BigDecimal.java:494) [rt.jar:1.8.0_111]
> at java.math.BigDecimal.<init>(BigDecimal.java:383) [rt.jar:1.8.0_111]
> at java.math.BigDecimal.<init>(BigDecimal.java:806) [rt.jar:1.8.0_111]
> at oracle.jdbc.driver.T4CVarcharAccessor.StringToNUMBER(T4CVarcharAccessor.java:825)
> ... 31 more
> {code}
> *Customer impact*: Clients are not able to send large messages. Sending/receiving large messages is common customer use case. This blocks RFE EAP7-591.
> There is no workaround.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-5966) Validate requirement for modules previously exported by javax.ejb.api
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-5966?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-5966:
------------------------------------
It should be safe to remove the depndencies from the {{org.jboss.weld.core}} module (feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml). Weld subsystem module.xml does not contain the dependencies any more.
Note that this "blind addition" significantly affects the size of WildFly Swarm uberjar because {{org.omg.api}} depends on {{org.jboss.jts}} -> {{org.apache.activemq.artemis}} -> {{org.wildfly.extension.messaging-activemq}} -> {{org.jboss.as.weld}} etc etc.. So once you add any of the modules mentioned above the size grows significantly (brings EJB3, Hibernate, etc.).
> Validate requirement for modules previously exported by javax.ejb.api
> ---------------------------------------------------------------------
>
> Key: WFLY-5966
> URL: https://issues.jboss.org/browse/WFLY-5966
> Project: WildFly
> Issue Type: Task
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Jason Greene
>
> The WFLY-5922 fix removed the exporting of a number of modules from javax.ejb.api. That introduced some problems with modules that depended on those exported packages no longer having visibility to needed classes, so to prevent problems I blindly added a commit to the module.xml for each module that depended upon javax.ejb.api to add a dependency set like this:
> {code}
> <!-- TODO validate the need for these and remove if not needed.
> Prior to WFLY-5922 they were exported by javax.ejb.api. -->
> <module name="javax.api"/>
> <module name="javax.transaction.api"/>
> <module name="javax.xml.rpc.api"/>
> <module name="javax.rmi.api"/>
> <module name="org.omg.api"/>
> {code}
> If a module already had a dep on one of those, it's not in the block.
> This task is to check each of these modules and replace that block with normal dependency declarations for any that are truly needed.
> Affected modules:
> feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/javax/management/j2ee/api/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/spi/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jsr77/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/webservices/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/weld/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/xts/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb3/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/iiop-client/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/appclient/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/ejb/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/compensations/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/rts/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/txframework/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ws/common/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/xts/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/rts/main/module.xml
> The following modules were indirectly affected via their dependency on javaee.api, which in turn exports javax.ejb.api:
> feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/jberet/main/module.xml
> jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml
> jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml
>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8246) Colocated HA topology doesn't work with HTTP connectors and static cluster
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-8246?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil moved JBEAP-9143 to WFLY-8246:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8246 (was: JBEAP-9143)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JMS
(was: JMS)
Affects Version/s: (was: 7.1.0.DR12)
Affects Testing: (was: Regression)
> Colocated HA topology doesn't work with HTTP connectors and static cluster
> --------------------------------------------------------------------------
>
> Key: WFLY-8246
> URL: https://issues.jboss.org/browse/WFLY-8246
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> *Scenario:*
> * 2 EAPs configured in colocated shared store HA topology with HTTP connectors and static cluster
> * static cluster means that cluster-connection is defined by static-connectors property
> * both EAPs and standalone clients are started
> * after that receiver receives 120 messages, first EAP is shut down
> *Expectation:* Clients do failover to second EAP and continue in their work.
> *Reality*: Clients are not able to reconnect to backup server.
> During the whole test I see a lot of {{AMQ214023: HTTP Handshake failed}} errors.
> The same scenario works with Netty connectors.
> The same scenario works in dedicated topology.
> Priority of this issue is blocker because it is regression against previous versions of EAP 7.1.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-6695) JspTagTestCase fails on Windows
by Khuddus Abdul (JIRA)
[ https://issues.jboss.org/browse/WFLY-6695?page=com.atlassian.jira.plugin.... ]
Khuddus Abdul commented on WFLY-6695:
-------------------------------------
Facing the same issue.
> JspTagTestCase fails on Windows
> -------------------------------
>
> Key: WFLY-6695
> URL: https://issues.jboss.org/browse/WFLY-6695
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 10.1.0.CR1
> Environment: Windows 10, Oracle JDK 1.8.0_92
> Reporter: Frank Langelage
>
> build.bat clean install failed with
> -------------------------------------------------------------------------------
> Test set: org.jboss.as.test.integration.jsp.JspTagTestCase
> -------------------------------------------------------------------------------
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.768 sec <<< FAILURE! - in org.jboss.as.test.integration.jsp.JspTagTestCase
> test(org.jboss.as.test.integration.jsp.JspTagTestCase) Time elapsed: 0.486 sec <<< FAILURE!
> org.junit.ComparisonFailure: expected:<This is a header[
> <div>tag</div>
> Static content]
> > but was:<This is a header[
> <div>tag</div>
> Static content
> ]
> >
> at org.junit.Assert.assertEquals(Assert.java:115)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.jboss.as.test.integration.jsp.JspTagTestCase.test(JspTagTestCase.java:67)
> Replacing all occurence of "\n" with System.getProperty("line.separator") in the expected String solved the problem for me.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8245) AuthenticationContext should not be loaded from wildfly-config.xml automatically in deployment
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-8245?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-8245:
-------------------------------
Description:
In case when wildfly-config.xml is located in deployment and application server does not have configured default-authentication-context for Elytron subsystem, then AuthenticationContext is automatically parsed from wildfly-config.xml.
In case when default-authentication-context for Elytron subsystem is configured, then AuthenticationContext is correctly loaded from application server.
If this is intended then it should be reflect in documentation - it currently says that "... they can make use of a configuration file using the _parseAuthenticationClientConfiguration(URI)_ method ...", but in current implementation it is parsed automatically.
[~dlofthouse] Could you please clarify whether this is intended change or it is an issue?
was:
In case when wildfly-config.xml is located in deployment and application server does not have configured default-authentication-context for Elytron subsystem, then AuthenticationContext is automatically parsed from wildfly-config.xml.
This behavior was changed between EAP 7.1.0.DR11 and EAP 7.1.0.DR12 (try Steps to Reproduce with DR12 as well as DR11).
In case when default-authentication-context for Elytron subsystem is configured, then AuthenticationContext is correctly loaded from application server.
If this is intended then it should be reflect in documentation - it currently says that "... they can make use of a configuration file using the _parseAuthenticationClientConfiguration(URI)_ method ...", but in current implementation it is parsed automatically.
[~dlofthouse] Could you please clarify whether this is intended change or it is an issue?
> AuthenticationContext should not be loaded from wildfly-config.xml automatically in deployment
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-8245
> URL: https://issues.jboss.org/browse/WFLY-8245
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
>
> In case when wildfly-config.xml is located in deployment and application server does not have configured default-authentication-context for Elytron subsystem, then AuthenticationContext is automatically parsed from wildfly-config.xml.
> In case when default-authentication-context for Elytron subsystem is configured, then AuthenticationContext is correctly loaded from application server.
> If this is intended then it should be reflect in documentation - it currently says that "... they can make use of a configuration file using the _parseAuthenticationClientConfiguration(URI)_ method ...", but in current implementation it is parsed automatically.
> [~dlofthouse] Could you please clarify whether this is intended change or it is an issue?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8245) AuthenticationContext should not be loaded from wildfly-config.xml automatically in deployment
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-8245:
----------------------------------
Summary: AuthenticationContext should not be loaded from wildfly-config.xml automatically in deployment
Key: WFLY-8245
URL: https://issues.jboss.org/browse/WFLY-8245
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
Priority: Critical
In case when wildfly-config.xml is located in deployment and application server does not have configured default-authentication-context for Elytron subsystem, then AuthenticationContext is automatically parsed from wildfly-config.xml.
This behavior was changed between EAP 7.1.0.DR11 and EAP 7.1.0.DR12 (try Steps to Reproduce with DR12 as well as DR11).
In case when default-authentication-context for Elytron subsystem is configured, then AuthenticationContext is correctly loaded from application server.
If this is intended then it should be reflect in documentation - it currently says that "... they can make use of a configuration file using the _parseAuthenticationClientConfiguration(URI)_ method ...", but in current implementation it is parsed automatically.
[~dlofthouse] Could you please clarify whether this is intended change or it is an issue?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JGRP-2159) Delta view cannot be installed
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2159?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2159:
--------------------------------
Here's how this can be reproduced (unit test: {{DeltaViewTest}}):
* J is the coordinator and has view J|0=K
* K joins and sends a JOIN-REQ to J
* J creates new view J|1=J,K (setting {{ltime}} to 1) and multicasts it, but the multicast is delayed (e.g. dropped and retransmitted)
* Finally, J sends a JOIN-RSP with view J|1 to K
* Before receiving the new view, K times out and sends another JOIN-REQ to J
* K receives view J|1 and installs it
* J creates a new view J|2=J,K (setting {{ltime}} to 2) and multicasts it. The multicast is again delayed.
* J sends a JOIN-RSP to K with view J|2, K installs it
* J finally gets the first view multicast and installs J|1=J,K
* New member L sends a JOIN-RSP to J
* J creates view J|3=JKL and multicasts it, and then sends a JOIN-RSP to L
* The multicast of J|3 is a *DeltaView* with ref-view-id=J|1 and joiners=L
* L installs the new view
* J installs the new view J|3
* However, K cannot install the new view as ref-view-id=J|1 is not known as it has view=J|2!
SOLUTION:
* The reason why spurious view J|2 is sent to K is that J hasn't yet installed view J|1 locally. If that was the case, it would see that K is already a member and simply resend view J|1, instead of creating view J|2.
* We therefore need to make sure a new view is installed in the coordinator *before* multicasting it, and this can be done by setting {{install_view_locally_first}} to true by default (or even removing the attribute)
* As a second line of defense, make the recepient of a DeltaView that cannot be installed send a request to the coordinator to resend the view as a full- instead of a delta- view.
* J creates new view J|3=JL
> Delta view cannot be installed
> ------------------------------
>
> Key: JGRP-2159
> URL: https://issues.jboss.org/browse/JGRP-2159
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.1, 4.0.1
>
> Attachments: discarded_delta_view.log
>
>
> A DeltaView cannot be installed because the ref view-id is not the current view-id.
> Looking at the view sequence for members J, K and L:
> {noformat}
> 19:22:54,278 DEBUG (testng-Test:[]) [GMS] J: installing view [J|0] (1) [J]
> 19:22:56,519 DEBUG (testng-Test:[]) [GMS] K: installing view [J|1] (2) [J, K]
> 19:22:56,572 DEBUG (jgroups-7,J:[]) [GMS] J: installing view [J|1] (2) [J, K]
> 19:22:56,590 DEBUG (jgroups-5,K:[]) [GMS] K: installing view [J|2] (2) [J, K]
> 19:22:58,585 DEBUG (jgroups-5,J:[]) [GMS] J: installing view [J|3] (3) [J, K, L]
> 19:23:00,603 DEBUG (testng-Test:[]) [GMS] L: installing view [J|3] (3) [J, K, L]
> {noformat}
> K cannot install DeltaView J|3 because it has view J|2 but the DeltaView has ref view-id J|1.
> The reason is that J|2 was apparently installed *only* at K (but not at coordinator J1!), despite it being the same view as J|1.
> We need to look into why J|2 was installed at K only. Second line of defense: when a DeltaView cannot be installed, send a message to the view sender (coord) and solicit the full view instead.
> See the attached log.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JGRP-2159) Delta view cannot be installed
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2159?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2159 at 2/27/17 2:44 AM:
---------------------------------------------------------
Workaround: {{GMS.use_delta_views="false"}} or {{GMS.install_view_locally_first="true"}}
was (Author: belaban):
Workaround: {{GMS.use_delta_views="false"}}
> Delta view cannot be installed
> ------------------------------
>
> Key: JGRP-2159
> URL: https://issues.jboss.org/browse/JGRP-2159
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.1, 4.0.1
>
> Attachments: discarded_delta_view.log
>
>
> A DeltaView cannot be installed because the ref view-id is not the current view-id.
> Looking at the view sequence for members J, K and L:
> {noformat}
> 19:22:54,278 DEBUG (testng-Test:[]) [GMS] J: installing view [J|0] (1) [J]
> 19:22:56,519 DEBUG (testng-Test:[]) [GMS] K: installing view [J|1] (2) [J, K]
> 19:22:56,572 DEBUG (jgroups-7,J:[]) [GMS] J: installing view [J|1] (2) [J, K]
> 19:22:56,590 DEBUG (jgroups-5,K:[]) [GMS] K: installing view [J|2] (2) [J, K]
> 19:22:58,585 DEBUG (jgroups-5,J:[]) [GMS] J: installing view [J|3] (3) [J, K, L]
> 19:23:00,603 DEBUG (testng-Test:[]) [GMS] L: installing view [J|3] (3) [J, K, L]
> {noformat}
> K cannot install DeltaView J|3 because it has view J|2 but the DeltaView has ref view-id J|1.
> The reason is that J|2 was apparently installed *only* at K (but not at coordinator J1!), despite it being the same view as J|1.
> We need to look into why J|2 was installed at K only. Second line of defense: when a DeltaView cannot be installed, send a message to the view sender (coord) and solicit the full view instead.
> See the attached log.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months