[JBoss JIRA] (WFLY-5621) Cleanup HornetQ xsd files in "docs/schema" directory
by Wolfgang Knauf (JIRA)
Wolfgang Knauf created WFLY-5621:
------------------------------------
Summary: Cleanup HornetQ xsd files in "docs/schema" directory
Key: WFLY-5621
URL: https://issues.jboss.org/browse/WFLY-5621
Project: WildFly
Issue Type: Bug
Components: Server
Affects Versions: 10.0.0.CR4
Reporter: Wolfgang Knauf
Assignee: Jason Greene
Priority: Minor
The download zip for WildFly 10.0CR4 contains the xsd files for HornetQ messaging configurations in "docs/schema". Those are obsoleted by ActiveMQ and should be removed.
-jboss-as-messaging-deployment_1_0.xsd (deployment of a "-jms.xml" file according to this old schema will fail with an error anyway), replaced by "wildfly-messaging-activemq-deployment_1_0.xsd")
-jboss-as-messaging_x_y.xsd (server configuration files, replaced by "wildfly-messaging-activemq_1_0.xsd").
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (WFLY-5620) Fix the documentation in wildfly-singleton_1_0.xsd
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-5620:
----------------------------------
Summary: Fix the documentation in wildfly-singleton_1_0.xsd
Key: WFLY-5620
URL: https://issues.jboss.org/browse/WFLY-5620
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.0.0.Beta2
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Fix For: 10.0.0.Final
https://github.com/wildfly/wildfly/blob/master/clustering/singleton/exten...
1. Attributes "name" and "cache-container" have the same documentation.
2. Attribute "quorum" is missing documentation.
{code:xml}
<xs:complexType name="singleton-policy">
<!-- ... -->
<xs:attribute name="name" type="xs:string" use="required">
<xs:annotation>
<xs:documentation>Identifies the cache-container used to back the singleton deployment policy.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="cache-container" type="xs:string" use="required">
<xs:annotation>
<xs:documentation>Identifies the cache-container used to back the singleton deployment policy.</xs:documentation>
</xs:annotation>
</xs:attribute>
<!-- ... -->
<xs:attribute name="quorum" type="xs:integer" default="1">
<xs:annotation>
<xs:documentation></xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:complexType>
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (WFLY-5352) Fix the documentation in wildfly-singleton_1_0.xsd
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5352?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-5352:
-------------------------------
Fix Version/s: 10.0.0.Final
(was: 10.0.0.CR1)
> Fix the documentation in wildfly-singleton_1_0.xsd
> --------------------------------------------------
>
> Key: WFLY-5352
> URL: https://issues.jboss.org/browse/WFLY-5352
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Beta2
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
> Fix For: 10.0.0.Final
>
>
> https://github.com/wildfly/wildfly/blob/master/clustering/singleton/exten...
> 1. Attributes "name" and "cache-container" have the same documentation.
> 2. Attribute "quorum" is missing documentation.
> {code:xml}
> <xs:complexType name="singleton-policy">
> <!-- ... -->
> <xs:attribute name="name" type="xs:string" use="required">
> <xs:annotation>
> <xs:documentation>Identifies the cache-container used to back the singleton deployment policy.</xs:documentation>
> </xs:annotation>
> </xs:attribute>
> <xs:attribute name="cache-container" type="xs:string" use="required">
> <xs:annotation>
> <xs:documentation>Identifies the cache-container used to back the singleton deployment policy.</xs:documentation>
> </xs:annotation>
> </xs:attribute>
> <!-- ... -->
> <xs:attribute name="quorum" type="xs:integer" default="1">
> <xs:annotation>
> <xs:documentation></xs:documentation>
> </xs:annotation>
> </xs:attribute>
> </xs:complexType>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (JGRP-1825) ReadWriteLock
by Manuel Dominguez Sarmiento (JIRA)
[ https://issues.jboss.org/browse/JGRP-1825?page=com.atlassian.jira.plugin.... ]
Manuel Dominguez Sarmiento commented on JGRP-1825:
--------------------------------------------------
The following articles give a good overview of the current design:
http://codespot.net/2014/02/03/hibernate-caching-strategies/
http://clustermania.blogspot.com.ar/2009/07/with-read-write-hibernate-2nd...
However, the soft-lock algorithm for the READ-WRITE strategy requires that, for being effective in a cluster:
a) Updates to the cluster are replicated synchronously. This is something that the Ehcache-JGroups replication module does somewhat poorly, because even though "synchronous" replication is supported, the implementation does not wait for the RPC acknowledgement - we've patched this some years ago and we maintain our own fork, since Terracotta stopped any this of development of clustering solutions for Ehcache which do not involve their commercial offerings.
b) Read-write locks guarding access the the replicated synchronous cache, otherwise transactional consistency is compromised.
> ReadWriteLock
> -------------
>
> Key: JGRP-1825
> URL: https://issues.jboss.org/browse/JGRP-1825
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6
>
> Attachments: JgroupTest.zip
>
>
> Adds a read/write lock to LockService. The impl is attached
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (WFLY-4957) After failback backup prints warnings to log
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-4957?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-4957:
------------------------------
Security: (was: Red Hat Internal)
> After failback backup prints warnings to log
> --------------------------------------------
>
> Key: WFLY-4957
> URL: https://issues.jboss.org/browse/WFLY-4957
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Alpha5
> Environment: Fedora 22
> openjdk 8
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Critical
> Attachments: master.xml, slave.xml
>
>
> 15:34:59,123 WARN [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 4) WFLYMSGAMQ0004: Failed to destroy queue: ExpiryQueue: java.lang.IllegalStateException: Cannot access JMS Server, core server is not yet active
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.checkInitialised(JMSServerManagerImpl.java:1640)
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.access$1100(JMSServerManagerImpl.java:101)
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl$3.runException(JMSServerManagerImpl.java:752)
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.runAfterActive(JMSServerManagerImpl.java:1847)
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.removeQueueFromBindingRegistry(JMSServerManagerImpl.java:741)
> at org.wildfly.extension.messaging.activemq.jms.JMSQueueService$2.run(JMSQueueService.java:101)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 15:34:59,123 WARN [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 68) WFLYMSGAMQ0004: Failed to destroy queue: AsyncQueue: java.lang.IllegalStateException: Cannot access JMS Server, core server is not yet active
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.checkInitialised(JMSServerManagerImpl.java:1640)
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.access$1100(JMSServerManagerImpl.java:101)
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl$3.runException(JMSServerManagerImpl.java:752)
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.runAfterActive(JMSServerManagerImpl.java:1847)
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.removeQueueFromBindingRegistry(JMSServerManagerImpl.java:741)
> at org.wildfly.extension.messaging.activemq.jms.JMSQueueService$2.run(JMSQueueService.java:101)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 15:34:59,123 WARN [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 9) WFLYMSGAMQ0004: Failed to destroy queue: DLQ: java.lang.IllegalStateException: Cannot access JMS Server, core server is not yet active
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.checkInitialised(JMSServerManagerImpl.java:1640)
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.access$1100(JMSServerManagerImpl.java:101)
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl$3.runException(JMSServerManagerImpl.java:752)
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.runAfterActive(JMSServerManagerImpl.java:1847)
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.removeQueueFromBindingRegistry(JMSServerManagerImpl.java:741)
> at org.wildfly.extension.messaging.activemq.jms.JMSQueueService$2.run(JMSQueueService.java:101)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (JGRP-1825) ReadWriteLock
by Manuel Dominguez Sarmiento (JIRA)
[ https://issues.jboss.org/browse/JGRP-1825?page=com.atlassian.jira.plugin.... ]
Manuel Dominguez Sarmiento commented on JGRP-1825:
--------------------------------------------------
Yes, we've had our fair number of issues with LockService handling partitions poorly due to some nodes going into extended GC cycles and being kicked out of the cluster.
Specifically we are working on an improved EhcacheRegionFactory for READ-WRITE caching on Hibernate using Ehcache together with JGroups replication. The built-in Ehcache-Hibernate integration does not provide consitency guarantees on clustered/replicated scenarios, unless you go with their commercial offering (Terracotta BigMemory). We are also considering Infinispan, but we have a huge codebase that relies on Ehcache+JGroups, so we're trying to improve the existing EhcacheRegionFactory. For this we need reliable distributed read-write locks.
> ReadWriteLock
> -------------
>
> Key: JGRP-1825
> URL: https://issues.jboss.org/browse/JGRP-1825
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6
>
> Attachments: JgroupTest.zip
>
>
> Adds a read/write lock to LockService. The impl is attached
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (WFLY-5618) HTTP Authentication Basic header is case sensitive
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-5618?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-5618:
-----------------------------------
Description:
I wrote client code to login to a rest service with security-constraint. The client code must use an HTTP header of Authorization: Basic [Base 64 username:password]. If 'Basic' is sent as uppercase 'BASIC' it didn't work, but if sent as 'Basic' then it did work. I don't think the HTTP header fields should be case sensitive.
https://tools.ietf.org/rfc/rfc2617.txt
was:
I wrote client code to login to a rest service with security-constraint. The client code must use an HTTP header of Authorization: Basic [Base 64 username:password]. If 'Basic' is sent as uppercase 'BASIC' it didn't work, but if sent as 'Basic' then it did work. I don't think the HTTP header fields should be case sensitive.
More info on HTTP authorization: http://www.httpwatch.com/httpgallery/authentication/
> HTTP Authentication Basic header is case sensitive
> --------------------------------------------------
>
> Key: WFLY-5618
> URL: https://issues.jboss.org/browse/WFLY-5618
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 9.0.2.Final
> Environment: Wildfly 9.0.1.Final.
> Reporter: Karl Nicholas
> Assignee: Darran Lofthouse
> Labels: authorization, http, security-constraint
>
> I wrote client code to login to a rest service with security-constraint. The client code must use an HTTP header of Authorization: Basic [Base 64 username:password]. If 'Basic' is sent as uppercase 'BASIC' it didn't work, but if sent as 'Basic' then it did work. I don't think the HTTP header fields should be case sensitive.
> https://tools.ietf.org/rfc/rfc2617.txt
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months