[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, 1 month
[JBoss JIRA] Created: (JBAS-4195) Sorting File.listFiles() result before loading Jars
by Noel Rocher (JIRA)
Sorting File.listFiles() result before loading Jars
---------------------------------------------------
Key: JBAS-4195
URL: http://jira.jboss.com/jira/browse/JBAS-4195
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: ClassLoading, Deployment services
Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.0.4.GA
Reporter: Noel Rocher
Assigned To: Scott M Stark
Priority: Trivial
List of files with a File.listFiles() usage where a sort() could be relevant
JBoss AS 4.0.5 GA
------------------
file:///app/jboss/jboss-4.0.5.GA-src/jmx/src/main/org/jboss/mx/loading/ClassLoaderUtils.java
file:///app/jboss/jboss-4.0.5.GA-src/system/src/main/org/jboss/deployment/SARDeployer.java <--- ?
file:///app/jboss/jboss-4.0.5.GA-src/system/src/main/org/jboss/deployment/scanner/URLDirectoryScanner.java <--- already sorted
file:///app/jboss/jboss-4.0.5.GA-src/system/src/main/org/jboss/deployment/SubDeployerSupport.java <--- ?
file:///app/jboss/jboss-4.0.5.GA-src/system/src/main/org/jboss/Main.java
file:///app/jboss/jboss-4.0.5.GA-src/system/src/main/org/jboss/system/server/ServerImpl.java
file:///app/jboss/jboss-4.0.5.GA-src/testsuite/src/main/org/jboss/test/jmx/test/AbstractURLDeploymentScannerTest.java <--- ?
file:///app/jboss/jboss-4.0.5.GA-src/tomcat/src/main/org/jboss/web/tomcat/tc5/WebCtxLoader.java
org.jboss.util.JarUtil method jar takes an unsorted list of files
--
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, 1 month
[JBoss JIRA] Commented: (JBPM-395) SwimlaneInstance PooledActor assignment bug (not re-assignment issue)
by Britt Miner (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-395?page=comments#action_12355682 ]
Britt Miner commented on JBPM-395:
----------------------------------
Hmm... [cough] well, perhaps I 'definitely' misspoke. This does not seem to be an issue with 3.1. I get to pull out my workaround :-)
> SwimlaneInstance PooledActor assignment bug (not re-assignment issue)
> ---------------------------------------------------------------------
>
> Key: JBPM-395
> URL: http://jira.jboss.com/jira/browse/JBPM-395
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Affects Versions: jBPM 3.0.1
> Environment: JDK 1.5, Postgresql, JBoss 4.0.2
> Reporter: Britt Miner
> Assigned To: Tom Baeyens
>
> Initializing swimlaneInstances at process creation (or perhaps any time prior to creation of an associated task) will persist any configured actorId to the database, but configured PooledActors are not persisted. The AssignmentHandler functionality seems to work fine--the newly initialized swimlaneInstance has both actorId and pooledActors set correctly; however, the pooledActors will not be persisted. Allowing the swimlaneInstance to be initialized at creation of a related task does result in both actorId and pooledActors being properly persisted.
> This issue is similar, though not identical, to http://jira.jboss.com/jira/browse/JBPM-375 and http://jira.jboss.com/jira/browse/JBPM-378 which are both related to swimlane assignment issues.
> Why initialize swimlaneInstances at process creation? So that swimlane assignments can be made based on the initiator of the process (responsibilities broken down by regional groups, etc.), and so that those assignments are available for reporting/forcasting purposes.
> This is the code fragment used to initialize the swimlanes:
> ...
> Map swimlanes = processDefinition.getTaskMgmtDefinition().getSwimlanes();
> Iterator itr = swimlanes.keySet().iterator();
> while(itr.hasNext()) {
> Swimlane swimlane = (Swimlane)swimlanes.get(itr.next());
> SwimlaneInstance swi = pi.getTaskMgmtInstance().getInitializedSwimlaneInstance(new Execution
> Context(pi.getRootToken()), swimlane);
> //at this point, swi contains both actors and PooledActors that were specified in configuration and
> populated with an appropriate AssignmentHandler
> }
> graphSession.saveProcessInstance(pi);
> jbpmSession.commitTransaction();
> Thanks,
> Britt
--
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, 2 months