[JBoss JIRA] Created: (JGRP-636) NullPointerException in Multiplexer
by Robert Newson (JIRA)
NullPointerException in Multiplexer
-----------------------------------
Key: JGRP-636
URL: http://jira.jboss.com/jira/browse/JGRP-636
Project: JGroups
Issue Type: Bug
Affects Versions: 2.6
Reporter: Robert Newson
Assigned To: Bela Ban
java.lang.NullPointerException
at org.jgroups.mux.Multiplexer.handleStateRequest(Multiplexer.java:639)
at org.jgroups.mux.Multiplexer.up(Multiplexer.java:352)
at org.jgroups.JChannel.up(JChannel.java:1148)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:362)
at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:427)
at org.jgroups.protocols.pbcast.STATE_TRANSFER.requestApplicationStates(STATE_TRANSFER.java:233)
at org.jgroups.protocols.pbcast.STATE_TRANSFER.handleStateReq(STATE_TRANSFER.java:367)
at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:117)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:205)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:766)
at org.jgroups.protocols.VIEW_SYNC.up(VIEW_SYNC.java:161)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
at org.jgroups.protocols.UNICAST.handleDataReceived(UNICAST.java:579)
at org.jgroups.protocols.UNICAST.up(UNICAST.java:250)
at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:714)
at org.jgroups.protocols.BARRIER.up(BARRIER.java:122)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:167)
at org.jgroups.protocols.FD.up(FD.java:322)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:300)
at org.jgroups.protocols.MERGE2.up(MERGE2.java:145)
at org.jgroups.protocols.Discovery.up(Discovery.java:250)
at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1510)
at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1459)
at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1737)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1060)
at org.jgroups.protocols.TP.receive(TP.java:1031)
at org.jgroups.protocols.UDP$UcastReceiver.run(UDP.java:899)
at java.lang.Thread.run(Thread.java:619)
--
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
18 years, 5 months
[JBoss JIRA] Created: (JBSER-97) RegularObjectPersister.readSlotWithFields to log number of fields being read
by Galder Zamarreno (JIRA)
RegularObjectPersister.readSlotWithFields to log number of fields being read
----------------------------------------------------------------------------
Key: JBSER-97
URL: http://jira.jboss.com/jira/browse/JBSER-97
Project: JBoss Serialization
Issue Type: Task
Affects Versions: 1.0.3 GA
Reporter: Galder Zamarreno
Assigned To: Clebert Suconic
Priority: Minor
writeSlotWithFields logs the slot name and number of fields to be written.
for debugging pupouses, readSlotWithFields could do with logging the number of fields written too, i.e.
RegularObjectPersister.readSlotWithFields() to start like this:
short numberOfFields = (short)fieldsKey.length;
if (isDebug)
{
log.debug("readSlotWithFields slot=" + slot.getSlotClass().getName() + " and " + numberOfFields + " fields");
}
instead of:
if (isDebug)
{
log.debug("readSlotWithFields slot=" + slot.getSlotClass().getName());
}
//final int numberOfFields = input.readShort();
short numberOfFields = (short)fieldsKey.length;
--
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
18 years, 5 months
[JBoss JIRA] Created: (JBAS-5161) Preferred master API should live on its own hasingleton election policy
by Galder Zamarreno (JIRA)
Preferred master API should live on its own hasingleton election policy
-----------------------------------------------------------------------
Key: JBAS-5161
URL: http://jira.jboss.com/jira/browse/JBAS-5161
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Fix For: JBossAS-5.0.0.Beta4
HASingletonElectionPolicy should only contain methods that actually called from
the HASingletonSupport/HASingletonController classes so that they can inject
attributes to the election policy that users don't have to specify in the ha singleton
election policy bean definition.Therefore:
/**
* Sets the preferred master node. As long as the preferred master node
* presents in the cluster, it will be always selected as master node,
* no matter what the election policy is.
* @param node String format of ip_address:port_number
*/
void setPreferredMaster(String node);
String getPreferredMaster();
The methods above should not live in HASingletonElectionPolicy, but instead on its
own policy impl class..
--
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
18 years, 5 months