April 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-5515) Failed to load users/passwords/role files

by Heiko Braun (JIRA)

Failed to load users/passwords/role files ----------------------------------------- Key: JBAS-5515 URL: http://jira.jboss.com/jira/browse/JBAS-5515 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Heiko Braun Fix For: JBossAS-5.0.0.CR1 21:25:41,277 ERROR [UsersRolesLoginModule] Failed to load users/passwords/role files java.io.IOException: No properties file: users.properties or defaults: defaultUsers.properties found at org.jboss.security.auth.spi.Util.loadProperties(Util.java:366) at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:186) at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:200) at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:127) When executing one-test: [junit] Running org.jboss.test.ws.jaxws.samples.context.WebServiceContextEJBTestCase [junit] Tests run: 3, Failures: 0, Errors: 3, Time elapsed: 2.421 sec [junit] Test org.jboss.test.ws.jaxws.samples.context.WebServiceContextEJBTestCase FAILED -- 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

14 years, 2 months

3
5
0 / 0

[JBoss JIRA] Created: (JBRULES-681) Multi-threaded local search solving

by Geoffrey De Smet (JIRA)

Multi-threaded local search solving ----------------------------------- Key: JBRULES-681 URL: http://jira.jboss.com/jira/browse/JBRULES-681 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Solver Reporter: Geoffrey De Smet Assigned To: Geoffrey De Smet Priority: Optional Use Future's to spread all possible moves in each step over a number of threads. This number of threads is equal to the number of cpu's by default, as no IO is done during solving. Problems: - each thread will needs it own WorkingMemory and during a step, each working memory will need to be updated - a bunch of classes will need to be thread safe, or at least visibility save, such as bestsolutionrecaller. - Barriers will be needed to collect the result of each step - decks might be a great way to spread out the load -- 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

14 years, 2 months

1
6
0 / 0

[JBoss JIRA] Created: (EJBTHREE-880) Hard-coded localhost in ejb3 test suite

by Aleksandar Kostadinov (JIRA)

Hard-coded localhost in ejb3 test suite --------------------------------------- Key: EJBTHREE-880 URL: http://jira.jboss.com/jira/browse/EJBTHREE-880 Project: EJB 3.0 Issue Type: Bug Reporter: Aleksandar Kostadinov When the ejb3 testsuite is run with "-Dnode0=IP1 -Dnode1=IP2" and IP1!=localhost there are some tests failing with "Retries exceeded, couldn't reconnect to 127.0.0.1:####". I see this for 4_0 and 4_2 jboss branches, but guess it's the same with head. One of the testcases is IiopRemoteUnitTestCase. I've checked ejb3/src/test/org/jboss/ejb3/test/iiop/unit/IiopRemoteUnitTestCase.java and there is 'props.put("java.naming.provider.url", "corbaloc::localhost:3528/NameService");'. Instead of localhost there should be used the node0 property. I guess the others have the same problem. -- 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

14 years, 3 months

6
16
0 / 0

[JBoss JIRA] Created: (JASSIST-44) Maven profiles for tools.jar should take account of Mac OS

by Martin Burger (JIRA)

Maven profiles for tools.jar should take account of Mac OS ---------------------------------------------------------- Key: JASSIST-44 URL: http://jira.jboss.com/jira/browse/JASSIST-44 Project: Javassist Issue Type: Bug Environment: Maven version: 2.0.8 Java version: 1.5.0_13 OS name: "mac os x" version: "10.4.11" arch: "i386" Family: "unix" Reporter: Martin Burger Assigned To: Shigeru Chiba The pom.xml uses different profiles to add the tools.jar to the dependencies. However, it is already included in the runtime for Mac OS X and some free JDKs and does not exist as a separate file 'tools.jar'. See: http://maven.apache.org/general.html#tools-jar-dependency As soon as http://jira.codehaus.org/browse/MNG-3106 gets fixed, activation should look like the following example: <activation> <jdk>1.6</jdk> <property> <name>java.vendor</name> <value>Sun Microsystems Inc.</value> </property> </activation> In the meantime <profiles> <profile> <id>tools.jar</id> <activation> <property> <name>java.vendor</name> <value>Sun Microsystems Inc.</value> </property> </activation> <dependencies> <dependency> <groupId>com.sun</groupId> <artifactId>tools</artifactId> <version>1.6</version> <scope>system</scope> <optional>true</optional> <systemPath>${java.home}/../lib/tools.jar</systemPath> </dependency> </dependencies> </profile> </profiles> should do the job. It could be a permanent solution because the different profiles differ only in the version element. -- 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

14 years, 3 months

2
5
0 / 0

[JBoss JIRA] Created: (JASSIST-106) Maven build doesn't work on Mac OS X

by Pete Muir (JIRA)

Maven build doesn't work on Mac OS X ------------------------------------ Key: JASSIST-106 URL: https://jira.jboss.org/jira/browse/JASSIST-106 Project: Javassist Issue Type: Task Affects Versions: 3.11.0.GA Reporter: Pete Muir Assignee: Shigeru Chiba It references tools.jar which doesn't exist. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JASSIST-96) Publish javassist to Maven central

by Pete Muir (JIRA)

Publish javassist to Maven central ---------------------------------- Key: JASSIST-96 URL: https://jira.jboss.org/jira/browse/JASSIST-96 Project: Javassist Issue Type: Task Reporter: Pete Muir It would be nice if Javassist were published to Maven central regularly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

4
15
0 / 0

[JBoss JIRA] Created: (JBAS-4526) JBossMQ UIL2 Read/Write Tasks should not be doing initialization

by Adrian Brock (JIRA)

JBossMQ UIL2 Read/Write Tasks should not be doing initialization ---------------------------------------------------------------- Key: JBAS-4526 URL: http://jira.jboss.com/jira/browse/JBAS-4526 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: JMS service Affects Versions: JBossAS-4.2.1.GA Reporter: Adrian Brock Assigned To: Adrian Brock Fix For: JBossAS-5.0.0.GA, JBossAS-4.2.2.CR1 The JBossMQ UIL2 Read/Write tasks both do their stream initialization when each thread starts. This code needs changing such that the streams are allocated before started the threads. Only if all resources can be succesfully allocated should we start the threads. -- 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

14 years, 3 months

3
5
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1732) Pooling strategy and configuration information needed at runtime

by Galder Zamarreno (JIRA)

Pooling strategy and configuration information needed at runtime ---------------------------------------------------------------- Key: EJBTHREE-1732 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1732 Project: EJB 3.0 Issue Type: Bug Components: ejb3 Affects Versions: AS 4.2.3.GA Reporter: Galder Zamarreno There needs to be a way at runtime to see what pooling strategy (including configuration options) an EJB3 bean is using. Currently, the only way to see this is by enabling TRACE on org.jboss.ejb3 and making an invocation to that EJB3 bean. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

2
7
0 / 0

[JBoss JIRA] Created: (JBAS-7674) Windows file locking problem with the data/jnp-service.url file

by Brian Stansberry (JIRA)

Windows file locking problem with the data/jnp-service.url file --------------------------------------------------------------- Key: JBAS-7674 URL: https://jira.jboss.org/jira/browse/JBAS-7674 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Management services Affects Versions: JBossAS-6.0.0.M1, JBossAS-5.1.0.GA Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.M2 In some circumstances, windows is reporting the AS is holding a lock on the data/jnp-service.url file when it isn't running. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

5
10
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1456) Messages stuck in being-delivered state in cluster

by Justin Bertram (JIRA)

Messages stuck in being-delivered state in cluster -------------------------------------------------- Key: JBMESSAGING-1456 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1456 Project: JBoss Messaging Issue Type: Bug Reporter: Justin Bertram Assignee: Tim Fox Priority: Critical Messages become "stuck" in being-delivered state when clients use a clustered XA connection factory in a cluster of at least 2 nodes. JBoss setup: -2 nodes of JBoss EAP 4.3 CP02 -commented out "ClusterPullConnectionFactory" in messaging-service.xml to prevent message redistribution and eliminate the "message suckers" as the potential culprit -MySQL backend using the default mysql-persistence-service.xml (from <JBOSS_HOME>/docs/examples/jms) Client setup: -both nodes have a client which is a separate process (i.e. not inside JBoss) -clients are Spring based -one client produces and consumes, the other client just consumes -both clients use the ClusteredXAConnectionFactory from the default connection-factories-service.xml -both clients publish to and consume from "queue/testDistributedQueue" -clients are configured to send persistent messages, use AUTO_ACKNOWLEDGE, and transacted sessions Symptoms of the issue: -when running the clients I watch the JMX-Console for the "queue/testDistributedQueue" -as the consumers pull messages off the queue I can see the MessageCount and DeliveringCount go to 0 every so often -after a period of time (usually a few hours) the MessageCount and DeliveringCount never go back to 0 -I "kill" the clients and wait for the DeliveringCount to go to 0, but it never does -after the clients are killed the ConsumerCount for the queue will drop, but never to 0 when messages are "stuck" -a thread dump reveals at least one JBM server session that is apparently stuck (it never goes away) - ostensibly this is the consumer that is showing in the JMX-Console for "queue/testDistributedQueue" -a "killall -3 java" doesn't produce anything from the clients so I know their dead -nothing is in any DLQ or expiry queue -the database contains as many rows in the JBM_MSG and JBM_MSG_REF tables as the DeliveringCount in the JMX-Console -rebooting the node with the stuck messages frees the messages to be consumed (i.e. un-sticks them) Other notes: -nothing else is happening on either node but running the client and running JBoss -this only appears to happen when a clustered connection factory is used. I tested using a normal connection factory and after 24 hours couldn't reproduce a stuck message. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

11
102
0 / 0

[JBoss JIRA] Created: (HIBERNATE-120) Hibernate maps type "timestamp" to Mysql's type "datetime" not "timestamp"

by zhou yanming (JIRA)

Hibernate maps type "timestamp" to Mysql's type "datetime" not "timestamp" -------------------------------------------------------------------------- Key: HIBERNATE-120 URL: https://jira.jboss.org/jira/browse/HIBERNATE-120 Project: Hibernate Integration Issue Type: Bug Reporter: zhou yanming Assignee: Steve Ebersole Priority: Critical datetime will trim millisecond record.setLastModified(new Date(1250053078708)); session.save(record); .... record = session.load(record.getId()); System.out.println(record.getLastModified()); // here is 125005307000 not expected 1250053078708 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

3
4
0 / 0

[JBoss JIRA] Created: (JBSER-119) Ensure compatibility with Trove

by Christian Effertz (JIRA)

Ensure compatibility with Trove ------------------------------- Key: JBSER-119 URL: https://jira.jboss.org/jira/browse/JBSER-119 Project: JBoss Serialization Issue Type: Thirdparty Change Affects Versions: 1.0.3 GA Reporter: Christian Effertz Assignee: Clebert Suconic Fix For: 1.1.0 Beta The version of [Trove|http://trove4j.sourceforge.net] that is shipped with the latest version of JBoss Serialization is quite old. Trove has had a major release since it was bundled last time for Version 1.0.3 and seems to be facing a next major version 3.0. As it is stated in their release notes that they had some performance improvements and Bug Fixes I would assume that JBoss Serialization would profit in terms of stability and performance if using the newer versions. I will give it a try in our dev system, but it would be more comforting to get a statement if your testsuite turned green if using the newer version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (JBEE-22) Add jboss-jaxrs-api_1.1_spec

by Shelly McGowan (JIRA)

Add jboss-jaxrs-api_1.1_spec ---------------------------- Key: JBEE-22 URL: https://jira.jboss.org/jira/browse/JBEE-22 Project: JBoss JavaEE APIs Issue Type: Sub-task Reporter: Shelly McGowan -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
9
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1330) EJB timer service should use a thread pool to avoid OOM

by Galder Zamarreno (JIRA)

EJB timer service should use a thread pool to avoid OOM ------------------------------------------------------- Key: EJBTHREE-1330 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1330 Project: EJB 3.0 Issue Type: Bug Components: pool Affects Versions: AS 4.2.2.GA Reporter: Galder Zamarreno Assigned To: Galder Zamarreno Priority: Minor The default EJB timer service used by the EJB3 layer is based on org.jboss.ejb3.timerservice.jboss.JBossTimerServiceFactory which delegates to the standard org.jboss.ejb.txtimer.EJBTimerService. For EJB3 beans using the EJB timer service the thread local pool should not be used. Since the current EJB timer service creates a new thread for each timer being created, the thread local pool will create a matching instance of the bean for that thread. Thus the number of active instances in total can effectively grow unchecked and thus an OOM will occur. -- 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

14 years, 4 months

5
8
0 / 0

[JBoss JIRA] Created: (JBSER-117) Problem with JBoss serializing of dynamic proxies

by Maksym Ivanchenko (JIRA)

Problem with JBoss serializing of dynamic proxies ------------------------------------------------- Key: JBSER-117 URL: https://jira.jboss.org/jira/browse/JBSER-117 Project: JBoss Serialization Issue Type: Bug Affects Versions: 1.0.3 GA Reporter: Maksym Ivanchenko Assignee: Clebert Suconic When we try to serialize a proxy that contains some child entity which points to proxy itself the following exception occurs: org.jboss.serial.exception.SerializationException: Object reference 1 was not found Simple test case for problem reproducing: import java.io.Serializable; import java.lang.reflect.InvocationHandler; import java.lang.reflect.Method; import java.lang.reflect.Proxy; import org.jboss.serial.io.JBossObjectOutputStream; import org.junit.Test; public class StandaloneProxySerializationTest { @Test public void testSerialization() throws Exception { ISampleEntity entity = new SampleEntityImpl(); Class<?>[] interfaces = new Class<?>[] {ISampleEntity.class}; SampleEntityInvocationHandler handler = new SampleEntityInvocationHandler(entity); ISampleEntity proxy = (ISampleEntity) Proxy.newProxyInstance(Thread.currentThread() .getContextClassLoader(), interfaces, handler); ISampleEntity childEntity = new SampleEntityImpl(); proxy.setChild(childEntity); childEntity.setParent(proxy); JBossObjectOutputStream jbossSerializer = new JBossObjectOutputStream(null); jbossSerializer.smartClone(proxy); } private static interface ISampleEntity { public ISampleEntity getParent(); public void setParent(ISampleEntity parent); public ISampleEntity getChild(); public void setChild(ISampleEntity child); } private static class SampleEntityImpl implements ISampleEntity, Serializable { private static final long serialVersionUID = 1L; private ISampleEntity parent; private ISampleEntity child; @Override public ISampleEntity getParent() { return parent; } @Override public void setParent(ISampleEntity parent) { this.parent = parent; } @Override public ISampleEntity getChild() { return child; } @Override public void setChild(ISampleEntity child) { this.child = child; } } private static class SampleEntityInvocationHandler implements InvocationHandler, Serializable { private static final long serialVersionUID = 1L; private ISampleEntity entity; public SampleEntityInvocationHandler(ISampleEntity entity) { this.entity = entity; } @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { return method.invoke(entity, args); } } } Upon ivestigating this issue we found that the problem is in ProxyPersister.readData() method. It reads the handler, the proxy class, constructs a proxy and only then puts it to cache. But if a proxy data contains proxy itself then it tries to find it by reference (which is not in cache yet, because the handler is still being read). So it throws "Object reference not found" exception. We worked around this problem by introducing an InvocationHandler wrapper in ProxyPersister: Patched ProxyPersister.java: /* * JBoss, Home of Professional Open Source * Copyright 2005, JBoss Inc., and individual contributors as indicated * by the @authors tag. See the copyright.txt in the distribution for a * full listing of individual contributors. * * This is free software; you can redistribute it and/or modify it * under the terms of the GNU Lesser General Public License as * published by the Free Software Foundation; either version 2.1 of * the License, or (at your option) any later version. * * This software is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this software; if not, write to the Free * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA * 02110-1301 USA, or see the FSF site: http://www.fsf.org. */ package org.jboss.serial.persister; import java.io.IOException; import java.io.ObjectInput; import java.io.ObjectOutput; import java.lang.reflect.Constructor; import java.lang.reflect.InvocationHandler; import java.lang.reflect.InvocationTargetException; import java.lang.reflect.Method; import java.lang.reflect.Proxy; import org.jboss.serial.classmetamodel.ClassMetaData; import org.jboss.serial.classmetamodel.StreamingClass; import org.jboss.serial.exception.SerializationException; import org.jboss.serial.objectmetamodel.ObjectSubstitutionInterface; import org.jboss.serial.objectmetamodel.ObjectsCache; /** * $Id: ProxyPersister.java,v 1.11 2006/04/24 23:49:40 csuconic Exp $ * * @author <a href="mailto:clebert.suconic@jboss.com">Clebert Suconic</a> */ public class ProxyPersister implements Persister { private byte id; public byte getId() { return id; } public void setId(byte id) { this.id = id; } public void writeData(ClassMetaData metaData, ObjectOutput output, Object obj, ObjectSubstitutionInterface substitution) throws IOException{ Object handler = Proxy.getInvocationHandler(obj); output.writeObject(obj.getClass()); output.writeObject(handler); } static class InvocationHandlerWrapper implements InvocationHandler { private InvocationHandler wrappedHandler; public void setWrappedHandler(InvocationHandler wrappedHandler) { this.wrappedHandler = wrappedHandler; } public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { return wrappedHandler.invoke(proxy, method, args); } } public Object readData (ClassLoader loader, StreamingClass streaming, ClassMetaData metaData, int referenceId, ObjectsCache cache, ObjectInput input, ObjectSubstitutionInterface substitution) throws IOException{ try { Class proxy = (Class)input.readObject(); Constructor constructor = proxy.getConstructor(new Class[] { InvocationHandler.class }); InvocationHandlerWrapper wrapper = new InvocationHandlerWrapper(); Object obj = constructor.newInstance(new Object[]{wrapper}); cache.putObjectInCacheRead(referenceId,obj); Object handler = input.readObject(); wrapper.setWrappedHandler((InvocationHandler) handler); return obj; } catch (ClassNotFoundException e) { throw new SerializationException(e); } catch (NoSuchMethodException e) { throw new SerializationException(e); } catch (IllegalAccessException e) { throw new SerializationException(e); } catch (InstantiationException e) { throw new SerializationException(e); } catch (InvocationTargetException e) { throw new SerializationException(e); } } public boolean canPersist(Object obj) { // not implemented return false; } } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

3
3
0 / 0

[JBoss JIRA] Created: (JBRULES-2293) Classpath resources being scanned by ResourceChangeScanner could cause improper resource removal

by Steve Ronderos (JIRA)

Classpath resources being scanned by ResourceChangeScanner could cause improper resource removal ------------------------------------------------------------------------------------------------ Key: JBRULES-2293 URL: https://jira.jboss.org/jira/browse/JBRULES-2293 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.0.1.FINAL Environment: Windows XP Java 5 Running in Oracle OC4J 10.1.3.2 Reporter: Steve Ronderos Assignee: Mark Proctor I encountered an issue today with my KnowledgeAgent removing resources from its RuleBase shortly after creating it. I have the ResourceChangeScanner running in my application. I tracked the issue back to the scan() method in ResourceChangeScannerImpl. It appears that the method is trying to identify resources that are no longer available and remove them from both the RuleBase and future scans. To do this it is checking lastModified on the resource and on a result of 0 removing the resource. The resources that I configured in my change-set definitely still exist, but due to URL handler implementation provided by my classloader, getLastModified always returns 0. (The resource I'm retrieving is coming from a jar that is in my application's classpath and the URL handler implementation is oracle.classloader.SharedCodeSourceURL) Full Email Group trail: http://www.nabble.com/Issue-with-ResourceChangeScanner-td25792358.html Michael recommends to never scan classpath resources. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

6
13
0 / 0

[JBoss JIRA] Created: (JBRULES-1880) Can fire rules after disposing the Stateful session

by Sravanthi Tipirneni (JIRA)

Can fire rules after disposing the Stateful session --------------------------------------------------- Key: JBRULES-1880 URL: https://jira.jboss.org/jira/browse/JBRULES-1880 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.7 Reporter: Sravanthi Tipirneni Assignee: Mark Proctor Priority: Minor I can access the session and fire rules even after the session is disposed using the dispose method -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

3
5
0 / 0

[JBoss JIRA] Created: (JBRULES-2124) KnowledgeAgent should load knowledge bases directly from Resource (bypassing the ChangeSet)

by Jürgen Schiewe (JIRA)

KnowledgeAgent should load knowledge bases directly from Resource (bypassing the ChangeSet) ------------------------------------------------------------------------------------------- Key: JBRULES-2124 URL: https://jira.jboss.org/jira/browse/JBRULES-2124 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-api, drools-core Affects Versions: 5.0.1.FINAL Reporter: Jürgen Schiewe Assignee: Mark Proctor We develop Drools based applications and use Guvnor as a a repository. Hard-coding the hostname where Guvnor runs is not an option for us because the names are different in each installation and we do not want to modify all the changeset.xml files for each deployment. Instead we would pass one (or more) Resources to the KnowledgeAgent and let it do the monitoring. This would allow us to build URLs dynamically from our system environment configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

3
5
0 / 0

[JBoss JIRA] Created: (JGRP-1001) Use ByteMan / Metronome to inject faults for testing

by Bela Ban (JIRA)

Use ByteMan / Metronome to inject faults for testing ---------------------------------------------------- Key: JGRP-1001 URL: https://jira.jboss.org/jira/browse/JGRP-1001 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 Use ByteMan (jboss.org/byteman) to simulate issues that can happen at runtime: do this in unit tests. For example: crash of merge leader after initial round (who frees the locks ?) (same for FLUSH) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

3
7
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1721) Implement @Asynchronous

by Andrew Lee Rubinger (JIRA)

Implement @Asynchronous ------------------------ Key: EJBTHREE-1721 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1721 Project: EJB 3.0 Issue Type: Task Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger Fix For: EJB 3.1 Container task for @Asynchronous handling as specified by EJB 3.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

4
5
0 / 0

[JBoss JIRA] Created: (JBAS-7856) parameter element missing value in profile.xml

by thamizhelango natarajan (JIRA)

parameter element missing value in profile.xml ---------------------------------------------- Key: JBAS-7856 URL: https://jira.jboss.org/jira/browse/JBAS-7856 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.1.0.GA Environment: Windows,X86 Reporter: thamizhelango natarajan <bean name="AttachmentStore" class="org.jboss.system.server.profileservice.repository.AbstractAttachmentStore"> <constructor><parameter class="java.io.File"><inject bean="BootstrapProfileFactory" property="attachmentStoreRoot" /></parameter></constructor> The parameter element missing class attribute -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

2
1
0 / 0

[JBoss JIRA] Created: (JBLOGGING-30) TCLFilter fails to get correct URLs from classloader in AS-5

by jaikiran pai (JIRA)

TCLFilter fails to get correct URLs from classloader in AS-5 -------------------------------------------------------------- Key: JBLOGGING-30 URL: https://jira.jboss.org/jira/browse/JBLOGGING-30 Project: JBoss Logging Issue Type: Bug Security Level: Public (Everyone can see) Components: jboss-logging-log4j Affects Versions: 2.1.0.GA-jboss-logging Reporter: jaikiran pai Assignee: jaikiran pai As explained in JBAS-6532, the TCLFilter doesn't work in AS-5 because it never attempts to use the URLClassLoader while retrieving the Classloader URLs. A patch is attached to that JIRA (details of the patch are in the forum thread) which needs to be applied in jboss-logging-log4j component to get this working. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

5
9
0 / 0

[JBoss JIRA] Created: (JBRULES-443) Release drools binaries with debug information

by Juergen none (JIRA)

Release drools binaries with debug information ---------------------------------------------- Key: JBRULES-443 URL: http://jira.jboss.com/jira/browse/JBRULES-443 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: All Reporter: Juergen none Assigned To: Mark Proctor Priority: Trivial Would it be possible to supply a debug-build of the binaries in addition to the existing downloads (where at least the drools jar files are without debug-info)? -- 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

14 years, 5 months

3
4
0 / 0

[JBoss JIRA] Created: (JGRP-1002) Merge: make the coordinator remain the same if possible after a merge

by Bela Ban (JIRA)

Merge: make the coordinator remain the same if possible after a merge --------------------------------------------------------------------- Key: JGRP-1002 URL: https://jira.jboss.org/jira/browse/JGRP-1002 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.0 When we have {C, A, B} and split into {C,A} and {B}, then a merge will produce {A,B,C}. Therefore the coord is moved from C to A. For certain apps, e.g. JBoss singletons, this is not good, as we're moving the singleton services from a perfectly healthy node to a different node. GOAL: come up with a deterministic policy of picking a coord such that we minimize coord switching if the existing coord is still member of the cluster. This depends on or is related to the flexible coord pick policy JIRA issue -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAS-7965) jta resource recovery problem

by Nicolae Petridean (JIRA)

jta resource recovery problem ----------------------------- Key: JBAS-7965 URL: https://jira.jboss.org/jira/browse/JBAS-7965 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Transaction Manager (Arjuna) Reporter: Nicolae Petridean Assignee: Jonathan Halliday Priority: Critical Hi all, i noticed that there is some problems with the transaction recovery in JBOSS. When a number of warnings like this : "WARN oggerI18N om.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa om.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa Could not find new XAResource to use for recovering non-serializable XAResource" appear , at some time the exceptions mechanism is affected (the exceptions are not thrown anymore). If the application uses timers those are also blocked (the timeouts dont appear anymore), it seems that the transcations that are not finished are blocking the timers. Why aren't those transactions just ended after some specific time ? Or is there another way to deal with the situation ? Thanks in advance, Nicu -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

3
2
0 / 0

[JBoss JIRA] Created: (JBAS-7930) Set the port_range on JGroups stacks to 1

by Brian Stansberry (JIRA)

Set the port_range on JGroups stacks to 1 ----------------------------------------- Key: JBAS-7930 URL: https://jira.jboss.org/jira/browse/JBAS-7930 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.M4 Lock down the ports. Do this for M4 as it may lead to testsuite troubles on slaves until we identify ports where there aren't conflicts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

7
12
0 / 0

[JBoss JIRA] Created: (JBAS-6532) TCLFilter doesn't work in jboss 5 with war's in any documented way

by robert lazarski (JIRA)

TCLFilter doesn't work in jboss 5 with war's in any documented way ------------------------------------------------------------------ Key: JBAS-6532 URL: https://jira.jboss.org/jira/browse/JBAS-6532 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Logging Affects Versions: JBossAS-5.0.0.GA Environment: jdk 6, linux Reporter: robert lazarski Assignee: Scott M Stark Reading this doc: http://www.jboss.org/community/docs/DOC-12203 Indicates a *-exp.war syntax is needed for TCLFilter war use, but there are no files of that type on my system running jboss 5. I've tried all the possible combinations I can think of, posted the problem to the forum, and the result is always that the file sizes and contents of the log files generated are exactly the same for the different war's, ie, no separated content. Here's my current config: <appender name="penguinLog" class="org.apache.log4j.FileAppender"> <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"></errorHandler> <param name="Append" value="false"/> <param name="File" value="${jboss.server.home.dir}/log/penguinLog.log"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%d %-5p %c{1} %m%n"/> </layout> <filter class="org.jboss.logging.filter.TCLFilter"> <param name="AcceptOnMatch" value="true"/> <param name="DeployURL" value="penguin"/> </filter> </appender> <appender name="wtfLog" class="org.apache.log4j.FileAppender"> <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"></errorHandler> <param name="Append" value="false"/> <param name="File" value="${jboss.server.home.dir}/log/wtfLog.log"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%d %-5p %c{1} %m%n"/> </layout> <filter class="org.jboss.logging.filter.TCLFilter"> <param name="AcceptOnMatch" value="true"/> <param name="DeployURL" value="wtf-exp.war"/> </filter> </appender> <root> <appender-ref ref="CONSOLE"/> <appender-ref ref="FILE"/> <appender-ref ref="penguinLog"/> <appender-ref ref="wtfLog"/> </root> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

7
13
0 / 0

[JBoss JIRA] Created: (JBWEB-160) XNIO Connector

by Remy Maucherat (JIRA)

XNIO Connector -------------- Key: JBWEB-160 URL: https://jira.jboss.org/jira/browse/JBWEB-160 Project: JBoss Web Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Remy Maucherat Assignee: Remy Maucherat Experiment with XNIO connector to determine if it makes sense to include one in JBW. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-6657) managementView.load() fails to merge ServerInfo, ThreadPool, GlobalRequestProcessor, and Host ManagedObjects

by Ian Springer (JIRA)

managementView.load() fails to merge ServerInfo, ThreadPool, GlobalRequestProcessor, and Host ManagedObjects ------------------------------------------------------------------------------------------------------------ Key: JBAS-6657 URL: https://jira.jboss.org/jira/browse/JBAS-6657 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: ProfileService Reporter: Ian Springer Assignee: Scott M Stark Fix For: JBossAS-5.1.0.CR1 These are all MOs that are needed by the Embedded Console. Here's the log output: 10:47:18,464 DEBUG [ProfileServiceFactory] About to load profile via Management View... 10:47:23,964 WARN [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null 10:47:23,980 WARN [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null 10:47:57,870 WARN [ManagementViewImpl] Failed to merged the following runtime ManagedObjects: {jboss.system:type=ServerInfo/jboss.system:type=ServerInfo=ManagedObject{jboss.system:type=ServerInfo}, jboss.web:name=http-127.0.0.1-8080,type=ThreadPool/=ManagedObject{jboss.web:name=http-127.0.0.1-8080,type=ThreadPool}, jboss.web:name=http-127.0.0.1-8080,type=GlobalRequestProcessor/=ManagedObject{jboss.web:name=http-127.0.0.1-8080,type=GlobalRequestProcessor}, jboss.web:host=127.0.0.1,type=Host/=ManagedObject{jboss.web:host=127.0.0.1,type=Host}} 10:48:00,917 DEBUG [ProfileServiceFactory] Loaded profile via Management View in 42453 milliseconds. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

4
3
0 / 0

[JBoss JIRA] Created: (JBREM-552) cannot init cause of ClassCastException

by John Mazzitelli (JIRA)

cannot init cause of ClassCastException --------------------------------------- Key: JBREM-552 URL: http://jira.jboss.com/jira/browse/JBREM-552 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.Beta2 (Boon) Reporter: John Mazzitelli Assigned To: Tom Elrod Priority: Minor Fix For: 2.0.0.CR1 (Boon) I'm in a catch clause within InvokerRegistry and I'm getting a weird exception thrown: java.lang.IllegalStateException: Can't overwrite cause at java.lang.Throwable.initCause(Throwable.java:320) at org.jboss.remoting.InvokerRegistry.loadClientInvoker(InvokerRegistry.java:447) at org.jboss.remoting.InvokerRegistry.createClientInvoker(InvokerRegistry.java:324) at org.jboss.remoting.Client.connect(Client.java:385) at org.jboss.on.communications.command.client.JBossRemotingRemoteCommunicator.getRemotingClient(JBossRemotingRemoteCommunicator.java:470) at org.jboss.on.communications.command.client.JBossRemotingRemoteCommunicator.send(JBossRemotingRemoteCommunicator.java:430) at org.jboss.on.communications.command.client.AbstractCommandClient.invoke(AbstractCommandClient.java:167) at org.jboss.on.communications.command.client.ClientCommandSender.send(ClientCommandSender.java:820) at org.jboss.on.communications.command.client.ServerPollingThread.run(ServerPollingThread.java:102) Look at line 447 and you'll see it is trying to init the cause of a ClassNotFoundException. Running in a debugger, the newly constructed exception created on 446 has a null cause. Looking then at Throwable.initCause and you'll see a null cause causes this IllegalStateException to be thrown. The cause needs to be "this", not null (I don't know why, seems like it should also look for null, but whatever - that's the way the JDK is written). The fix is simple - use the constructor that takes a throwable as its second parameter. Not sure why initCause it being used, as opposed to this constructor. e.g.: new ClassNotFoundException("Can not invoke loadClientInvokerClass method on " + transportFactoryClass, e); (notice the ", e" parameter). There are three other instances where initCause is called on ClassNotFoundException that also need to be fixed. See the other catch clauses in here. -- 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

14 years, 6 months

5
5
0 / 0

[JBoss JIRA] Created: (SECURITY-176) Implement JBossRequestContext.asElement(Document)

by Anil Saldhana (JIRA)

Implement JBossRequestContext.asElement(Document) ------------------------------------------------- Key: SECURITY-176 URL: http://jira.jboss.com/jira/browse/SECURITY-176 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: JBossXACML Affects Versions: 2.0.2-BETA6 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: 2.0.2.GA If provided a Document, then create an element with the request details. Pretty cumbersome process. -- 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

14 years, 6 months

4
4
0 / 0

[JBoss JIRA] Created: (SECURITY-177) Implement JBossResponseContext.asElement(Document)

by Anil Saldhana (JIRA)

Implement JBossResponseContext.asElement(Document) -------------------------------------------------- Key: SECURITY-177 URL: http://jira.jboss.com/jira/browse/SECURITY-177 Project: JBoss Security and Identity Management Issue Type: Sub-task Security Level: Public (Everyone can see) Components: JBossXACML Affects Versions: 2.0.2-BETA6 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: 2.0.2.GA -- 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

14 years, 6 months

3
3
0 / 0

[JBoss JIRA] Created: (JGRP-1194) Revisit implementation of TUNNEL and shared transport

by Vladimir Blagojevic (JIRA)

Revisit implementation of TUNNEL and shared transport ----------------------------------------------------- Key: JGRP-1194 URL: https://jira.jboss.org/jira/browse/JGRP-1194 Project: JGroups Issue Type: Task Affects Versions: 2.9, 2.8 Reporter: Vladimir Blagojevic Assignee: Vladimir Blagojevic Fix For: 3.0 TUNNEL and shared transport are not supported at the moment (2.10.Alpha5). The main complexity behind TUNNEL and shared transport is that we have to change StubReceiver model. StubReceiver reads messages of the socket on the TUNNEL side. With shared transport turned on StubReceiver would have to be changed because we are receiving byte arrays for all channels sharing transport. We need some special StubReceiver multiplexer so to speak which will read messages and then pass off the byte arrays to other Receivers which will in turn pass them as messages to appropriate channel above transport. Each byte array passed around have to be pre appended with some identifier....and so on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

4
3
0 / 0

[JBoss JIRA] Created: (JGRP-809) Copyless stack

by Bela Ban (JIRA)

Copyless stack -------------- Key: JGRP-809 URL: https://jira.jboss.org/jira/browse/JGRP-809 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 Currently (as of 2.7), the transport reads the contents of a received packet into a buffer, then passes a *copy* of the buffer to a thread from the OOB or incoming thread pools. To prevent this copy, we can - have the receiver read only the version and OOB flag (to see which thread pool to dispatch the packet to) - pass a ref to the socket to a thread from the incoming of OOB pool, have that thread read the packet and return - each thread in the pool has its own buffer into which the buffer is read from the socket Possibly use NIO: we can install a selector and get woken up whenever data to be read is present. At that point, we can pass the ref to the socket to the handler thread and return immediately. NIO with channels for multicast sockets is available only in JDK 7 (or 8?), so this is a bit off... However, we can already implement this with reading the version and flags bytes and then passing the socket to the handler -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

2
6
0 / 0

[JBoss JIRA] Created: (JGRP-815) Scatter/Gather to avoid copying

by Bela Ban (JIRA)

Scatter/Gather to avoid copying ------------------------------- Key: JGRP-815 URL: https://jira.jboss.org/jira/browse/JGRP-815 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 When we invoke Channel.send(), we pass a bufffer to JGroups. At the transport level, JGroups marshals the sender and destination address, plus all headers and the buffer into a new byte[] buffer, which is then passed to the socket (DatagramSocket, MulticastSocket, Socket). We cannot do gathering writes on a DatagramSocket because DatagramSocket doesn't expose this functionality, contrary to a DatagramChannel. We could avoid having to copy the user's buffer by using gathering writes: effectively passing to the socket NIO ByteBuffers containing: 1: Src and dest address plus flags, plus possibly size 2: The marshalled headers 3: The buffer passed to JGroups by the user We can obtain a gathering-write channel as follows: ByteBuffer[] buffers; // contains the 3 byte buffers above DatagramSocket sock; DatagramChannel ch=sock.getChannel(); ch.write(buffers, 0, length); // length is the number of bytes of the total marshalled message This is supported by a GatheringByteChannel. I don't think there's currently a need to do scattered reads, but this needs to get investigated more. Also investigate whether MulticastSockets support gathering writes (whether they expose the correct DatagramChannel). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

2
8
0 / 0

[JBoss JIRA] Created: (JGRP-816) TP: avoid copying when receiving data

by Bela Ban (JIRA)

TP: avoid copying when receiving data ------------------------------------- Key: JGRP-816 URL: https://jira.jboss.org/jira/browse/JGRP-816 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 Currently, we receive data into a byte[] buffer, e.g. from DatagramSocket.receive(), but then have to COPY buffer when passing it to a worker from the thread pool. The copy is needed because the next DatargamSocket.receive() will overwrite the contents of buffer, and if the worker thread is still unmarshalling the data from the buffer, it might read corrupt contents. To overcome this, investigate the following: - Every worker thread has it own buffer - When the thread has been idle for N seconds and is removed from the pool, that buffer will be discarded - We create DatagramChannels from the socket(s) (DatagramSocket, MulticastSocket or Socket) - A selector is called when new data is available on the socket - The key returned by the selector points to the right channel - We pass the channel to a thread pool worker thread and continue with the select() loop - The worker then reads the data into its own buffer, unmarshalls it and passed it up the stack ==> No copy of the buffer is required as the thread's buffer is available until the message has been processed (usually until message unmarshalling) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

2
10
0 / 0

[JBoss JIRA] Created: (JGRP-886) TCP: single implementation based on NIO

by Bela Ban (JIRA)

TCP: single implementation based on NIO --------------------------------------- Key: JGRP-886 URL: https://jira.jboss.org/jira/browse/JGRP-886 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 Merge TCP and TCP_NIO into one protocol. Adapt it to use NIO2 (when available). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

3
8
0 / 0

[JBoss JIRA] Created: (JBREM-902) InvocationRequest need SSLSession for certificates and principal in sslsocket transport

by ya xiang (JIRA)

InvocationRequest need SSLSession for certificates and principal in sslsocket transport --------------------------------------------------------------------------------------- Key: JBREM-902 URL: http://jira.jboss.com/jira/browse/JBREM-902 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: security Reporter: ya xiang In a SSL context, there is a real need for check principal and certificates. There are ways to do this, but current jboss remoting not provide it, just provider socket remote address as sessionId. seems not enough. -- 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

14 years, 6 months

2
5
0 / 0

[JBoss JIRA] Created: (JBREM-1138) JBREM-1127 - ClassCastExceptions arising from Unmarsharller/Classloader caching in MicroRemoteClientInvoker

by Galder Zamarreño (JIRA)

JBREM-1127 - ClassCastExceptions arising from Unmarsharller/Classloader caching in MicroRemoteClientInvoker ----------------------------------------------------------------------------------------------------------- Key: JBREM-1138 URL: https://jira.jboss.org/jira/browse/JBREM-1138 Project: JBoss Remoting Issue Type: Support Patch Security Level: Public (Everyone can see) Reporter: Galder Zamarreño Assignee: Galder Zamarreño Port JBREM-1127 to a one-off patch so that classloading issues are avoided with paralell isolated EAR invocations using different versions of same class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

2
3
0 / 0

[JBoss JIRA] Created: (JBREM-1169) Bisocket connection won't be closed if pulling out the ethernet cable between client and server. The failure detection code won't close the failure connection, as a result, the subsequent requests will hang after connection account exceeds the threshold

by mingjun jiang (JIRA)

Bisocket connection won't be closed if pulling out the ethernet cable between client and server. The failure detection code won't close the failure connection, as a result, the subsequent requests will hang after connection account exceeds the threshold ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBREM-1169 URL: https://jira.jboss.org/jira/browse/JBREM-1169 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: detection Affects Versions: 2.2.3.SP1 Environment: OS: Windows Server 2003. JBoss App Server 4.2.3.GA, JBoss Messaging 1.4.5 GA, JBoss Remoting 2.2.3 SP1 Reporter: mingjun jiang We are using JBoss App Server 4.2.3.GA, JBoss Messaging 1.4.5 GA and JBoss Remoting 2.2.3 SP1. In our application, there are a lot of Message listeners running on the client side, these message listeners will receive messages from queue/topic deployed in JBoss Messaging Configuration: We created our own JMS Connection factory which uses the default remoting connector. As you know, the default remoting connector is configured to use the bisocket transport. We didn't change the default value of the remoting connector During we run our application, we open the JBoss web console to monitor the value of currentClientPoolSize under "Jboss.remoting" JMX MBean. How to reproduce this issue: 1. Run 5 message listeners in the client side to receive messages from JBoss Messaging, then we observe the value of currentClientPoolSize is 10 2. After processing several messages, we manually pull out the ethernet cable. The value of currentClientPoolSize is still 10. 3. We run another 5 message listeners in client side, then the value of currentClientPoolSize will become 20 4. After we do the same operations above several times, the value of currentClientPoolSize will increase continuously. Once the value of currentClientPoolSize is equal to the MaxPoolSize, then the subsequent incoming client requests will hang, and we will encounter the following exception in server side 2009-10-20 18:08:09,655 ERROR [org.jboss.remoting.transport.socket.ServerThread] Worker thread initialization failure java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read(BufferedInputStream.java:235) at java.io.FilterInputStream.read(FilterInputStream.java:66) at org.jboss.remoting.transport.socket.ServerThread.readVersion(ServerThread.java:859) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:545) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:406) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:173) Conclusion: JBoss Messaging won't close the failure connections if they are caused by manually pulling out ethernet cable. As a result, the value of currentClientPoolSize will increase continuously and finally the new client requests will hang Note: If we killed the process of message listener in client side, then the value of currentClientPoolSize will decrease to 0 immediately, it seems that the server could detect the failure connection and perform the corresponding resource releasing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

4
5
0 / 0

[JBoss JIRA] Created: (JBREM-1054) Annotation to automatically return new transporters types

by David Lloyd (JIRA)

Annotation to automatically return new transporters types --------------------------------------------------------- Key: JBREM-1054 URL: https://jira.jboss.org/jira/browse/JBREM-1054 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: r3 api Reporter: David Lloyd Priority: Optional Fix For: 3.1.0.Beta1 It would be cool if a transporter interface (or an implementing class of that interface) could have methods which sport an annotation that indicates that the return value of that method, if it is an interface, should be automatically wrapped into a transporter (if invoked via a transporter). This way, complex remote object structures can be easily created and used. Also handy would be a simple way of notating such methods when the interface and implementation are already existent. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

3
14
0 / 0

[JBoss JIRA] Created: (JBREM-857) transporterclient not thread-safe for failover

by craig bordelon (JIRA)

transporterclient not thread-safe for failover ---------------------------------------------- Key: JBREM-857 URL: http://jira.jboss.com/jira/browse/JBREM-857 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transporter Affects Versions: 1.4.6.GA Environment: solaris 10 and java 5 Reporter: craig bordelon Fix For: 2.2.2.GA_CP02 the jboss 1.4.1 transporterclient used by multithreaded program was giving strange results on a clustered server when failing over so i found lack of synchronization in the code. I made these changes and seems to be helping. changes to TransporterClient.java. I would like this fixed in the 2.x and 3.x versions (hello developers). I think i know how to fix the 2.x version of this code too as it has some new stuff but is likewise broken. (developers send me an email to bord(a)iscp.telcordia.com if you need it. thx Craig) @@ -93,11 +93,12 @@ /** * Disconnects the remoting client */ - private void disconnect() + private synchronized void disconnect() { if(remotingClient != null) { remotingClient.disconnect(); + remotingClient = null; } } @@ -232,14 +233,18 @@ do { + Client rcl = null; + synchronized(this) { rcl = remotingClient; } + if (rcl == null) throw new CannotConnectException("Client has been dis connected."); try { failOver = false; - response = remotingClient.invoke(request); + response = rcl.invoke(request); } catch(CannotConnectException cnc) { - failOver = findAlternativeTarget(); + failOver = findAlternativeTarget(rcl); + if (log.isDebugEnabled()) log.error("on CannotConnectException failO ver is "+failOver+" for "+rcl.getInvoker().getLocator()); if(!failOver) { throw cnc; @@ -264,7 +269,7 @@ * * @return */ - private boolean findAlternativeTarget() + private boolean findAlternativeTarget(Client rcl) { boolean failover = false; @@ -287,12 +292,19 @@ { // finally found server with target handler InvokerLocator newLocator = data.getInvokerLocator(); - if(!remotingClient.getInvoker().getLocator().equals(new Locator)) + if(!rcl.getInvoker().getLocator().equals(newLocator)) { try { - remotingClient = new Client(newLocator); - remotingClient.connect(); + synchronized(this) { + if (rcl == remotingClient) { + disconnect(); + remotingClient = new Client(newLocator); + } + //otherwise have to assume some other thread + //has meanwhile changed it + //including even disconnecting + } return true; } catch(Exception e) @@ -300,6 +312,8 @@ log.warn("Problem connecting to newly found alter nate target.", e); } } + else if (log.isDebugEnabled()) + log.error(rcl.getInvoker().getLocator()+" == "+newLoc ator); } } } @@ -333,4 +347,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

14 years, 6 months

3
3
0 / 0

[JBoss JIRA] Created: (JBREM-906) NoSuchObjectException on Server Restart Using RMI Transport & Unified Invoker

by John Reynolds (JIRA)

NoSuchObjectException on Server Restart Using RMI Transport & Unified Invoker ----------------------------------------------------------------------------- Key: JBREM-906 URL: http://jira.jboss.com/jira/browse/JBREM-906 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: unifiedinvoker Affects Versions: 2.2.2.GA Environment: Server Running Windows XP or Redhat - Swing Client on Windows XP Reporter: John Reynolds Using a Swing client to connect to the JBoss server, configured with RMI Transport Connector and Unified Invoker, I receive the following StackTrace when, after successfully connecting to the server and executing a few EJB transactions, I shut the server down and then bring it back up. Upon attempting to do any further invocations, it appears cached information is causing the client to fail. ------------- (rmi.RMIClientInvoker 272 ) java.rmi.NoSuchObjectException: no such object in table galaxy.framework.model.domain.services.util.SLCommunicationException: Error making invocation in RMI client invoker. at galaxy.framework.model.domain.services.util.ServiceLocator.authenticateUser(ServiceLocator.java:738) at galaxy.framework.model.domain.services.util.ServiceLocator.initializeWithLDAP(ServiceLocator.java:435) at galaxy.application.view.swing.presentation.util.ClientConnectionManager$1.run(ClientConnectionManager.java:51) Caused by: org.jboss.remoting.CannotConnectException: Error making invocation in RMI client invoker. at org.jboss.remoting.transport.rmi.RMIClientInvoker.transport(RMIClientInvoker.java:273) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122) at org.jboss.remoting.Client.invoke(Client.java:1550) at org.jboss.remoting.Client.invoke(Client.java:530) at org.jboss.invocation.unified.interfaces.UnifiedInvokerProxy.invoke(UnifiedInvokerProxy.java:183) at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70) at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100) at $Proxy1.authenticateSwingUserWithLDAP(Unknown Source) at galaxy.framework.model.domain.services.util.ServiceLocator.authenticateUser(ServiceLocator.java:725) ... 2 more Caused by: java.rmi.NoSuchObjectException: no such object in table at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126) at org.jboss.remoting.transport.rmi.RMIServerInvoker_Stub.transport(Unknown Source) at org.jboss.remoting.transport.rmi.RMIClientInvoker.transport(RMIClientInvoker.java:238) ... 14 more ------------ Seems potentially similar to this issue fixed in 4.0.5 in non-remoting-RMI code: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=116027 -- 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

14 years, 6 months

2
1
0 / 0

[JBoss JIRA] Created: (JBREM-802) TransporterHandler should not use Class.forName

by Julien Viet (JIRA)

TransporterHandler should not use Class.forName ----------------------------------------------- Key: JBREM-802 URL: http://jira.jboss.com/jira/browse/JBREM-802 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transporter Affects Versions: 2.2.1.GA, 2.2.0.SP4 Reporter: Julien Viet line: classSig[x] = Class.forName(sig[x]); should probably be replaced by classSig[x] = targetPOJO.getClass().getClassLoader().loadClass(sig[x]); to provide a correct class lookup -- 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

14 years, 6 months

4
4
0 / 0

[JBoss JIRA] Created: (JBREM-808) Remove dependencies on ObjectNameFactory from JBoss JMX

by Julien Viet (JIRA)

Remove dependencies on ObjectNameFactory from JBoss JMX ------------------------------------------------------- Key: JBREM-808 URL: http://jira.jboss.com/jira/browse/JBREM-808 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Julien Viet It happens when my POJO has not been bound on the transporter server, it looks like the transporter client is trying to do some fail over. This make JBoss Remoting depends on the JBoss JMX implementation. That makes JBoss Remoting more difficult to embed and reuse. I think that the ObjectNameFactory class could be easily ported to JBoss Remoting without any harm done. However perhaps JBoss Remoting has more dependencies on JBoss JMX that I don't know that would prevent to remove such dependency. [junit_] Exception in thread "main" java.lang.NoClassDefFoundError: org/jboss/mx/util/ObjectNameFactory [junit_] at org.jboss.remoting.transporter.InternalTransporterServices.<clinit>(InternalTransporterServices.java:41) [junit_] at org.jboss.remoting.transporter.TransporterClient.findAlternativeTarget(TransporterClient.java:330) [junit_] at org.jboss.remoting.transporter.TransporterClient.invoke(TransporterClient.java:301) [junit_] at $Proxy0.getInfo(Unknown Source) [junit_] at org.jboss.portal.test.framework.driver.remote.RemoteTestDriverClient.getInfo(RemoteTestDriverClient.java:107) -- 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

14 years, 6 months

3
3
0 / 0

[JBoss JIRA] Created: (JBREM-762) Deadlock bug in socket invoker

by Tim McCune (JIRA)

Deadlock bug in socket invoker ------------------------------ Key: JBREM-762 URL: http://jira.jboss.com/jira/browse/JBREM-762 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 1.4.6.GA Environment: JBoss 4.0.4 EJB 3.0-rc9-patch1 JDK 1.6.0 Reporter: Tim McCune There is a potential thread leak in ServerThread.java that causes ServerThreads to stick around, but to disappear from the thread pool as the accept() thread(s) see it. Eventually, when the # of leaked threads reaches the MaxPoolSize, the system ends up deadlocked and will not accept any more incoming socket connections. I have described the problem in great detail in a forum post and in support case 00016786. I have patched the code, and so far it seems to be working fine and to have fixed the problem. This is what I patched: In ServerThread.java, I wrapped the contents of wakeup() inside of a try/catch, block, with the following code in the catch block: } catch (Exception e) { synchronized (clientpool) { synchronized (threadpool) { clientpool.remove(this); threadpool.add(this); Thread.interrupted(); } } throw e; } This makes sure that the thread is put back into the threadpool when an exception occurs in the createServerSocket() method (this method is doing socket I/O in 1.4.6, and in our case, this socket connection was timing out.). -- 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

14 years, 6 months

2
1
0 / 0

[JBoss JIRA] Created: (JBREM-646) dynamic loading of new keystores during runtime is not possible when using Transporters (beaming POJOs)

by Claudia Richter (JIRA)

dynamic loading of new keystores during runtime is not possible when using Transporters (beaming POJOs) ------------------------------------------------------------------------------------------------------- Key: JBREM-646 URL: http://jira.jboss.com/jira/browse/JBREM-646 Project: JBoss Remoting Issue Type: Patch Security Level: Public (Everyone can see) Components: transporter Environment: ?? Reporter: Claudia Richter Assigned To: Tom Elrod when running a Transporter Server and a Transporter Client, using SSL connection, the Transporter Server does not recognise changes within its Truststore, if this is updated. Means, if the Client is not trusted when starting the Server, it will not be trusted for future request until the Server is restarted. It would be better to have a Server that is able to recognise Truststore changes. This feature is already implemented for other transports (no Transporters) as described in issue http://jira.jboss.com/jira/browse/JBREM-427. -- 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

14 years, 6 months

4
7
0 / 0

[JBoss JIRA] Created: (JBREM-652) allow passing of config map when creating transporter client

by Tom Elrod (JIRA)

allow passing of config map when creating transporter client ------------------------------------------------------------ Key: JBREM-652 URL: http://jira.jboss.com/jira/browse/JBREM-652 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: transporter Affects Versions: 2.2.0.Alpha4 Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.2.0.Beta1 (Bluto) Currently the transporter client can only be created using invoker locator for configuration. Need to add to the api so can pass config map which gets passed to the remoting client that is created so can customize things such as ssl config. For example, would be need to be able to something like is done in org.jboss.test.remoting.transport.socket.ssl.custom.InvokerClientTest with a transporter client. -- 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

14 years, 6 months

3
4
0 / 0

[JBoss JIRA] Created: (JBREM-738) ServerThread/invoker still executing invocation after its related TransportServer was stopped

by craig bordelon (JIRA)

ServerThread/invoker still executing invocation after its related TransportServer was stopped --------------------------------------------------------------------------------------------- Key: JBREM-738 URL: http://jira.jboss.com/jira/browse/JBREM-738 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transporter Affects Versions: 2.2.0.Beta1 (Bluto) Environment: java 1.5 on solaris but doubt its specific to this one. Reporter: craig bordelon Assigned To: Tom Elrod get an exception on the third iteration of a transporter client to a transporter server where the client code is doing the same invoke each time. This should not happen as the first two iterations give correct result. The exception is thrown from the server side as apparently the jboss remoting internals are confused -- stating that a ServerInvoker is not in "started state". Exception is java.lang.reflect.UndeclaredThrowableException at $Proxy4.toString(Unknown Source) at java.lang.String.valueOf(String.java:2615) at java.lang.StringBuilder.append(StringBuilder.java:116) at proxy.Client.testClientCall(Client.java:38) at proxy.Client.main(Client.java:115) Caused by: org.jboss.remoting.ServerInvoker$InvalidStateException: Can not proc ess invocation request since is not in started state. at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:751) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(S erverThread.java:568) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread. java:390) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.ja va:164) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClient Invoker.java:163) at org.jboss.remoting.Client.invoke(Client.java:1548) at org.jboss.remoting.Client.invoke(Client.java:534) at org.jboss.remoting.Client.invoke(Client.java:522) at org.jboss.remoting.transporter.TransporterClient.invoke(TransporterC lient.java:297) to reproduce this (one way at least): run the transporter sample modified for the Client to execute the the makeClientCall multiple times. Now to get past the obvious first issue (socket in use) add new code for customerProcessor.releaseCustomer(processedCustomer.getCustomerId() in the Client just before the TransporterClient.destroyTransporterClient(customerProcessor); Implement this method in the CustomerProcessorImpl to use the id to locate (eg hash get()) the related ICustomer TransporterClient and destroy it and to the TransporterServer to stop it. This theoretically frees up the Customer "server" allowing for the next iteration by the Client. note that the processCustomer() implemenation is modified to store the TransporterClient and TransporterServer that are created here. ------------ I dug into the code a bit and what i gathered is that a ServerThread is trying to do processInvocation using a SocketServerInvoker that was already "stopped". I think the ServerThread itself should not be executing as the TransporterServer it should be involved with was already stopped. I posted to the jboss forum on issues i was having trying to make the transporter sample run from the client multiple times. See issue by "bord" on 4/17/2007 -- 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

14 years, 6 months

3
3
0 / 0

[JBoss JIRA] Created: (JBREM-591) Make asynchronous calls using Transporter

by vivek v (JIRA)

Make asynchronous calls using Transporter ----------------------------------------- Key: JBREM-591 URL: http://jira.jboss.com/jira/browse/JBREM-591 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: transporter Reporter: vivek v Assigned To: Tom Elrod This came out of the user forum question, http://www.jboss.com/index.html?module=bb&op=viewtopic&t=89224 Currently, there is a mechanism to do asynchronous calls and callbacks using InvocationHandler. As more and more people are using POJOs (via Transporter) for remoting it would be great if we can have the same features (both asynchronous calls and callbacks) available for the Transporter. Couple of use cases can be, Asynchronous Call ----------------------------- 1) Client makes a simple method call (using POJO) on server 2) Server gets the request and returns immediately to the Client. Now Client is free to do its own stuff without waiting or polling for the result. 3) Server starts processing the request 4) When the response is ready Server sends the response to the Client. Callbacks -------------------- 1) An alert happens on the server side 2) Server should be able to send the alert to the Client without Client requesting for it. -- 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

14 years, 6 months

4
5
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 April 2010