January 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBESB-336) Check configuration assumptions for various listeners

by Mark Little (JIRA)

Check configuration assumptions for various listeners ----------------------------------------------------- Key: JBESB-336 URL: http://jira.jboss.com/jira/browse/JBESB-336 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation, Rosetta Affects Versions: 4.0 CR2 Reporter: Mark Little Assigned To: Esteban Schifman Priority: Critical Fix For: 4.0 What configuration assumptions do we make for each type of listener and do we document them? For example, it appears as though the notion of work directory, post directory etc for the file and ftp couriers assume that the directories are not shared, i.e., parent --> work --> post will work, but parent or parent --> work ----> post won't work. -- 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, 3 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-668) jrunit should allow TRACE level logging

by Ovidiu Feodorov (JIRA)

jrunit should allow TRACE level logging --------------------------------------- Key: JBREM-668 URL: http://jira.jboss.com/jira/browse/JBREM-668 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Ovidiu Feodorov Assigned To: Tom Elrod Fix For: 2.2.0.Alpha5 -- 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, 3 months

1
1
0 / 0

VIAGRA for $0.87 per pill

by Jerold Barber

men of Greece; this is certainly true wisdom, and this is that blood, to purchase these hearts of ours, and shall we only become the first-fruits of them that sleep; and as in Adam all righteousness of God in Christ Jesus, ‘who is the end of the whole posterity, in whose name he acted, became liable to the prison, and did not minister unto thee? Then shall he answer hearts can desire. Believers, you shall judge the evil, and name given under heaven, whereby they can be saved, but God's dear Son! To put off the old man, which is corrupt, and wisdom, propose a more consistent scheme to build you words of the text, “I determined not to know any thing Jerold Barber

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBESB-367) Spring integration exazmpl

by Mark Little (JIRA)

Spring integration exazmpl -------------------------- Key: JBESB-367 URL: http://jira.jboss.com/jira/browse/JBESB-367 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Mark Little Assigned To: Mark Little -- 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, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBESB-343) Tests should clean up after themselves.

by Kurt Stam (JIRA)

Tests should clean up after themselves. --------------------------------------- Key: JBESB-343 URL: http://jira.jboss.com/jira/browse/JBESB-343 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Environment: any Reporter: Kurt Stam Assigned To: Mark Little Priority: Minor Fix For: 4.0 My temp directory gets filled up by left-over files from unit tests. Tests should clean up after themselves! -- 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, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (JBREM-649) Concurrent exceptions on Lease when connecting/disconnecting new Clients

by Clebert Suconic (JIRA)

Concurrent exceptions on Lease when connecting/disconnecting new Clients ------------------------------------------------------------------------ Key: JBREM-649 URL: http://jira.jboss.com/jira/browse/JBREM-649 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Clebert Suconic Assigned To: Tom Elrod It looks like also there is a possibility of Server hang on these situations: On the exception bellow, a HashMap was changed while being iterated inside serialization. java.lang.reflect.InvocationTargetException at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.serial.persister.RegularObjectPersister.writeSlotWithMethod(RegularObjectPersister.java:120) at org.jboss.serial.persister.RegularObjectPersister.defaultWrite(RegularObjectPersister.java:86) at org.jboss.serial.persister.RegularObjectPersister.writeData(RegularObjectPersister.java:62) at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:276) at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectOutput.writeObject(DataContainer.java:206) at org.jboss.serial.persister.ObjectOutputStreamProxy.writeObjectOverride(ObjectOutputStreamProxy.java:60) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:274) at java.util.HashMap.writeObject(HashMap.java:986) at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.serial.persister.RegularObjectPersister.writeSlotWithMethod(RegularObjectPersister.java:120) at org.jboss.serial.persister.RegularObjectPersister.defaultWrite(RegularObjectPersister.java:86) at org.jboss.serial.persister.RegularObjectPersister.writeData(RegularObjectPersister.java:62) at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:276) at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectOutput.writeObject(DataContainer.java:206) at org.jboss.serial.persister.RegularObjectPersister.writeSlotWithFields(RegularObjectPersister.java:182) at org.jboss.serial.persister.RegularObjectPersister.defaultWrite(RegularObjectPersister.java:90) at org.jboss.serial.persister.RegularObjectPersister.writeData(RegularObjectPersister.java:62) at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:276) at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectOutput.writeObject(DataContainer.java:206) at org.jboss.serial.io.JBossObjectOutputStream.writeObjectOverride(JBossObjectOutputStream.java:181) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:274) at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObject(JavaSerializationManager.java:86) at org.jboss.remoting.marshal.serializable.SerializableMarshaller.write(SerializableMarshaller.java:84) at org.jboss.jms.server.remoting.JMSWireFormat.write(JMSWireFormat.java:310) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedWrite(MicroSocketClientInvoker.java:518) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:340) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:125) at org.jboss.remoting.LeasePinger.sendClientPing(LeasePinger.java:97) at org.jboss.remoting.LeasePinger$LeaseTimerTask.run(LeasePinger.java:216) at java.util.TimerThread.mainLoop(Timer.java:432) at java.util.TimerThread.run(Timer.java:382) Caused by: java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:782) at java.util.HashMap$EntryIterator.next(HashMap.java:824) at java.util.HashMap.writeObject(HashMap.java:984) ... 36 more -- 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, 3 months

2
6
0 / 0

[JBoss JIRA] Created: (JBAS-3984) workflow test (ignore - to be deleted)

by Alex Pinkin (JIRA)

workflow test (ignore - to be deleted) -------------------------------------- Key: JBAS-3984 URL: http://jira.jboss.com/jira/browse/JBAS-3984 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Alex Pinkin Assigned To: Alex Pinkin 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, 3 months

1
1
0 / 0

[JBoss JIRA] Deleted: (JBMESSAGING-745) Just a JIRA workflow test (to be deleted)

by Alex Pinkin (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-745?page=all ] Alex Pinkin deleted JBMESSAGING-745: ------------------------------------ > Just a JIRA workflow test (to be deleted) > ----------------------------------------- > > Key: JBMESSAGING-745 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-745 > Project: JBoss Messaging > Issue Type: Support Patch > Reporter: Alex Pinkin > Assigned To: Alex Pinkin > > testing JIRA workflow -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-745) Just a JIRA workflow test (to be deleted)

by Alex Pinkin (JIRA)

Just a JIRA workflow test (to be deleted) ----------------------------------------- Key: JBMESSAGING-745 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-745 Project: JBoss Messaging Issue Type: Support Patch Reporter: Alex Pinkin Assigned To: Alex Pinkin testing JIRA workflow -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-326) Create the concept of a "priority queue" to speed execution of certain remote method invocations

by Vladimir Blagojevic (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-326?page=all ] Vladimir Blagojevic updated JBCACHE-326: ---------------------------------------- Fix Version/s: 2.1.0.GA (was: 2.0.0.GA) Brian said: That should definitely be pushed out of 2.0.0. Maybe we should keep the JIRA open for a while, as it still may be a useful concept. Maybe not though; if you can't think of any situation where one message from a sender would block execution of another message from the *same* sender, then the JIRA probably serves no purpose. The case that led to the JIRA was: 1) prepare from server A acquires locks on B. 2) prepare from server C blocks up_thread on B waiting for locks. 3) commit/rollback from server A stuck in queue behind prepare from server C. ConcurrentStack solves that problem. Bela and I had a brief discussion on the JG dev list shortly before Xmas about adding the ability to execute RpcDispatcher calls using a thread pool / Executor. If we ever did implement JBCACHE-326, I'm sure it would be built on top of that feature. > Create the concept of a "priority queue" to speed execution of certain remote method invocations > ------------------------------------------------------------------------------------------------ > > Key: JBCACHE-326 > URL: http://jira.jboss.com/jira/browse/JBCACHE-326 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Brian Stansberry > Assigned To: Vladimir Blagojevic > Fix For: 2.1.0.GA > > > Change the handling of requests in JBossCache (another interceptor on top of ReplicationInterceptor): > - Create 2 queues (of MethodCall objects), one thread for each queue > - The regular MethodCalls like put(), remove() etc go into the default queue (A), where they are processed according to order (FIFO) > - The special calls like block(), _getState(), commit() or acks for PREPARE/COMMIT calls go into the other (priority) queue (B), these calls *CAN* be received out of sequence > - This way, an _getState() would always be processed and would be able to (1) stop the processing of queue A and (2) force- release any locks held > by on the tree. > _ This way commit() calls can promptly release locks, without having to wait behind other prepare calls. -- 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, 3 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 January 2007