November 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (JBMESSAGING-406) Persistence refactoring

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-406?page=comments#action_12... ] Tim Fox commented on JBMESSAGING-406: ------------------------------------- By replicating to buddy - but only in memory (should be configurable) get in memory replication! > Persistence refactoring > ----------------------- > > Key: JBMESSAGING-406 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-406 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > Assigned To: Tim Fox > Priority: Critical > Fix For: 2.0.0 Alpha > > > Need to refactor persistence so each node has its own storage. > We should provide at least three local persistence manager configs: > 1) JDBC local pm that works out of the box with HSQL - not recommended for production. > 2) BDB based pm that customers need to download - recommended for best performance. > Should optimise for the SAN use case. > Need to consider whether we need to support replication for failover too. -- 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

17 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-574) In memory replication of persistent messages

by Tim Fox (JIRA)

In memory replication of persistent messages -------------------------------------------- Key: JBMESSAGING-574 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-574 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.0.Beta1 We should enable an option whereby persisted messages can be replicated between nodes rather than persisted to disk -- 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

17 years, 2 months

4
10
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1087) Clustering scalability tests

by Tim Fox (JIRA)

Clustering scalability tests ---------------------------- Key: JBMESSAGING-1087 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1087 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox Fix For: Performance metrics, benchmarks and scalability testing Setup clustering scalabiity tests on the clustering lab. Design metrics and see how performance varies with number of nodes 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

17 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1192) Cannot gravitate data only stored in cache loader

by Brian Stansberry (JIRA)

Cannot gravitate data only stored in cache loader ------------------------------------------------- Key: JBCACHE-1192 URL: http://jira.jboss.com/jira/browse/JBCACHE-1192 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Eviction, Replication Affects Versions: 1.4.1.SP4, 1.4.1.SP3, 1.4.1.SP2, 1.4.1.SP1, 2.0.0.GA, 1.4.1.GA, 1.4.0.SP1, 1.4.0.GA Reporter: Brian Stansberry Assigned To: Manik Surtani Priority: Critical Fix For: 1.4.1.SP6, 2.1.0.GA If data has been evicted and is only available via a cacheloader, data gravitation fails to find it. The CacheImpl.gravitateData method only searches the in-memory state. -- 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

17 years, 2 months

2
6
0 / 0

[JBoss JIRA] Created: (JBCACHE-1209) Restore existing Option to InvocationContext in TreeCache._gravitateData

by Brian Stansberry (JIRA)

Restore existing Option to InvocationContext in TreeCache._gravitateData ------------------------------------------------------------------------ Key: JBCACHE-1209 URL: http://jira.jboss.com/jira/browse/JBCACHE-1209 Project: JBoss Cache Issue Type: Sub-task Security Level: Public (Everyone can see) Affects Versions: 1.4.1.SP6 Reporter: Brian Stansberry Assigned To: Manik Surtani Fix For: 1.4.1.SP6 The fix for JBCACHE-1192 has introduced a couple of problems that are manifesting themselves in numerous errors in the test suite: 1) _gravitateData changes the value of skipDataGravitation for the Option associated with the call, but then doesn't restore the correct value to *that* instance of Option. 2) _gravitateData calls get(Fqn), and that call actually results in the instance of Option that is associated with the thread being changed (see impl of get(Fqn). But, _gravitateData does not restore the original Option to the thread. Maybe not a problem if _gravitateData is called remotely, since there is no meaningful Option associated with the thread. But _gravitateData can now also be called by DataGravitationInterceptor.localBackupGet, and in that case there very well could be a meaningful Option associated with the thread, and it needs to be restored before _gravitateData returns. I'll attach a possible patch in a minute. -- 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

17 years, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JGRP-465) Deadlock in FC if RPC response blocks

by Brian Stansberry (JIRA)

Deadlock in FC if RPC response blocks ------------------------------------- Key: JGRP-465 URL: http://jira.jboss.com/jira/browse/JGRP-465 Project: JGroups Issue Type: Bug Affects Versions: 2.4.1 SP1 Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: 2.4.1 SP2 In 2.4.1.SP1 (and probably earlier) FC can deadlock if all up/down threads are set to false at and above FC and an incoming RPC loops back down the channel with its response. Following stack trace shows a deadlock situation (note the line numbers in FC are off from the cvs code; this occured with a patched FC version, but the patch is not relevant to this error): "IncomingPacketHandler (channel=Tomcat-Cluster)" daemon prio=1 tid=0xc8a68b60 nid=0x1ece in Object.wait() [0xc94d1000..0xc94d1f30] at java.lang.Object.wait(Native Method) at EDU.oswego.cs.dl.util.concurrent.CondVar.timedwait(CondVar.java:222) - locked <0xd187e398> (a EDU.oswego.cs.dl.util.concurrent.CondVar) at org.jgroups.protocols.FC.handleDownMessage(FC.java:394) at org.jgroups.protocols.FC.down(FC.java:336) at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517) at org.jgroups.protocols.FC.receiveDownEvent(FC.java:330) at org.jgroups.stack.Protocol.passDown(Protocol.java:551) at org.jgroups.protocols.FRAG2.down(FRAG2.java:167) at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517) at org.jgroups.stack.Protocol.passDown(Protocol.java:551) at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:294) at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517) at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:385) at org.jgroups.JChannel.down(JChannel.java:1231) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:790) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passDown(MessageDispatcher.java:767) at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:693) at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:544) at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:367) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:777) at org.jgroups.JChannel.up(JChannel.java:1091) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:377) at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:393) at org.jgroups.stack.Protocol.passUp(Protocol.java:538) at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:158) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488) at org.jgroups.stack.Protocol.passUp(Protocol.java:538) at org.jgroups.protocols.FRAG2.up(FRAG2.java:197) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488) at org.jgroups.stack.Protocol.passUp(Protocol.java:538) at org.jgroups.protocols.FC.up(FC.java:377) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488) at org.jgroups.stack.Protocol.passUp(Protocol.java:538) at org.jgroups.protocols.pbcast.GMS.up(GMS.java:768) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488) at org.jgroups.protocols.pbcast.GMS.receiveUpEvent(GMS.java:788) at org.jgroups.stack.Protocol.passUp(Protocol.java:538) at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:260) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488) at org.jgroups.stack.Protocol.passUp(Protocol.java:538) at org.jgroups.protocols.UNICAST.handleDataReceived(UNICAST.java:476) - locked <0xd1eec6d8> (a org.jgroups.protocols.UNICAST$Entry) at org.jgroups.protocols.UNICAST.up(UNICAST.java:206) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488) at org.jgroups.stack.Protocol.passUp(Protocol.java:538) at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:569) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488) at org.jgroups.stack.Protocol.passUp(Protocol.java:538) at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:170) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488) at org.jgroups.stack.Protocol.passUp(Protocol.java:538) at org.jgroups.protocols.FD.up(FD.java:300) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488) at org.jgroups.stack.Protocol.passUp(Protocol.java:538) at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488) at org.jgroups.stack.Protocol.passUp(Protocol.java:538) at org.jgroups.protocols.MERGE2.up(MERGE2.java:162) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488) at org.jgroups.stack.Protocol.passUp(Protocol.java:538) at org.jgroups.protocols.Discovery.up(Discovery.java:225) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488) at org.jgroups.stack.Protocol.passUp(Protocol.java:538) at org.jgroups.protocols.TP.handleIncomingMessage(TP.java:908) at org.jgroups.protocols.TP.handleIncomingPacket(TP.java:850) at org.jgroups.protocols.TP.access$400(TP.java:45) at org.jgroups.protocols.TP$IncomingPacketHandler.run(TP.java:1296) at java.lang.Thread.run(Thread.java:595) The thread carried an RPC up to RpcDispatcher and is waiting in FC.handleDownMessage() for credits to become available to send the RPC response. Those credits will never arrive, as the thread that is blocking is the one that would need to deliver the credits. This is less of an issue in 2.5. This is because 2.5. uses the concurrent stack and credit replenishments are sent as OOB messages on a separate thread. (Would still be an issue in 2.5 if the concurrent stack were disabled via configuration.) Hacky solution is to somehow flag the up thread and in handleDownMessage() check for the flag before blocking the thread. If the flag is set, don't block the thread -- just let it through, i.e. let it exceed max_credits. In cases like recent JBC releases where the vast majority of RPC responses are lightweight "null" responses, this is pretty safe. Need to add a config flag to disable the workaround though for use in applications where RPC responses frequently return large amounts of data. -- 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

17 years, 2 months

2
4
0 / 0

[JBoss JIRA] Created: (JBPM-1022) 3.2.1 Admin Console: Any user sees all users tasks

by Burr Sutter (JIRA)

3.2.1 Admin Console: Any user sees all users tasks --------------------------------------------------- Key: JBPM-1022 URL: http://jira.jboss.com/jira/browse/JBPM-1022 Project: JBoss jBPM Issue Type: Bug Components: Web Interface Affects Versions: jBPM jPDL 3.2.1 Reporter: Burr Sutter Assigned To: Tom Baeyens Priority: Blocker Fix For: jBPM jPDL 3.2.2 In the current Admin Console, any given user will see all other users tasks. Plus a user can "take" another person's assigned tasks even when they are not an "administrator". -- 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

17 years, 2 months

4
7
0 / 0

[JBoss JIRA] Created: (JBAS-3704) Add a notion of available interfaces to org.jboss.test.util.server.*

by Scott M Stark (JIRA)

Add a notion of available interfaces to org.jboss.test.util.server.* -------------------------------------------------------------------- Key: JBAS-3704 URL: http://jira.jboss.com/jira/browse/JBAS-3704 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Test Suite Affects Versions: JBossAS-4.0.4.GA Reporter: Scott M Stark Fix For: JBossAS-4.0.6.CR1 An issue with automating testing involving binding to specific addresses is that there is no predefined set of properties a testsuite descriptor can reference. The qa env has MYTESTIP_1 type of env vars set, and java 1.4.2+ has java.net.NetworkInterface, that could be used as the basis for defining jboss.server.iface.0..N system properties that configurations could rely on for setting one or more bind interfaces. We need to add this functionality to the server startup tasks. -- 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

17 years, 2 months

5
10
0 / 0

[JBoss JIRA] Updated: (JBREM-166) JMXConnectorServer will not start if using rmi invoker elsewhere

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-166?page=all ] Ron Sigal updated JBREM-166: ---------------------------- Fix Version/s: 2.4.0.Beta1 (Pinto) Assignee: (was: Tom Elrod) Adding fix version 2.4.0.Beta1. This issue seems to be related to JBAS-3885: JMXConnectorServer not respecting the -b value, recently fixed by Dimitris, who changed the creation of the RMI registry in org.jboss.mx.remoting.service.JMXConnectorServerService.start() to use a ServerSocketFactory that binds to a single host. Maybe the same needs to be done in org.jboss.remoting.transport.rmi.RMIServerInvoker. > JMXConnectorServer will not start if using rmi invoker elsewhere > ---------------------------------------------------------------- > > Key: JBREM-166 > URL: http://jira.jboss.com/jira/browse/JBREM-166 > Project: JBoss Remoting > Issue Type: Bug > Components: jmx remoting > Affects Versions: JMX Remoting 1.0.1 > Reporter: Tom Elrod > Fix For: JMX Remoting 1.0.2, 2.4.0.Beta1 (Pinto) > > > If have a remoting invoker using rmi transport, it will create a rmi registry. Then when the JMXConnectorServer starts, it will also try to create one. Even though is on a different port, will get the following exception: > java.rmi.server.ExportException: internal error: ObjID already in use > at sun.rmi.transport.ObjectTable.putTarget(ObjectTable.java:168) > at sun.rmi.transport.Transport.exportObject(Transport.java:69) > at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:190) > at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:382) > at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:116) > at sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:145) > at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:92) > at sun.rmi.registry.RegistryImpl.<init>(RegistryImpl.java:78) > at java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:164) > at org.jboss.mx.remoting.service.JMXConnectorServerService.start(JMXConnectorServerService.java:91) -- 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

17 years, 2 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 November 2007