[JBoss JIRA] (JBCOMMON-131) Setting cache timeout for JAAS under jboss-eap-6.1 does not work
by Artur Mioduszewski (JIRA)
Artur Mioduszewski created JBCOMMON-131:
-------------------------------------------
Summary: Setting cache timeout for JAAS under jboss-eap-6.1 does not work
Key: JBCOMMON-131
URL: https://issues.jboss.org/browse/JBCOMMON-131
Project: JBoss Common
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: jboss-eap-6.1
Reporter: Artur Mioduszewski
Assignee: Dimitris Andreadis
When: cache-type="default" in security-domain configuration -> authentication works correctly.
When below configuration is used -> JAAS authentication stops to work (on JBoss console there are not any errors)
<code>
...
<security-domain name="myJaasDomain" cache-type="infinispan">
<security-domains>
<security-domain name="DigitalSignalWS" cache-type="default">
<authentication>
<login-module code="Database" flag="required">
<module-option name="dsJndiName" value="java:jboss/datasources/digital-signal-service-dev-ws-DS"/>
<module-option name="principalsQuery" value="SELECT l.PASSWORD FROM LOGIN l WHERE l.USERNAME=?"/>
<module-option name="rolesQuery" value="SELECT ar.NAME, 'Roles' FROM login l, login_access_group lg, access_group g, access_group_s_access_right ga, s_access_right ar WHERE l.username = ? AND l.id = lg.login_ID AND lg.groups_ID = g.id AND g.ID = ga.access_group_ID AND ga.accessRights_ID = ar.ID"/>
<module-option name="hashAlgorithm" value="MD5"/>
<module-option name="hashEncoding" value="base64"/>
<module-option name="unauthenticatedIdentity" value="guest"/>
</login-module>
</authentication>
</security-domain>
...
<subsystem xmlns="urn:jboss:domain:infinispan:1.2" default-cache-container="web">
<cache-container name="cluster" aliases="ha-partition" default-cache="default">
<transport lock-timeout="60000"/>
<replicated-cache name="default" mode="SYNC" batching="true">
<locking isolation="REPEATABLE_READ"/>
</replicated-cache>
</cache-container>
<cache-container name="web" aliases="standard-session-cache" default-cache="repl">
<transport lock-timeout="60000"/>
<replicated-cache name="repl" mode="ASYNC" batching="true">
<file-store/>
</replicated-cache>
<replicated-cache name="sso" mode="SYNC" batching="true"/>
<distributed-cache name="dist" mode="ASYNC" batching="true">
<file-store/>
</distributed-cache>
</cache-container>
<cache-container name="ejb" aliases="sfsb sfsb-cache" default-cache="repl">
<transport lock-timeout="60000"/>
<replicated-cache name="repl" mode="ASYNC" batching="true">
<file-store/>
</replicated-cache>
<replicated-cache name="remote-connector-client-mappings" mode="SYNC" batching="true"/>
<distributed-cache name="dist" mode="ASYNC" batching="true">
<file-store/>
</distributed-cache>
</cache-container>
<cache-container name="hibernate" default-cache="local-query">
<transport lock-timeout="60000"/>
<local-cache name="local-query">
<transaction mode="NONE"/>
<expiration max-idle="100000"/>
</local-cache>
<invalidation-cache name="entity" mode="SYNC">
<transaction mode="NON_XA"/>
<expiration max-idle="100000"/>
</invalidation-cache>
<replicated-cache name="timestamps" mode="ASYNC">
<transaction mode="NONE"/>
</replicated-cache>
</cache-container>
</subsystem>
...
<code>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (DROOLS-320) Drools plugin Rete Tree viewer does not work with timer and || operator.
by Duncan Doyle (JIRA)
Duncan Doyle created DROOLS-320:
-----------------------------------
Summary: Drools plugin Rete Tree viewer does not work with timer and || operator.
Key: DROOLS-320
URL: https://issues.jboss.org/browse/DROOLS-320
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.0.0.CR5
Environment: Mac OS-X 10.9, JBoss Developer Studio 7, Oracle Hotspot 1.7.0_45, Drools-jBPM Eclipse plugin 6.0.0.CR5
Reporter: Duncan Doyle
Assignee: Mark Proctor
See this example project: https://github.com/DuncanDoyle/DroolsReteViewer , which is based on the Drools Eclipse sample project.
The 'src/main/resources/rules/Sample.drl' is a valid DRL file, but it cannot be opened in the Rete Tree because of:
- the 'timer (int: 10s)' definition in rule "GoodBye-Timer". This gives the error:
Rete Tree Build Error!
Reason:
org.drools.core.RuntimeDroolsException:
java.lang.reflect.InvocationTargetException: [Rete(0)]
- the '||' operator in the rule "Hello World-Or". This gives the error:
Rete Tree Build Error!
Reason:
java.lang.NullPointerException: null
This forces us to change our rule definition files to be able to inspect the Rete Tree (which we require to analyse the tree for possible optimizations).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2203) Error deploying multiple *-ds.xml files
by Nick Howes (JIRA)
[ https://issues.jboss.org/browse/WFLY-2203?page=com.atlassian.jira.plugin.... ]
Nick Howes commented on WFLY-2203:
----------------------------------
No, I had to switch to JBoss AS 7 to deploy my app.
> Error deploying multiple *-ds.xml files
> ---------------------------------------
>
> Key: WFLY-2203
> URL: https://issues.jboss.org/browse/WFLY-2203
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.0.0.Beta1
> Reporter: Nick Howes
> Assignee: Stefano Maestri
> Priority: Minor
> Fix For: 8.0.0.Final
>
>
> Our individual *-ds.xml datasources were all deploying fine in Alpha4 but in the Beta1 nightlies this error appears on startup:
> {noformat}
> 15:07:52,111 ERROR [org.jboss.msc.service] (MSC service thread 1-4) MSC000002: Invocation of listener "org.jboss.as.connector.subsystems.datasources.D
> ataSourceStatisticsListener@7d18ac99" failed: java.lang.IllegalArgumentException: JBAS014742: A node is already registered at '(deployment => *)(subsy
> stem => datasources)(data-source => *)(statistics => jdbc)'
> at org.jboss.as.controller.registry.NodeSubregistry.register(NodeSubregistry.java:86) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1
> -SNAPSHOT]
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:149) [wildfly-controller-8
> .0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.registry.AbstractResourceRegistration.registerSubModel(AbstractResourceRegistration.java:90) [wildfly-controller-8.
> 0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.connector.subsystems.datasources.DataSourceStatisticsListener.transition(DataSourceStatisticsListener.java:72) [wildfly-connec
> tor-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> {noformat}
> Our datasource files look like this. I haven't tried putting all the datasource elements into one file.
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <datasources>
> <datasource jndi-name="java:/AlphaDS" enabled="true" use-java-context="true" pool-name="AlphaDS">
> <connection-url>jdbc:oracle:thin://@db-host:1666/dev-db</connection-url>
> <driver>oracle</driver>
> <security>
> <user-name>XXX</user-name>
> <password>YYY</password>
> </security>
> <connection-property name="defaultNChar">true</connection-property>
> </datasource>
> </datasources>
> {code}
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <datasources>
> <datasource jndi-name="java:/BetaDS" enabled="true" use-java-context="true" pool-name="BetaDS">
> <connection-url>jdbc:oracle:thin://@db-host:1666/dev-db</connection-url>
> <driver>oracle</driver>
> <security>
> <user-name>XXX</user-name>
> <password>YYY</password>
> </security>
> <connection-property name="defaultNChar">true</connection-property>
> </datasource>
> </datasources>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JGRP-1675) Threads stuck in FlowControl.decrementIfEnoughCredits
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.... ]
Radim Vansa edited comment on JGRP-1675 at 11/5/13 9:57 AM:
------------------------------------------------------------
The credits (REPLENISH message) is not dropped, it is not sent at all. As OOB TP is depleted, there is no delivered message which would trigger the REPLENISH. The CREDIT_REQUEST, that could trigger the REPLENISH, is not delivered either (processed in INT TP) because it is moved to UNICASTx tables and waits for sequential delivery to FlowControl after the rest of OOB messages.
was (Author: rvansa):
The credits (REPLENISH messagge) is not dropped, it is not sent at all. As OOB TP is depleted, there is no delivered message which would trigger the REPLENISH. The CREDIT_REQUEST, that could trigger the REPLENISH, is not delivered either (processed in INT TP) because it is moved to UNICASTx tables and waits for sequential delivery to FlowControl after the rest of OOB messages.
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
> Key: JGRP-1675
> URL: https://issues.jboss.org/browse/JGRP-1675
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: jgroups-udp-radim.xml, RemoteGetStressTest.java, UPerf2.java
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JGRP-1729) Implement a SASL AuthToken
by Tristan Tarrant (JIRA)
Tristan Tarrant created JGRP-1729:
-------------------------------------
Summary: Implement a SASL AuthToken
Key: JGRP-1729
URL: https://issues.jboss.org/browse/JGRP-1729
Project: JGroups
Issue Type: Feature Request
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 3.5
Implementing a SASL AuthToken will give us the ability to use whatever SASL mechs are offered by the underlying platform without introducing new dependencies. It would also replace many of the currently provided AuthToken implementations (MD5, X509, Krb5) with a more secure, flexible implementation (e.g. safe from replay attacks)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JGRP-1675) Threads stuck in FlowControl.decrementIfEnoughCredits
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on JGRP-1675:
-----------------------------------
The credits (REPLENISH messagge) is not dropped, it is not sent at all. As OOB TP is depleted, there is no delivered message which would trigger the REPLENISH. The CREDIT_REQUEST, that could trigger the REPLENISH, is not delivered either (processed in INT TP) because it is moved to UNICASTx tables and waits for sequential delivery to FlowControl after the rest of OOB messages.
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
> Key: JGRP-1675
> URL: https://issues.jboss.org/browse/JGRP-1675
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: jgroups-udp-radim.xml, RemoteGetStressTest.java, UPerf2.java
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JGRP-1675) Threads stuck in FlowControl.decrementIfEnoughCredits
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1675:
--------------------------------
UPerf2's GET request uses a GET_FIRST on 2 members. This clogs up the receivers' OOB thread pools, and thus credits are dropped. Sending the CREDIT_REQUESTS as OOB fixes this, but the performance is still slow because of the exhaused OOB pool.
I suggest send the GET as a unicast to the owner and if the owner doesn't respond within N ms (perhaps computed as 30% over the rolling avg time for GETs), then try the other owner (essentially staggered GETs as suggested by Manik).
Alternatively, a GET could be an anycast, but the target list should include only the primary owner, conceptually this is the same as above.
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
> Key: JGRP-1675
> URL: https://issues.jboss.org/browse/JGRP-1675
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: jgroups-udp-radim.xml, RemoteGetStressTest.java, UPerf2.java
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2426) Easily accessible static information describing the release
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka edited comment on WFLY-2426 at 11/5/13 8:30 AM:
-------------------------------------------------------------
I think we had a discussion about this (regarding EAP) with Paul Gier, and the problem was with the fact that one never knows what will end up as a product, so some information needs to be added after it pops out of Brew/Mead. Bringing Paul's attention.
was (Author: ozizka):
I think we had a discussion about this (regarding EAP) with Paul Gier, and the problem was with the fact that one never knows what will end up as a product, so the information is added when it pops out of Brew/Mead. Bringing Paul's attention.
> Easily accessible static information describing the release
> -----------------------------------------------------------
>
> Key: WFLY-2426
> URL: https://issues.jboss.org/browse/WFLY-2426
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
>
> Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly.
> This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build.
> The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity.
> The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution?
> The solution to this issue should consider the implications for the patching tool.
> [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... for
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2426) Easily accessible static information describing the release
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka commented on WFLY-2426:
------------------------------------
By the way, I have an identification mechanism in WindRide - based on CRC32 comparison of jars. That came out of necessity to identify any version, since EAP 5, and also AS releases. Can be also applied to other servers, or generally any set of files. It also contains some kind of heuristics to deal with CP's and one-offs, and files replaced by user. The information is then carried in files within the WindRide project, as there was nothing to rely on in the scanned distributions.
Examples: https://github.com/OndraZizka/jboss-migration/tree/master/engine/src/main...
Is this a viable alternative, or are you intending to add a spefic file?
> Easily accessible static information describing the release
> -----------------------------------------------------------
>
> Key: WFLY-2426
> URL: https://issues.jboss.org/browse/WFLY-2426
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
>
> Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly.
> This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build.
> The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity.
> The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution?
> The solution to this issue should consider the implications for the patching tool.
> [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... for
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months