[JBoss JIRA] Created: (JBPORTAL-1176) Error Displaying Flash in JBoss Portal 2.4.1.CR2
by Mitch De Felice (JIRA)
Error Displaying Flash in JBoss Portal 2.4.1.CR2
------------------------------------------------
Key: JBPORTAL-1176
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1176
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal Portlet
Affects Versions: 2.4.1 SP1
Environment: Release ID: JBoss [Zion] 4.0.5.GA
Home Dir: E:\Apache Group\jboss-portal-2.4.1-CR2
Java version: 1.4.2_09,Sun Microsystems Inc.
Java VM: Java HotSpot(TM) Server VM 1.4.2_09-b05,Sun Microsystems Inc.
OS-System: Windows 2000 5.0,x86
Database: Oracle 9i
Reporter: Mitch De Felice
Assigned To: Julien Viet
I'm having two problems with running the flash plugin in Jboss Portel window.
1. When I try to set the height and width on the object tag to a 100%, the window goes totally blank, like I didn't have any statements in the jsp. However, if I set the width="100%" and set a specific height="450" the flash plugin will be displayed.
<center>
<object width="100%" height="100%">
<param name="movie" value="<%= request.getAttribute("flashurl") %>"/>
<embed src="<%= request.getAttribute("flashurl") %>" width="100%" height="100%"/>
</object>
</center>
2. The second problem that I'm seeing when trying to view a flash plungin in a Portlet Window is when I specify the classid on the object tag, the footer of the Portlet Window gets clipped off.
<center>
<object width="100%" height="455"
classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" >
<param name="movie" value="<%= request.getAttribute("flashurl") %>"/>
<embed src="<%= request.getAttribute("flashurl") %>" width="100%" height="455"/>
</object>
</center>
I need to specify the classid so as the flash plugin can make an Ajax call back into the server.
--
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, 3 months
[JBoss JIRA] Created: (JBPORTAL-1525) RichFaces : finish integration : features, examples...
by Antoine Herzog (JIRA)
RichFaces : finish integration : features, examples...
------------------------------------------------------
Key: JBPORTAL-1525
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1525
Project: JBoss Portal
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Portal Portlet
Affects Versions: 2.6 CR3
Environment: JBoss Portal 2.6CR3 (on a JBoss AS 4.0.5)
Rich Faces 3.0.0 and 3.0.2 (fixed version)
Reporter: Antoine Herzog
Assigned To: Julien Viet
RichFaces has provided a sample application to work in a JBoss Portal Portlet.
There was quiet a lot of tuning and adaptation (RichFaces side only ?).
It seems that it work with the JBoss Portal 2.6.0 as released.
But they may be some things to do in JBoss Portal side.
- Use of RichFaces for admin portlets etc... (as it is now inside JBoss products)
- At least, integrate a sample RichFaces Portlet, to show how nice it is, and how it works etc...
--
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, 3 months
[JBoss JIRA] Created: (JGRP-654) Scheduler thread goes in infinite loop after getting interrupted by the priority task
by vivek v (JIRA)
Scheduler thread goes in infinite loop after getting interrupted by the priority task
-------------------------------------------------------------------------------------
Key: JGRP-654
URL: http://jira.jboss.com/jira/browse/JGRP-654
Project: JGroups
Issue Type: Bug
Affects Versions: 2.6.1
Environment: Linux, JGroups v. 2.6.1
Reporter: vivek v
Assigned To: Bela Ban
This seems like a bug in Scheduler class. The scheduler thread goes into infinite loop and never recovers after being interrupted by the priority task (upon deadlock detection). Here is what I think happens (with both deadlock_detection and concurrent_processing enabled for RpcDispatcher),
1) The tasks are added to the Scheduler Queue
2) If the deadlock_detection is turned on and there is a kind of
deadlock (2-way method calls) the RequestCorrelator.receiveMessage()
calls scheduler.addPrio(req) method
3) The addPrio(Runnable task) method adds the priority task to the
head of the queue and calls the interrupt method on the Scheduler
thread.
4) In the run() method of Scheduler we peek the queue, take the task
from head and run it
5) "sched_thread.isInterrupted()" in the run method returns true and
throws InterruptedException
6) Since, interrupted exception is thrown we bypass the
"queue.removeElement(current_task)" - and the task is not removed
from the queue.
7) The catch block of InterruptedException sets the
current_task.suspended=true, but never resets the interrupt flag
8) Now we keep going through the same loop for the same task in the
queue in the run() method as we never resets the interrupt flag.
I hope this is a correct diagnosis of this "TimeoutException" problem we have been seeing for last 2-3 months. I'm not sure if there are some nested Rpc calls in our system, but with deadlock-detection turned on they should be resolved. As tasks are never moved out of the queue, all the tasks just keep adding up (I see my queue over 2300 elements) and thus, we get TimeoutException for all the incoming calls.
I think we need to call "sched_thread.interrupted()" in the InterruptedException catch block so we can remove items from the queue as we process them. I've tried with this change (added Thread.interrupted at the end of InterruptedException catch block) in my local jgroups-all.jar and it seems to work fine for a long time now (3-4 hours, earlier it used to fail within 2 hours).
I haven't found any workaround for this problem if the deadlock detection logic is exercised.
--
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, 3 months
[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, 3 months