[JBoss JIRA] Created: (JBAS-7548) Request parameters reappear in a filter between subsequent requests
by Robert Spielmann (JIRA)
Request parameters reappear in a filter between subsequent requests
-------------------------------------------------------------------
Key: JBAS-7548
URL: https://jira.jboss.org/jira/browse/JBAS-7548
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-4.2.3.GA
Environment: JBoss 4.2.3GA/JBossWeb 2.0.1GA, JDK 1.6.0_17, Windows XP SP3 as well as Linux
Reporter: Robert Spielmann
We have a filter that gets a parameter from the httpRequest, in order to do something based on the param value. It seems that under certain conditions (which we cannot isolate unfortunately) the request parameter re-appears from the depths of Catalina/Coyote - httpRequest.getParameter(FOO) goes down through the RequestFacade to an org.apache.catalina.connector.Request which contains an org.apache.coyote.Request and so on.
We would expect that for subsequent requests, the request parameters ALWAYS get reset to "nothing" except those parameters that were really passed into the request. This seems to be different though. As we cannot go deeper using a debugger, we think this might be a problem with JBossWeb 2.0.1 itself.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months
[JBoss JIRA] Created: (JGRP-1111) Draw demo does not work using state transfer, sequencer, and flush together.
by sean chandler (JIRA)
Draw demo does not work using state transfer, sequencer, and flush together.
----------------------------------------------------------------------------
Key: JGRP-1111
URL: https://jira.jboss.org/jira/browse/JGRP-1111
Project: JGroups
Issue Type: Bug
Affects Versions: 2.6.13
Environment: CentOS 5.4
Java 1.6.0.17
Reporter: sean chandler
Assignee: Bela Ban
Fix For: 2.6.14
Draw demo does not work in conjunction with state transfer, sequencer, and flush in the stack. Nodes will join initially and form a cluster. Killing master node puts the survivor in an infinite flush block. The killed node will never join the cluster again.
Reproduce:
Start two nodes using the command lines below.
Draw on both panels.
Kill master node.
Draw on survivor.
Bring up killed node.
Infinite flush block (regardless of flush timeout).
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
x.x.x.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
224.0.0.0 0.0.0.0 240.0.0.0 U 0 0 0 eth1
0.0.0.0 x.x.x.x.254 0.0.0.0 UG 0 0 0 eth0
node0> java -classpath commons-logging.jar:jgroups-all.jar -Djava.net.preferIPv4Stack=true -Djgroups.bind_addr=169.254.0.1 org.jgroups.demos.Draw -state -props jgroups.xml
node1> java -classpath commons-logging.jar:jgroups-all.jar -Djava.net.preferIPv4Stack=true -Djgroups.bind_addr=169.254.0.2 org.jgroups.demos.Draw -state -props jgroups.xml
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months
[JBoss JIRA] Created: (JGRP-1114) RATE_LIMITER: protocol to define max throughput / sender / time unit
by Bela Ban (JIRA)
RATE_LIMITER: protocol to define max throughput / sender / time unit
--------------------------------------------------------------------
Key: JGRP-1114
URL: https://jira.jboss.org/jira/browse/JGRP-1114
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.8
This is a new protocol which limits the rate of sending messages. Properties max_bytes defines the max number of bytes and time_period the max number of milliseconds. Together, these props define an upper limit of bytes to be sent / time_period, for example
max_bytes="120KB" time_period="3000" defines that we can send a max of 120'000 bytes distributed over the course of 3 seconds.
max_bytes="10MB" time_period="1000" means that a sender can send only 10MB of data per second. If we have 4 senders, then the total throughtput will never be more than 40MB/sec/node in this example.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months