[JBoss JIRA] Created: (JBAS-4488) Write BMTCleanUp tests for web-apps
by Adrian Brock (JIRA)
Write BMTCleanUp tests for web-apps
-----------------------------------
Key: JBAS-4488
URL: http://jira.jboss.com/jira/browse/JBAS-4488
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Reporter: Adrian Brock
Assigned To: Remy Maucherat
Priority: Blocker
Fix For: JBossAS-5.0.0.Beta3, JBossAS-4.2.1.CR1
We need to port the BMTCleanUp tests described on JBAS-4487 to web applications.
The fix has already been applied to the CachedConnectionValve.
The difficulty is that Tomcat does not provide a way to guarantee that two requests will occur on the same thread.
One possiblity is to deploy an additional connector on a different tcp/ip port with a max thread pool size of 1
just for this test.
--
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
[JBoss JIRA] Created: (JBPORTAL-1501) PortletTagHandler : not yet programmed in 2.6.0RC3
by Antoine Herzog (JIRA)
PortletTagHandler : not yet programmed in 2.6.0RC3
--------------------------------------------------
Key: JBPORTAL-1501
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1501
Project: JBoss Portal
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Portal Core
Affects Versions: 2.6 CR3
Environment: JPB2.6.0 RC3
Reporter: Antoine Herzog
Assigned To: Julien Viet
The PortletTagHandler class is not yet programmed.
The former code (for 2.4.1) is commented out.
This class was patched for 2.4.2 and 2.4.6
See : http://jira.jboss.com/jira/browse/JBPORTAL-1316
It seems that the portlet rendering API has changed quiet a lot for 2.6
Any tips of what have changed : general philosophy of the change, where to find what have moved, etc... are welcome to help make a patch.
I think this should be done for 2.6.0 final, has I know 2 portal in prod that use it yet (in 2.4.1).
It is very usefull to put some portlets directly in the layout jsp framework, and not in "all the pages" :
- chose the locale,
- chose the theme (for special accessibility prestentation),
- login and user portlet,
- general main navigation, etc...
Thanks
--
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
[JBoss JIRA] Created: (JBRULES-960) WorkingMemory cannot insert proxy object
by zhou yanming (JIRA)
WorkingMemory cannot insert proxy object
----------------------------------------
Key: JBRULES-960
URL: http://jira.jboss.com/jira/browse/JBRULES-960
Project: JBoss Rules
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.0.0.MR3
Reporter: zhou yanming
Assigned To: Mark Proctor
Priority: Critical
Fix For: 4.0.0.MR4
object was proxied by CGLIB,and works fine with 4.0.0.MR2,but when I upgrade to 4.0.0.MR3,It raise a exception
Caused by: java.lang.VerifyError: model.Order$$EnhancerByCGLIB$$d6d596a8ShadowProxy overrides final method ?0ó*h=+.?0ó*h=+
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.lang.ClassLoader.defineClass(ClassLoader.java:465)
at org.drools.rule.MapBackedClassLoader.fastFindClass(MapBackedClassLoader.java:40)
at org.drools.rule.MapBackedClassLoader.loadClass(MapBackedClassLoader.java:59)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.drools.reteoo.Rete$ObjectTypeConf.<init>(Rete.java:352)
at org.drools.reteoo.Rete.assertObject(Rete.java:152)
at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:772)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:584)
--
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
[JBoss JIRA] Created: (JGRP-503) Retransmitted message too large
by Bela Ban (JIRA)
Retransmitted message too large
-------------------------------
Key: JGRP-503
URL: http://jira.jboss.com/jira/browse/JGRP-503
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.5
Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=4288472
By: whatagreatuser
After leaving a 3 member cluster running for ~2 hours, received bunches of errors
on all the members. Below is the config XML, which is basically udp.xml with
some tweaks for for larger thread_pool and oob_thread_pool.
The Channel is basically used as an RPC layer with an RpcDispatcher sitting
on top of it. At the time of the errors no “user-level†messages were being
sent. No state is being managed by the channel either.
//channel setup
channel=new JChannel(jgroups_config_file);
channel.setOpt(Channel.AUTO_RECONNECT, Boolean.TRUE);
channel.addChannelListener(this);
disp=new RpcDispatcher(channel, null, this, this, true, true);
//force connect
channel.connect(clusterName);
ERROR | failed sending message to 10.0.0.64:28701 (163 bytes)
java.lang.Exception: dest=/10.0.0.64:28701 (65508 bytes)
at org.jgroups.protocols.UDP._send(UDP.java:345)
at org.jgroups.protocols.UDP.sendToSingleMember(UDP.java:302)
at org.jgroups.protocols.TP.doSend(TP.java:1197)
at org.jgroups.protocols.TP.send(TP.java:1184)
at org.jgroups.protocols.TP.down(TP.java:957)
at org.jgroups.protocols.Discovery.down(Discovery.java:325)
at org.jgroups.protocols.MERGE2.down(MERGE2.java:184)
at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:406)
at org.jgroups.protocols.FD.down(FD.java:363)
at org.jgroups.stack.Protocol.down(Protocol.java:270)
at org.jgroups.protocols.BARRIER.down(BARRIER.java:94)
at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:494)
at org.jgroups.protocols.UNICAST.retransmit(UNICAST.java:467)
at org.jgroups.stack.AckSenderWindow.retransmit(AckSenderWindow.java:145)
at org.jgroups.stack.Retransmitter$Entry.run(Retransmitter.java:339)
at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:187)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:65)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:168)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.net.SocketException: The message is larger than the maximum
supported by the underlying transport: Datagram send failed
at java.net.PlainDatagramSocketImpl.send(Native Method)
at java.net.DatagramSocket.send(DatagramSocket.java:612)
at org.jgroups.protocols.UDP._send(UDP.java:341)
... 23 more
ERROR | failed sending message to 10.0.0.64:28701 (163 bytes)
java.lang.Exception: dest=/10.0.0.64:28701 (65508 bytes)
at org.jgroups.protocols.UDP._send(UDP.java:345)
at org.jgroups.protocols.UDP.sendToSingleMember(UDP.java:302)
at org.jgroups.protocols.TP.doSend(TP.java:1197)
at org.jgroups.protocols.TP.send(TP.java:1184)
at org.jgroups.protocols.TP.down(TP.java:957)
at org.jgroups.protocols.Discovery.down(Discovery.java:325)
at org.jgroups.protocols.MERGE2.down(MERGE2.java:184)
at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:406)
at org.jgroups.protocols.FD.down(FD.java:363)
at org.jgroups.stack.Protocol.down(Protocol.java:270)
at org.jgroups.protocols.BARRIER.down(BARRIER.java:94)
at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:494)
at org.jgroups.protocols.UNICAST.retransmit(UNICAST.java:467)
at org.jgroups.stack.AckSenderWindow.retransmit(AckSenderWindow.java
:145)
at org.jgroups.stack.Retransmitter$Entry.run(Retransmitter.java:339)
at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java
:187)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.jav
a:417)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269
)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureT
ask.access$301(ScheduledThreadPoolExecutor.java:65)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureT
ask.run(ScheduledThreadPoolExecutor.java:168)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPool
Executor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExec
utor.java:675)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.net.SocketException: The message is larger than the maximum
supported by the underlying transport: Datagram send failed
at java.net.PlainDatagramSocketImpl.send(Native Method)
at java.net.DatagramSocket.send(DatagramSocket.java:612)
at org.jgroups.protocols.UDP._send(UDP.java:341)
... 23 more
ERROR | failed sending message to 10.0.0.64:28702 (66863 bytes)
java.lang.Exception: message size (66935) is greater than max bundling size
(64000). Set the fragmentation/bundle size in FRAG and TP correctly
at org.jgroups.protocols.TP$Bundler.checkLength(TP.java:1781)
at org.jgroups.protocols.TP$Bundler.send(TP.java:1670)
at org.jgroups.protocols.TP$Bundler.access$100(TP.java:1657)
at org.jgroups.protocols.TP.send(TP.java:1173)
at org.jgroups.protocols.TP.down(TP.java:957)
at org.jgroups.protocols.Discovery.down(Discovery.java:325)
at org.jgroups.protocols.MERGE2.down(MERGE2.java:184)
at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:406)
at org.jgroups.protocols.FD.down(FD.java:363)
at org.jgroups.stack.Protocol.down(Protocol.java:270)
at org.jgroups.protocols.BARRIER.down(BARRIER.java:94)
at org.jgroups.protocols.pbcast.NAKACK.sendXmitRsp(NAKACK.java:840)
at org.jgroups.protocols.pbcast.NAKACK.handleXmitReq(NAKACK.java:789
)
at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:537)
at org.jgroups.protocols.BARRIER.up(BARRIER.java:119)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:154)
at org.jgroups.protocols.FD.up(FD.java:328)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301)
at org.jgroups.protocols.MERGE2.up(MERGE2.java:145)
at org.jgroups.protocols.Discovery.up(Discovery.java:224)
at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1
541)
at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1495)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPool
Executor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExec
utor.java:675)
at java.lang.Thread.run(Thread.java:595)
<!--
Default stack using IP multicasting. It is similar to the "udp"
stack in stacks.xml, but doesn't use streaming state transfer and flushing
author: Bela Ban
version: $Id: udp.xml,v 1.20 2007/03/16 09:54:44 belaban Exp $
-->
<config>
<UDP
mcast_addr="${jgroups.udp.mcast_addr:228.10.10.50}"
mcast_port="${jgroups.udp.mcast_port:50000}"
tos="8"
ucast_recv_buf_size="20000000"
ucast_send_buf_size="640000"
mcast_recv_buf_size="25000000"
mcast_send_buf_size="640000"
loopback="false"
discard_incompatible_packets="true"
max_bundle_size="64000"
max_bundle_timeout="30"
use_incoming_packet_handler="true"
ip_ttl="${jgroups.udp.ip_ttl:2}"
enable_bundling="true"
enable_diagnostics="true"
thread_naming_pattern="cl"
use_concurrent_stack="true"
thread_pool.enabled="true"
thread_pool.min_threads="1"
thread_pool.max_threads="250"
thread_pool.keep_alive_time="60000"
thread_pool.queue_enabled="true"
thread_pool.queue_max_size="10000"
thread_pool.rejection_policy="Abort"
oob_thread_pool.enabled="true"
oob_thread_pool.min_threads="1"
oob_thread_pool.max_threads="250"
oob_thread_pool.keep_alive_time="60000"
oob_thread_pool.queue_enabled="true"
oob_thread_pool.queue_max_size="10000"
oob_thread_pool.rejection_policy="Abort"/>
<PING timeout="2000"
num_initial_members="2"/>
<MERGE2 max_interval="30000"
min_interval="10000"/>
<FD_SOCK/>
<FD timeout="10000" max_tries="5" shun="true"/>
<VERIFY_SUSPECT timeout="1500" />
<BARRIER />
<pbcast.NAKACK max_xmit_size="60000"
use_mcast_xmit="false" gc_lag="0"
retransmit_timeout="300,600,1200,2400,4800"
discard_delivered_msgs="true"/>
<UNICAST timeout="300,600,1200,2400,3600"/>
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
max_bytes="400000"/>
<VIEW_SYNC avg_send_interval="60000" />
<pbcast.GMS print_local_addr="true" join_timeout="3000"
join_retry_timeout="2000" shun="false"
view_bundling="true"/>
<FC max_credits="20000000"
min_threshold="0.10"/>
<FRAG2 frag_size="60000" />
<!--pbcast.STREAMING_STATE_TRANSFER use_reading_thread="true"/-->
<pbcast.STATE_TRANSFER />
<!-- pbcast.FLUSH /-->
</config>
--
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
[JBoss JIRA] Created: (JBMICROCONT-175) Move incomplete deployment checking into MainDeployer
by Scott M Stark (JIRA)
Move incomplete deployment checking into MainDeployer
-----------------------------------------------------
Key: JBMICROCONT-175
URL: http://jira.jboss.com/jira/browse/JBMICROCONT-175
Project: JBoss MicroContainer
Issue Type: Feature Request
Affects Versions: JBossMC_2_0_0 Beta3
Reporter: Scott M Stark
Fix For: JBossMC_2_0_0_CR1
Currently all users of the MainDeployer.process have to externally code something like:
protected void checkIncomplete() throws DeploymentException
{
IncompleteDeployments incomplete = IncompleteDeploymentsBuilder.build(mainDeployer, controller);
if (incomplete.isIncomplete())
throw new IncompleteDeploymentException(incomplete);
}
to see if the last process has any deployments in an incomplete state. It would be better if this logic was passed in as a listener with helper implementations for the typical check to avoid this duplication and need to inject kernel controller.
--
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
[JBoss JIRA] Created: (JGRP-533) RpcDispatcher: thread pool to provide interruptible cluster call invocations
by Bela Ban (JIRA)
RpcDispatcher: thread pool to provide interruptible cluster call invocations
----------------------------------------------------------------------------
Key: JGRP-533
URL: http://jira.jboss.com/jira/browse/JGRP-533
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.4.1 SP4, 2.5
This is to solve http://jira.jboss.com/jira/browse/JBCACHE-1103, especially in 2.4. (In 2.5, we have OOB messages that deliver credit responses).
SOLUTION:
Th idea is to have 1 additional callRemoteMethod(s) method, which takes a timeout > 0 and a boolean use_thread_pool. If the boolean is false, then we have the default behavior: send the request, then block until all responses have been received. Else, the behavor is the following:
- Create a task that is scheduled with a thread pool and as result get a Future. (The thread pool might get created per RpcDispatcher or as static member of the RpcDispatcher class, and it is configured via system props).
- Block on the Future for timeout milliseconds
- If all the responses have been received:
- Set the result in the Future and notify it, so the caller unblocks and returns
- If the timeout elapsed:
- Interrupt the task (e.g. thread blocked in FC.down() will return, and mark the GroupRequest as 'done' so further responses are ignored) and return the current results with the RpcList, unblocking the caller
The decision whether or not to use a thread pool is *per method call*, so we don't have the overhead of the thread pool for regular calls.
This is only necessary for 2.4, as we only have a single request queue, which caused JBCACHE-1103. In 2.5, this will not happen. Question is do we want to forward-port this to 2.5 as well...
--
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
