January 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-8546) Negative Thread.sleep(timeout) call in NewMsgsWorker#run()

by Takayoshi Kimura (JIRA)

Negative Thread.sleep(timeout) call in NewMsgsWorker#run() ---------------------------------------------------------- Key: JBAS-8546 URL: https://jira.jboss.org/browse/JBAS-8546 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA service Affects Versions: 6.0.0.M5 Reporter: Takayoshi Kimura Assignee: Jesper Pedersen Fix For: TBD-6.x When this happens the NewMsgsWorker no longer check new emails. We should check the timeout parameter value before calling Thread.sleep(timeout). Basically there is no guarantee that the timeout is positive value. Say if you activate 10 endpoints very quickly with same interval, the "next - now" calculation would be negative. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBWEB-192) Fix Eclipse .classpath java build path

by Jordi Falguera (JIRA)

Fix Eclipse .classpath java build path -------------------------------------- Key: JBWEB-192 URL: https://issues.jboss.org/browse/JBWEB-192 Project: JBoss Web Issue Type: Patch Security Level: Public (Everyone can see) Affects Versions: JBossWeb-7.0.0.Beta1 Environment: FC13, Helios SR1, JVM 1.6.0_21-b06 Reporter: Jordi Falguera Assignee: Remy Maucherat Priority: Minor Attachments: JBWEB-192.patch Fix Eclipse .classpath java build path. Before building the project in eclipse, it requires first to build it using ant. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (JGRP-1267) UNICAST2: incorrect delivery order

by Bela Ban (JIRA)

UNICAST2: incorrect delivery order ---------------------------------- Key: JGRP-1267 URL: https://issues.jboss.org/browse/JGRP-1267 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.11.1, 2.12 Under stress, UNICAST2 can deliver messages in incorrect order. The reason is that in UNICAST2.handleDataReceived() 'processing' is set to false in the finally clause, no matter what. This can cause multiple threads to concurrently deliver messages for the same destination. SOLUTION: copy the code from NAKACK.handleMessage(), which does *not* set 'processing' to false in finally -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
1
0 / 0

[JBoss JIRA] Updated: (JBAS-8781) Can't process JSF TLD

by Stan Silvert (JIRA)

[ https://issues.jboss.org/browse/JBAS-8781?page=com.atlassian.jira.plugin.... ] Stan Silvert updated JBAS-8781: ------------------------------- Summary: Can't process JSF TLD (was: Can't parse JSF TLD) > Can't process JSF TLD > --------------------- > > Key: JBAS-8781 > URL: https://issues.jboss.org/browse/JBAS-8781 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Tomcat) service > Affects Versions: 7.0.0.Alpha1 > Reporter: Stan Silvert > Assignee: Remy Maucherat > > WAR to reproduce is attached. > 15:32:07,764 ERROR [org.jboss.as.server.deployment] (pool-3-thread-1) Caught exc > eption handling update (param is 10cd5140-b773-49da-97ab-0fb055b56141): java.lan > g.RuntimeException: Failed to process deployment chain. > at org.jboss.as.model.ServerDeploymentStartStopHandler.activate(ServerDe > ploymentStartStopHandler.java:203) > at org.jboss.as.model.ServerDeploymentStartStopHandler.deploy(ServerDepl > oymentStartStopHandler.java:87) > at org.jboss.as.model.ServerDeploymentStartStopHandler.deploy(ServerDepl > oymentStartStopHandler.java:71) > at org.jboss.as.model.ServerDeploymentStartStopHandler.redeploy(ServerDe > ploymentStartStopHandler.java:117) > at org.jboss.as.model.ServerModelDeploymentFullReplaceUpdate.applyUpdate > (ServerModelDeploymentFullReplaceUpdate.java:68) > at org.jboss.as.server.mgmt.ServerUpdateController$ServerModelUpdateTupl > e.applyUpdate(ServerUpdateController.java:430) > at org.jboss.as.server.mgmt.ServerUpdateController$ServerModelUpdateTupl > e.access$200(ServerUpdateController.java:400) > at org.jboss.as.server.mgmt.ServerUpdateController.applyUpdates(ServerUp > dateController.java:189) > at org.jboss.as.server.mgmt.ServerUpdateController.executeUpdates(Server > UpdateController.java:142) > at org.jboss.as.server.mgmt.deployment.ServerDeploymentManagerImpl$2.run > (ServerDeploymentManagerImpl.java:218) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec > utor.java:886) [:1.6.0_18] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor > .java:908) [:1.6.0_18] > at java.lang.Thread.run(Thread.java:619) [:1.6.0_18] > Caused by: org.jboss.as.deployment.unit.DeploymentUnitProcessingException: Faile > d to parse "/C:/projects/as7trunk/jboss-as/build/target/jboss-7.0.0.Alpha2/bin/c > ontent/mojarra2.0-bundled.war/WEB-INF/lib/jsf-impl-2.0.3-b05.jar/META-INF/html_b > asic.tld" > at org.jboss.as.web.deployment.TldParsingDeploymentProcessor.parseTLD(Tl > dParsingDeploymentProcessor.java:118) > at org.jboss.as.web.deployment.TldParsingDeploymentProcessor.processTlds > (TldParsingDeploymentProcessor.java:97) > at org.jboss.as.web.deployment.TldParsingDeploymentProcessor.processDepl > oyment(TldParsingDeploymentProcessor.java:77) > at org.jboss.as.deployment.chain.DeploymentChainImpl.processDeployment(D > eploymentChainImpl.java:50) > at org.jboss.as.model.ServerDeploymentStartStopHandler.activate(ServerDe > ploymentStartStopHandler.java:201) > ... 12 more > Caused by: java.lang.IllegalArgumentException: No enum const class org.jboss.met > adata.web.spec.BodyContentType. > JSP > at java.lang.Enum.valueOf(Enum.java:196) [:1.6.0_18] > at org.jboss.metadata.web.spec.BodyContentType.valueOf(BodyContentType.j > ava:32) > at org.jboss.as.metadata.parser.jsp.TagMetaDataParser.parse(TagMetaDataP > arser.java:111) > at org.jboss.as.metadata.parser.jsp.TldMetaDataParser.parse(TldMetaDataP > arser.java:200) > at org.jboss.as.web.deployment.TldParsingDeploymentProcessor.parseTLD(Tl > dParsingDeploymentProcessor.java:116) > ... 16 more -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-1266) NAKACK: don't wrap retransmitted messages

by Bela Ban (JIRA)

NAKACK: don't wrap retransmitted messages ----------------------------------------- Key: JGRP-1266 URL: https://issues.jboss.org/browse/JGRP-1266 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.12 In NAKACK.handleXmitReq(), we wrap messages that are retransmitted. Every xmitted message gets serialized into a byte buffer, and is added as the payload of another message. When received, NAKACK.handleXmitRsp() de-serializes the message and passes it up. We can get rid of this unneeded serialization/de-serialization: - When a message is to be retransmitted with dest=null (use_mcast_xmit), we simply resend the message: the rceeiver will receive the message as if it was a regular message, and not an xmit. NAKACK.handleMessage() will be invoked. - When dest != null, we make a copy of the message and replace the NakAckHeader.MSG with XMIT_RSP (plus seqno). When the message is received (handledd by NAKACK.handleXmitRsp() this time), we simply replace the XMIT_RSP with a MSG again, and pass the message up When we have a lot of retransmissions, this will save 1 serialization when handling the xmit request, and 1 de-serialization when handling the xmit response. Even better when use_mcast_xmit=true: here, everybody has to de-serialize the xmitted message. With the proposed solution, this cost is gone -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-2861) Jackrabbit cluster configuration ant task

by Tihomir Surdilovic (JIRA)

Jackrabbit cluster configuration ant task ----------------------------------------- Key: JBRULES-2861 URL: https://issues.jboss.org/browse/JBRULES-2861 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-ant Affects Versions: 5.1.1.FINAL Reporter: Tihomir Surdilovic Assignee: Tihomir Surdilovic Fix For: FUTURE Add ant task for jackrabbit cluster configuration -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
1
0 / 0

[JBoss JIRA] Updated: (JBWEB-192) Fix Eclipse .classpath java build path

by Jordi Falguera (JIRA)

[ https://issues.jboss.org/browse/JBWEB-192?page=com.atlassian.jira.plugin.... ] Jordi Falguera updated JBWEB-192: --------------------------------- Attachment: JBWEB-192.patch Patch that modifies .classpath file > Fix Eclipse .classpath java build path > -------------------------------------- > > Key: JBWEB-192 > URL: https://issues.jboss.org/browse/JBWEB-192 > Project: JBoss Web > Issue Type: Patch > Security Level: Public(Everyone can see) > Affects Versions: JBossWeb-7.0.0.Beta1 > Environment: FC13, Helios SR1, JVM 1.6.0_21-b06 > Reporter: Jordi Falguera > Assignee: Remy Maucherat > Priority: Minor > Attachments: JBWEB-192.patch > > > Fix Eclipse .classpath java build path. > Before building the project in eclipse, it requires first to build it using ant. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2011