[JBoss JIRA] (WFLY-9375) META-INF/services are always accessible from dependencies
by Alexander Kudrevatykh (JIRA)
Alexander Kudrevatykh created WFLY-9375:
-------------------------------------------
Summary: META-INF/services are always accessible from dependencies
Key: WFLY-9375
URL: https://issues.jboss.org/browse/WFLY-9375
Project: WildFly
Issue Type: Bug
Affects Versions: 11.0.0.CR1, 10.1.0.Final, 10.0.0.Final
Reporter: Alexander Kudrevatykh
Assignee: Jason Greene
I found regression in Wildfly 10.1 (10.0 and 11 CR1 also affected) - META-INF/services entries are accesible from war dependencies, even if not marked as "import"
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3316) Server fails to start after submitting invalid security attributes
by Martin Stefanko (JIRA)
Martin Stefanko created WFCORE-3316:
---------------------------------------
Summary: Server fails to start after submitting invalid security attributes
Key: WFCORE-3316
URL: https://issues.jboss.org/browse/WFCORE-3316
Project: WildFly Core
Issue Type: Bug
Components: CLI
Affects Versions: 3.0.3.Final
Reporter: Martin Stefanko
Assignee: Martin Stefanko
Priority: Critical
Server fails to start after submitting invalid security attributes values for remoting http connector (e.g QOP, strength)
Only fix for the configuration is to manually change the XML file directly
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (JGRP-2220) Two nodes can own a same lock at same time
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2220?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2220:
---------------------------
Fix Version/s: 4.0.7
> Two nodes can own a same lock at same time
> ------------------------------------------
>
> Key: JGRP-2220
> URL: https://issues.jboss.org/browse/JGRP-2220
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4
> Environment: Two nodes cluster with jgroup 3.4.0 alpha2
> Reporter: Xiao Li
> Assignee: Bela Ban
> Fix For: 4.0.7
>
>
> We have a two node cluster with following protocol stack for distributed lock.
> lock.protocolStack=UDP(bind_addr=myIP;bind_port=31562;mcast_addr=239.255.166.17;mcast_port=31569;ip_ttl=32;mcast_send_buf_size=150000;mcast_recv_buf_size=80000):PING(timeout=2000;num_initial_members=3):MERGE2(min_interval=5000;max_interval=10000):FD_ALL(interval=5000;timeout=20000):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(retransmit_timeout=300,600,1200,2400,4800):UNICAST(timeout=5000):pbcast.STABLE(desired_avg_gossip=20000):FRAG(frag_size=8096):pbcast.GMS(join_timeout=5000;print_local_addr=true):CENTRAL_LOCK(num_backups=2)
> We use the following call to get a lock for one node.
> lock = lockManager.getLock(lockId);
> lock.tryLock(Long.MAX_VALUE, TimeUnit.MILLISECONDS); where lockManager is an object of LockService and lock is a Lock object.
> Another node is waiting on the lock at same method call. When the node owning the lock release the lock with the call lock.unlock(), the node waiting on the lock gets the lock and the lock is deleted from the node owned the lock. When the JVM for the node that released the lock restarted, it can also get same lock. So two nodes own the lock at same time.
> If I don't call lock.unlock() before shutting down the node, it waits for the lock as expected when its JVM starts up.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (AG-35) Use ServiceLoader to discover implementations
by Luis Barreiro (JIRA)
[ https://issues.jboss.org/browse/AG-35?page=com.atlassian.jira.plugin.syst... ]
Luis Barreiro resolved AG-35.
-----------------------------
Resolution: Done
Three options as to how generate the service descriptor :
# by hand, in resources/META-INF folder
# using a maven plugin (com.github.kristofa/service-plugin-loader)
# using an annotation (org.kohsuke/metainf-services)
Decided to go for a maven plugin, for being the cleanest way, although it does not seem to integrate with IDEs as well as an annotation does.
> Use ServiceLoader to discover implementations
> ---------------------------------------------
>
> Key: AG-35
> URL: https://issues.jboss.org/browse/AG-35
> Project: Agroal
> Issue Type: Bug
> Components: api, hikari, pool
> Affects Versions: 0.2
> Reporter: Luis Barreiro
> Assignee: Luis Barreiro
> Fix For: 0.3
>
>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (JGRP-2220) Two nodes can own a same lock at same time
by Xiao Li (JIRA)
Xiao Li created JGRP-2220:
-----------------------------
Summary: Two nodes can own a same lock at same time
Key: JGRP-2220
URL: https://issues.jboss.org/browse/JGRP-2220
Project: JGroups
Issue Type: Bug
Affects Versions: 3.4
Environment: Two nodes cluster with jgroup 3.4.0 alpha2
Reporter: Xiao Li
Assignee: Bela Ban
We have a two node cluster with following protocol stack for distributed lock.
lock.protocolStack=UDP(bind_addr=myIP;bind_port=31562;mcast_addr=239.255.166.17;mcast_port=31569;ip_ttl=32;mcast_send_buf_size=150000;mcast_recv_buf_size=80000):PING(timeout=2000;num_initial_members=3):MERGE2(min_interval=5000;max_interval=10000):FD_ALL(interval=5000;timeout=20000):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(retransmit_timeout=300,600,1200,2400,4800):UNICAST(timeout=5000):pbcast.STABLE(desired_avg_gossip=20000):FRAG(frag_size=8096):pbcast.GMS(join_timeout=5000;print_local_addr=true):CENTRAL_LOCK(num_backups=2)
We use the following call to get a lock for one node.
lock = lockManager.getLock(lockId);
lock.tryLock(Long.MAX_VALUE, TimeUnit.MILLISECONDS); where lockManager is an object of LockService and lock is a Lock object.
Another node is waiting on the lock at same method call. When the node owning the lock release the lock with the call lock.unlock(), the node waiting on the lock gets the lock and the lock is deleted from the node owned the lock. When the JVM for the node that released the lock restarted, it can also get same lock. So two nodes own the lock at same time.
If I don't call lock.unlock() before shutting down the node, it waits for the lock as expected when its JVM starts up.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months