[JBoss JIRA] Created: (JGRP-416) MergeView processing fails for Multiplexer channel
by Jerry Gauthier (JIRA)
MergeView processing fails for Multiplexer channel
--------------------------------------------------
Key: JGRP-416
URL: http://jira.jboss.com/jira/browse/JGRP-416
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4.1
Reporter: Jerry Gauthier
Assigned To: Bela Ban
When I simulate a cluster failure and restart using a Multiplexer channel, the merge process fails in JGroups with an UnsupportedOperationException in Multiplexer.mergeServiceState(). The stack trace is as follows.
ERROR [org.jgroups.mux.Multiplexer] problems handling merge view java.lang.UnsupportedOperationException
at org.jgroups.util.UnmodifiableVector.retainAll(UnmodifiableVector.java:158)
at org.jgroups.mux.Multiplexer.mergeServiceState(Multiplexer.java:867)
at org.jgroups.mux.Multiplexer.handleMergeView(Multiplexer.java:812)
at org.jgroups.mux.Multiplexer.access$200(Multiplexer.java:21)
at org.jgroups.mux.Multiplexer$1.run(Multiplexer.java:287)
I looked at the relevant JGroups code and it appears that JGroups uses a MergeView object that always returns an UnmodifiableVector when MergeView.getMembers() is invoked. The Multiplexer.mergeServiceState() method invokes MergeView.getMembers() followed by UnmodifiableVector(.retainAll(), causing the exception to occur.
This problem can be replicated by executing DRMTestCase in JBossAS 5.0. The error occurs in DRMTestCase.isMasterReplica().
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 3 months
[JBoss JIRA] Created: (JGRP-348) UNICAST: incorrect sequence numbers after merge if subgroups didn't completely exclude each other
by Bela Ban (JIRA)
UNICAST: incorrect sequence numbers after merge if subgroups didn't completely exclude each other
-------------------------------------------------------------------------------------------------
Key: JGRP-348
URL: http://jira.jboss.com/jira/browse/JGRP-348
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.5
Mail from David Foregt:
Hi Bela,
Still have an issue with JGroup 2.4 with UNICAST after applying your
recommended settings. We spent more time analyzing the issue and found the
exact scenario that cause the problem:
- We have multiple nodes running on machine A (a1, a2, a3, a4...a15) an one
node running on machine B (b1).
- b1 node is started first (coord) then all a's nodes are started.
When all nodes are active in the group we disconnected machine A from the
network.
- After ~10 sec all a's see b1 as dead and a new view is propagated to all
a's nodes and connection table for b1 entry is cleared for all a's nodes.
- b1 start seeing a's node as dead one by one every ~10 sec (as define by FD
/ VERIFY_SUSPECT) after 30 sec b1's view is (a4, a5...a15) and we
reconnected the network cable on machine A. (b1 connection table was cleared
for only a1...a3)
- After A reconnect to the network a merge was done and all nodes are back
in the group and are able to exchange Multicast message.
- Because b1 did not detect a4...a15 as dead when it send a unicast message
to those nodes the seqno has not been reset to 1. When a4 receive the first
unicast message from b1 (because its connection table was cleared for b1) it
create at line 453 of UNICAST a new AckReceiverWindow with initial_seqno = 1
and add the received message (that has a seqno > 1) in the new
AckReceiverWindow then all subsequent unicast message received from b1 are
added in this new AckReceiverWindow and when remove is called at line 470 of
UNICAST it always return null because the AckReceiverWindow::next_to_remove
is equal to 1 and the message that we are adding to AckReceiverWindow have a
seqno > 1.
The result is that a4...a15 will never be able to receive any other unicast
msg from b1. This is reproducible all the time.
Our quick fix that look to work fine is to change UNICAST line 453 as
following (I am not sure about potential bug introduce by this):
entry.received_msgs=new AckReceiverWindow(seqno);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 3 months
[JBoss JIRA] Created: (JBAS-3777) Cannot get client cerfiticate when using IIS 6
by Tomaz Cerar (JIRA)
Cannot get client cerfiticate when using IIS 6
----------------------------------------------
Key: JBAS-3777
URL: http://jira.jboss.com/jira/browse/JBAS-3777
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Affects Versions: JBossAS-4.0.3 SP1
Environment: Windows 2003 SP1, IIS 6, Tomcat connector 1.2.19
Reporter: Tomaz Cerar
Assigned To: Remy Maucherat
We have an application where user can authenticate himself with Client certificate.
SSL and authentication is done by IIS 6.
The problem is that after auth is successful but I don't get client certificate in servlet.
request.getAttribute("javax.servlet.request.X509Certificate") returns null
The same application with same configuration works ok on IIS 5(old production box) and IIS 5.1 (development)
I have tried with various versions of JK and JK2 and same result, doesn't work in IIS 6.
I have tried to run IIS in IIS 5 isolation mode and without, and results are same.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 3 months
[JBoss JIRA] Created: (JGRP-357) Unicast messages to unused port result in infinitely retransmission of message
by Vincent Hartsteen (JIRA)
Unicast messages to unused port result in infinitely retransmission of message
------------------------------------------------------------------------------
Key: JGRP-357
URL: http://jira.jboss.com/jira/browse/JGRP-357
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Reporter: Vincent Hartsteen
Assigned To: Bela Ban
In JGroups 2.4 (but probably this also happens in previous versions, did not verify this) we noticed that it is possible to send a message to a host:port that is not part of the group. This member might have been a member of the group but does not need to have been. This results in the retransmission of the message. However this retransmission never seems to end. The attached program demonstrates this.
Use the properties file to assign a host-address and port the program will send messages to.
Properties file:
===========
flood.target.address : 10.220.242.33
flood.target.port : 2715
flood.topic : flood.the.network
flood.stack : UDP(mcast_addr=228.1.2.123;mcast_port=19302;ip_ttl=32;loopback=false;\
mcast_recv_buf_size=1000000;max_bundle_size=64000;max_bundle_timeout=100;use_incoming_packet_handler=false;\
use_outgoing_packet_handler=true;ucast_send_buf_size=1000000;ip_ttl=32;enable_bundling=true/):\
PING(timeout=6000;num_initial_members=8;down_thread=false):\
MERGE2(max_interval=300000;min_interval=60000;down_thread=false):\
FD(timeout=30000;max_tries=5;shun=true):\
pbcast.NAKACK(gc_lag=300;retransmit_timeout=3000,30000,60000,180000;use_mcast_xmit=false;max_xmit_size=8192):\
UNICAST(timeout=3000,30000,60000,180000):\
pbcast.STABLE(desired_avg_gossip=300000;stability_delay=30000;max_bytes=65536;down_thread=false):\
pbcast.GMS(join_timeout=10000;join_retry_timeout=5000;shun=true;print_local_addr=true;down_thread=false):\
FC(max_credits=64000;min_credits=8000;down_thread=false):\
FRAG2(frag_size=8000;down_thread=false;up_thread=false):\
COMPRESS(down_thread=false;min_size=256;compression_level=9;up_thread=true):\
pbcast.STATE_TRANSFER(down_thread=false;up_thread=false)
Program:
=======
public class Flooder implements MembershipListener, RequestHandler, RspCollector {
private static Log log = LogFactory.getLog(Flooder.class);
private static int counter = 0;
private Channel channel = null;
private MessageDispatcher dispatcher = null;
private Timer floodTimer = null;
private InetAddress targetAddr;
private int targetPort;
private String topic;
private String stack;
public Flooder() throws IOException, ChannelException {
Properties properties = new Properties();
InputStream in = ClassLoader.getSystemClassLoader().getResourceAsStream("flooder.properties");
properties.load(in);
in.close();
targetAddr = InetAddress.getByName(properties.getProperty("flood.target.address").trim());
targetPort = Integer.parseInt(properties.getProperty("flood.target.port"));
topic = properties.getProperty("flood.topic");
stack = properties.getProperty("flood.stack");
initialize();
}
public void initialize() throws ChannelException {
channel = new JChannel(stack);
channel.setOpt(Channel.BLOCK, Boolean.TRUE);
channel.setOpt(Channel.GET_STATE_EVENTS, Boolean.TRUE);
channel.setOpt(Channel.AUTO_RECONNECT, Boolean.TRUE);
channel.setOpt(Channel.AUTO_GETSTATE, Boolean.TRUE);
channel.connect(topic);
dispatcher = new MessageDispatcher(channel, null, this, this);
log.trace("Connected to topic " + topic + " w/ stack: " + ((JChannel)channel).getProtocolStack().printProtocolSpec(true));
}
public void startFlooding() {
if (floodTimer != null) floodTimer.cancel();
floodTimer = new Timer();
floodTimer.schedule(new TimerTask() {
@Override
public void run() {
Address address = new IpAddress(targetAddr, targetPort);
Message msg = new Message(address, null, ("Flooooooooood#" + ++counter + "#").getBytes());
Vector<Address> victor = new Vector<Address>(1);
victor.add(address);
dispatcher.castMessage(victor, System.currentTimeMillis(), msg, Flooder.this);
log.trace("Sent Flooding message #" + counter + " to " + address + " @ " + new Date());
}
}, 1000, 10000);
}
public void block() {
log.trace("BLOCK");
}
public void suspect(Address addr) {
log.trace("SUSPECT: " + addr);
}
public void viewAccepted(View v) {
log.trace("VIEW ACCEPTED: " + v);
}
public Object handle(Message msg) {
log.trace("MESSAGE RECEIVED: " + msg);
return "HANDLED";
}
public void receiveResponse(Message m) {
log.trace("RECEIVE RESPONSE: " + m + " hdr=" + m.getHeaders());
}
public void viewChange(View v) {
log.trace("VIEW CHANGE: " + v);
}
public static void main(String[] args) {
try {
Flooder flooder = new Flooder();
flooder.startFlooding();
} catch (Exception ex) {
log.error("Exception occurred: ", ex);
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 3 months
[JBoss JIRA] Created: (JBAS-3923) CMP mixing database columns on high load
by Marius Kotsbak (JIRA)
CMP mixing database columns on high load
----------------------------------------
Key: JBAS-3923
URL: http://jira.jboss.com/jira/browse/JBAS-3923
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-4.0.4.GA
Environment: -Debian Linux sarge (stable)
-Postgresql 8.1.4
-jdbc driver postgresql-8.1-407.jdbc3.jar
Reporter: Marius Kotsbak
This exception appears on high load (stress testing) of a product on JBoss 4.0.4:
2006-12-04 17:46:06,732 ERROR [org.jboss.ejb.plugins.LogInterceptor] EJBException in method: public abstract no.boostcom.sms
fusion.beans.RecurringDataLocal no.boostcom.smsfusion.beans.InboxLocal.getRecurringData(), causedBy:
org.postgresql.util.PSQLException: Bad value for type timestamp : active
at org.postgresql.jdbc2.TimestampUtils.loadCalendar(TimestampUtils.java:232)
at org.postgresql.jdbc2.TimestampUtils.toTimestamp(TimestampUtils.java:307)
at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getTimestamp(AbstractJdbc2ResultSet.java:419)
at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getTimestamp(AbstractJdbc2ResultSet.java:2088)
at org.jboss.resource.adapter.jdbc.WrappedResultSet.getTimestamp(WrappedResultSet.java:943)
at org.jboss.ejb.plugins.cmp.jdbc.JDBCResultSetReader$12.readResult(JDBCResultSetReader.java:255)
at org.jboss.ejb.plugins.cmp.jdbc.JDBCResultSetReader$AbstractResultSetReader.get(JDBCResultSetReader.java:500)
at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgumentResults(JDBCAbstractCMPFieldBridge.j
ava:482)
at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgumentResults(JDBCAbstractCMPFieldBridge.j
ava:432)
at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadInstanceResults(JDBCAbstractCMPFieldBridge.j
ava:393)
at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:207)
at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:88)
at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:646)
at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:628)
at org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPersistenceManager.java:406)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.loadEntity(CachedConnectionInterceptor.java:252)
at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:243)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
at org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentranceInterceptor.java:126)
at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:276)
at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:104)
at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:68)
at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:378)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136)
at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:520)
at org.jboss.ejb.Container.invoke(Container.java:954)
at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:430)
The value "active" is valid for another column in the same entity bean than the timestamp column JBoss is trying to use it on.
We see other similar stacktraces:
2006-12-04 17:46:12,884 ERROR [org.jboss.ejb.plugins.LogInterceptor] TransactionRolledbackLocalException in method: public a
bstract boolean no.boostcom.smsfusion.smsfusionReceiverBeans.MtextHelperLocal.storeSMS(no.polardesign.boostcom.sms.SMSInnMel
ding,no.boostcom.smsfusion.beans.InboxVO) throws javax.ejb.ObjectNotFoundException,javax.naming.NamingException,javax.ejb.Fi
nderException,javax.ejb.CreateException, causedBy:
org.postgresql.util.PSQLException: Bad value for type timestamp : WAP Ordbok
at org.postgresql.jdbc2.TimestampUtils.loadCalendar(TimestampUtils.java:232)
Here another column is exchanged with the timestamp column.
Removing the CMRs between all related CMP beans (which also removes locking) seems to remove this problem, but that can result in much work. Get-fields in the entity beans are set to read only to reduce locking.
The same code worked fine on JBoss 3.2.5 using the same stress tests. It is also working on JBoss 4.0.4 during single accesses (not multitasking).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 3 months
[JBoss JIRA] Created: (EJBTHREE-844) We need a optimistic locking version of TreeCacheProviderHook
by Galder Zamarreno (JIRA)
We need a optimistic locking version of TreeCacheProviderHook
-------------------------------------------------------------
Key: EJBTHREE-844
URL: http://jira.jboss.com/jira/browse/EJBTHREE-844
Project: EJB 3.0
Issue Type: Bug
Components: Clustering
Affects Versions: EJB 3.0 RC9 - Patch 1, EJB 3.0 RC9 - FD
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Attachments: OptimisticTreeCacheProviderHook.java
Currently, EJB3/Hibernate cannot take advantage of using a second level
cache based in optimistic locking in a EJB3 environment. We only have a
TreeCacheProviderHook CacheProvider for pessimistic locking which
means that if a customer wants to set up optimistic locking, it's forced to
use OptimisticTreeCacheProvider.
However, this class was not designed for managed environments and
ends up creating another cache, so you end up with two caches for the
same job in the same instance which is wrong.
I have created a OptimisticTreeCacheProviderHook which creates an
org.hibernate.cache.OptimisticTreeCache based on the TreeCacheMBean
instance looked up. Please find attached.
This could be improved by creating a accessor method for
TreeCacheProviderHook.cache, so that I can directly extend it rather
than reimplementing CacheProvider. But, I have gone followed the
CacheProvider implementation path so that I can quickly pass a
patched jar containing this class only to the customer for them to try.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 3 months
[JBoss JIRA] Created: (JGRP-386) RequestCorrelator thread safety issue
by Bela Ban (JIRA)
RequestCorrelator thread safety issue
-------------------------------------
Key: JGRP-386
URL: http://jira.jboss.com/jira/browse/JGRP-386
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.4.1
[Dave Oxley]
We have had a deadlock issue with JGroups. The same issue affects 2.2.8 and 2.4.0. The call_stack in blocks.RequestCorrelator is a class variable and is set when a message is processed in util.Scheduler with deadlock_detection set to true. However if multiple threads call sendRequest in blocks.RequestCorrelator then they pick up the call_stack that may not be relevant to that request. This is most evident when concurrent_processing is also set to true as the call_stack grows permanently. The attached patch (against the 2.4 branch) makes call_stack a ThreadLocal and is set by the util.ReusableThread used to process the request. I've also changed the setConcurrentProcessing methods so that they work after the various objects have already been constructed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 3 months