July 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Assigned: (JBPM-450) webapp can't handle processes without an image file

by Ronald van Kuijk (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-450?page=all ] Ronald van Kuijk reassigned JBPM-450: ------------------------------------- Assignee: Ronald van Kuijk (was: Tom Baeyens) > webapp can't handle processes without an image file > --------------------------------------------------- > > Key: JBPM-450 > URL: http://jira.jboss.com/jira/browse/JBPM-450 > Project: JBoss jBPM > Issue Type: Bug > Components: Web Interface > Reporter: Tom Baeyens > Assigned To: Ronald van Kuijk > Fix For: jBPM 3.2 > > -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] Created: (JBTM-101) Provide a global default timeout value for ArjunaCore transactions

by Mark Little (JIRA)

Provide a global default timeout value for ArjunaCore transactions ------------------------------------------------------------------ Key: JBTM-101 URL: http://jira.jboss.com/jira/browse/JBTM-101 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2 Reporter: Mark Little Assigned To: Mark Little Fix For: 4.2.1 This can be picked up by the local JTA implementation. -- 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, 12 months

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-102) Update manual for JTA default timeout

by Mark Little (JIRA)

Update manual for JTA default timeout ------------------------------------- Key: JBTM-102 URL: http://jira.jboss.com/jira/browse/JBTM-102 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation, JTA Implementation Affects Versions: 4.2.1 Reporter: Mark Little Assigned To: Mark Little Fix For: 4.2.1 -- 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, 12 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-537) org.jboss.test.remoting.transport.rmi.ssl.handshake.RMIInvokerTestCase(java_serialization) - failing

by Tom Elrod (JIRA)

org.jboss.test.remoting.transport.rmi.ssl.handshake.RMIInvokerTestCase(java_serialization) - failing ---------------------------------------------------------------------------------------------------- Key: JBREM-537 URL: http://jira.jboss.com/jira/browse/JBREM-537 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: security Affects Versions: 2.0.0.Beta2 (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.0.0.CR1 (Boon) http://cruisecontrol.jboss.com/cc/artifacts/jboss-remoting-testsuite-1.4/... -- 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, 12 months

2
2
0 / 0

[JBoss JIRA] Closed: (JBREM-390) finish multiplex

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-390?page=all ] Ron Sigal closed JBREM-390. --------------------------- Resolution: Done While there is still room for performance improvement, the basic API and feature set are essentially complete. > finish multiplex > ---------------- > > Key: JBREM-390 > URL: http://jira.jboss.com/jira/browse/JBREM-390 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Components: transport-multiplex > Affects Versions: 1.4.1 final > Reporter: Tom Elrod > Assigned To: Ron Sigal > Fix For: 2.0.0.CR1 (Boon) > > > to be production ready -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBREM-402) Let virtual MultiplexServerInvokers share master MultiplexServerInvoker's thread pool.

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-402?page=all ] Ron Sigal closed JBREM-402. --------------------------- Resolution: Done Replaced by JBREM-554. > Let virtual MultiplexServerInvokers share master MultiplexServerInvoker's thread pool. > -------------------------------------------------------------------------------------- > > Key: JBREM-402 > URL: http://jira.jboss.com/jira/browse/JBREM-402 > Project: JBoss Remoting > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Affects Versions: 2.0.0.CR1 (Boon) > Reporter: Ron Sigal > Assigned To: Ron Sigal > Fix For: 2.0.0.CR1 (Boon) > > > Consider a use case in which the same master MultiplexServerInvoker is contacted repeatedly to create virtual MultiplexServerInvokers. Then having some existing threads around to use would save virtual MultiplexServerInvokers from having to build up their own threadpools. -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBREM-397) Underlying actual socket stays alive after all virtual connections have closed.

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-397?page=all ] Ron Sigal resolved JBREM-397. ----------------------------- Resolution: Done This problem has not been reproduced, so we are closing it, pending additional information. > Underlying actual socket stays alive after all virtual connections have closed. > ------------------------------------------------------------------------------- > > Key: JBREM-397 > URL: http://jira.jboss.com/jira/browse/JBREM-397 > Project: JBoss Remoting > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Affects Versions: 2.0.0.Beta2 (Boon) > Reporter: Ron Sigal > Assigned To: Ron Sigal > Fix For: 2.0.0.CR1 (Boon) > > > Tim Fox is opening and closing multiplex connections in a loop, and seeing the actual sockets remain in ESTABLISHED state, instead of shutting down. -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBREM-534) multiplex client cannot re-connect to server after it has died and then been re-started

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-534?page=comments#action_12339906 ] Ron Sigal commented on JBREM-534: --------------------------------- This is indeed a Multiplex issue. The client invoker is closely tied to the server invoker because it depends on a persistent socket connection to the server. This situation is remedied by some changes to InputMultiplexor, OutputMultiplexor, MultiplexingManager, MultiplexClientInvoker, and MultiplexServerInvoker. Whenever InputMultiplexor or OutputMultiplexor detect a broken connection, they inform MultiplexingManager, which informs all of the virtual sockets in its group. When MultiplexClientInvoker.createSocket() finds that its priming socket has been contacted about a broken connection, it attempts to create a new priming socket connected to a new server at the same address as the one that went down. The complication is that there might be a virtual callback MultiplexServerInvoker in the same group, bound to a particular bind port. Attempting to create a new socket bound to the same port can cause a bind exception, so MultiplexClientInvoker gets an arbitrary bind port and restarts the MultiplexServerInvoker with a new VirtualServerrSocket bound to the new bind port. If the Connector was created explicitly by the user, the user will have to query the Connector for its new InvokerLocator before re-registering any callback handlers. > multiplex client cannot re-connect to server after it has died and then been re-started > --------------------------------------------------------------------------------------- > > Key: JBREM-534 > URL: http://jira.jboss.com/jira/browse/JBREM-534 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: transport-multiplex > Affects Versions: 2.0.0.Beta2 (Boon) > Reporter: Tom Elrod > Assigned To: Ron Sigal > Fix For: 2.0.0.CR1 (Boon) > > > "However, I have found another issue that still needs looking into. If using multiplex transport and a server is killed and then re-started, it looks like the detector sees the server restarting, then tries to ping it, but can not, so discards it as being dead, then repeats this process. This does not happen when using socket transport, so looks like there is some issue where multiplex client is having trouble making invocations on a server after it has gone down and then come back up." -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBPORTAL-208) Automated test suite

by Julien Viet (JIRA)

[ http://jira.jboss.com/jira/browse/JBPORTAL-208?page=all ] Julien Viet resolved JBPORTAL-208. ---------------------------------- Resolution: Done > Automated test suite > -------------------- > > Key: JBPORTAL-208 > URL: http://jira.jboss.com/jira/browse/JBPORTAL-208 > Project: JBoss Portal > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Portal Core > Affects Versions: 2.2 Final > Reporter: Julien Viet > Assigned To: Rali Genova > Fix For: 2.4 Final > > Time Spent: 3 hours > Remaining Estimate: 0 minutes > -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-2380) VFS Aspect for deployments

by Scott M Stark (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2380?page=all ] Scott M Stark closed JBAS-2380. ------------------------------- Resolution: Done Assignee: Scott M Stark The VFS VirtualFile is exposed as part of the org.jboss.deployers.spi.DeploymentContext for each deployment element. > VFS Aspect for deployments > -------------------------- > > Key: JBAS-2380 > URL: http://jira.jboss.com/jira/browse/JBAS-2380 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Deployment services > Reporter: Scott M Stark > Assigned To: Scott M Stark > Priority: Blocker > Fix For: JBossAS-5.0.0.Beta > > > An integration task for the VFS aspect common to deployment content and class loaders. -- 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, 12 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2006