March 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBDEPLOY-11) Test that the correct classpath was obtained by StructureBuilder

by Ales Justin (JIRA)

Test that the correct classpath was obtained by StructureBuilder ---------------------------------------------------------------- Key: JBDEPLOY-11 URL: http://jira.jboss.com/jira/browse/JBDEPLOY-11 Project: JBoss Deployers Issue Type: Sub-task Components: tests Affects Versions: JBDEPLOY-2.0.0.Beta11 Reporter: Ales Justin Assigned To: Ales Justin Fix For: JBDEPLOY-2.0.0.CR1 VFSStructureBuilderTest - needs proper testing that the correct classpath was obtained. -- 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

18 years, 3 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-844) Put instance variable "isRemotingUserAgent" on stack in CoyoteInvoker

by Ron Sigal (JIRA)

Put instance variable "isRemotingUserAgent" on stack in CoyoteInvoker --------------------------------------------------------------------- Key: JBREM-844 URL: http://jira.jboss.com/jira/browse/JBREM-844 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP2, 2.2.2.GA_CP01, 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) In org.jboss.remoting.transport.CoyoteInvoker, the variable "isRemotingUserAgent" is declared as an instance variable, which creates a race condition among multiple 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

18 years, 3 months

1
6
0 / 0

[JBoss JIRA] Created: (JBREM-826) JBoss Remoting logs at ERROR and WARN in many places

by Tim Fox (JIRA)

JBoss Remoting logs at ERROR and WARN in many places ---------------------------------------------------- Key: JBREM-826 URL: http://jira.jboss.com/jira/browse/JBREM-826 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Tim Fox Fix For: 2.4.0.Beta1 (Pinto) In many places JBoss Remoting logs at ERROR or WARN which seem inappropriate. JBR is a toolkit and should not log errors it does not handle. If every toolkit being used in the chain logged the same error then you end up with a complete mess in the logs every time an exeception occurs. There is a general principle of you shouldn't log unless you handle the error. If you just pass it up, don't log. This principle is adhered to in JBoss AS for example, and IMHO should be used throughout all JBoss projectsd Failover in JBoss Messaging is a good example. In JBM we detect failure of the remoting connection via the connection listener, and transparently reconnect on a different node. In this case, from the users POV *no error* has occurred - the process should be completely seamless. However JBoss Remoting spews a load of exceptions to the logs at ERROR and WARN, for example: @main 08:01:30,648 INFO [ServerManagement] Waiting for server to die @main 08:01:30,953 INFO [ServerManagement] server 1 killed and dead @Timer-3 08:01:31,253 ERROR [SocketClientInvoker] Got marshalling exception, exiting java.net.SocketException: end of file at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:577) at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:413) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122) at org.jboss.remoting.ConnectionValidator.doCheckConnection(ConnectionValidator.java:133) at org.jboss.remoting.ConnectionValidator.run(ConnectionValidator.java:308) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) @Thread-9 08:01:31,277 WARN [ClientClusteredConnectionFactoryDelegate] org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection for InvokerLocator [bisocket://localhost:2117/?clientLeasePeriod=10000&clientMaxPoolSize=200&clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper&dataType=jms&marshaller=org.jboss.jms.wireformat.JMSWireFormat&numberOfCallRetries=1&numberOfRetries=10&pingFrequency=214748364&pingWindowFactor=10&socket.check_connection=false&timeout=0&unmarshaller=org.jboss.jms.wireformat.JMSWireFormat] org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection for InvokerLocator [bisocket://localhost:2117/?clientLeasePeriod=10000&clientMaxPoolSize=200&clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper&dataType=jms&marshaller=org.jboss.jms.wireformat.JMSWireFormat&numberOfCallRetries=1&numberOfRetries=10&pingFrequency=214748364&pingWindowFactor=10&socket.check_connection=false&timeout=0&unmarshaller=org.jboss.jms.wireformat.JMSWireFormat] at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:532) at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:413) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122) at org.jboss.remoting.Client.invoke(Client.java:1634) at org.jboss.remoting.Client.invoke(Client.java:548) at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.removeCallback(ClientClusteredConnectionFactoryDelegate.java:152) at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.closeCallback(ClientClusteredConnectionFactoryDelegate.java:168) at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.establishCallback(ClientClusteredConnectionFactoryDelegate.java:93) at org.jboss.jms.client.remoting.ConnectionFactoryCallbackHandler$CallbackConnectionListener.handleConnectionException(ConnectionFactoryCallbackHandler.java:105) at org.jboss.remoting.ConnectionValidator$1.run(ConnectionValidator.java:452) Caused by: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at java.net.Socket.connect(Socket.java:519) at org.jboss.remoting.transport.socket.SocketClientInvoker.createSocket(SocketClientInvoker.java:187) at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.createSocket(BisocketClientInvoker.java:420) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.getConnection(MicroSocketClientInvoker.java:815) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:525) ... 9 more @Thread-9 08:01:31,299 WARN [Client] unable to remove remote callback handler: Can not get connection to server. Problem establishing socket connection for InvokerLocator [bisocket://localhost:2117/?clientLeasePeriod=10000&clientMaxPoolSize=200&clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper&dataType=jms&marshaller=org.jboss.jms.wireformat.JMSWireFormat&numberOfCallRetries=1&numberOfRetries=10&pingFrequency=214748364&pingWindowFactor=10&socket.check_connection=false&timeout=0&unmarshaller=org.jboss.jms.wireformat.JMSWireFormat] SERVER 0 STDOUT: @Timer-4 08:01:31,301 ERROR [SocketClientInvoker] Got marshalling exception, exiting SERVER 0 STDOUT: java.net.SocketException: end of file SERVER 0 STDOUT: at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:577) SERVER 0 STDOUT: at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:413) SERVER 0 STDOUT: at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122) @Thread-9 08:01:31,320 WARN [LeasePinger] LeasePinger[SocketClientInvoker[c0f1ec, bisocket://localhost:2117](3j001-bj8ucn-f8e4sbxc-1-f8e4sby7-3)] failed sending disconnect for client lease for client with session ID 3j001-bj8ucn-f8e4sbxc-1-f8e4sbxd-2 SERVER 0 STDOUT: at org.jboss.remoting.ConnectionValidator.doCheckConnection(ConnectionValidator.java:133) SERVER 0 STDOUT: at org.jboss.remoting.ConnectionValidator.run(ConnectionValidator.java:308) SERVER 0 STDOUT: at java.util.TimerThread.mainLoop(Timer.java:512) SERVER 0 STDOUT: at java.util.TimerThread.run(Timer.java:462) @Thread-9 08:01:31,345 WARN [LeasePinger] LeasePinger[SocketClientInvoker[c0f1ec, bisocket://localhost:2117](3j001-bj8ucn-f8e4sbxc-1-f8e4sby7-3)] failed to ping to server: Can not get connection to server. Problem establishing socket connection for InvokerLocator [bisocket://localhost:2117/?cli This completely messes up the logs and the customer believes something has gone wrong, phones support and they waste a lot of time trying to work out what the problem is, when actually there is no problem and this is perfectly successful failover from one node to another, but to the customer they have a flawed experience. If anything is to be logged in these cases it should be at DEBUG level at the highest, so it can be easily supressed in the standard log4j config. In the mean-time if you could provide a log4j config which supresses these messages for the specific classes so they don't appear even on ERROR level that would be much appreciated. -- 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

18 years, 3 months

2
5
0 / 0

[JBoss JIRA] Updated: (JBREM-167) RMI Invoker does not use true remoting marshalling/unmarshalling

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-167?page=all ] Ron Sigal updated JBREM-167: ---------------------------- JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=131485&start=0 Opened thread "Question about Remoting, Marshalling, and EJBs" (http://www.jboss.com/index.html?module=bb&op=viewtopic&t=131485&start=0) in the "Design of the JBoss EJB Container" to solicit opinions about this issue. In general, the response was that there was no particular demand for the feature, but it was probably not harmful. > RMI Invoker does not use true remoting marshalling/unmarshalling > ---------------------------------------------------------------- > > Key: JBREM-167 > URL: http://jira.jboss.com/jira/browse/JBREM-167 > Project: JBoss Remoting > Issue Type: Bug > Components: transport > Affects Versions: 1.2.0 final > Reporter: Tom Elrod > Assigned To: Ron Sigal > Priority: Minor > Fix For: 2.4.0.CR1 (Pinto) > > > In process of fixing JBREM-165 (RMI support for UnifiedInvoker), have added ability to call on mashaller when making request so that can modify payload before sending. Although the RMIInvokerClient does use the configured marshaller, it does not use the configured unmarshaller (RMIInvokerServer is the opposite). This was done to get JBREM-165 working, but is not a total solution and needs to be fixed so anyone can add a marshaller/unmarshaller for RMI invoker that will be called both ways (in and out) on both the client and server. -- 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

18 years, 3 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBREM-167) RMI Invoker does not use true remoting marshalling/unmarshalling

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-167?page=comments#action_12402625 ] Ron Sigal commented on JBREM-167: --------------------------------- 1. org.jboss.remoting.transport.rmi.RMIClientInvoker and RMIServerInvoker now have the ability to marshal and unmarshal in the server to client direction as well as the client to server direction. 2. Marshalling in the client to server direction has been changed so that once an object has been marshalled into a ByteArrayOutputStream, it is not reread from an ObjectInputStream. Instead, the byte array is passed directly to the proxy's transport() method. 3. Just in case, the original version of marshalling/unmarshalling is available by setting the new parameter RMIServerInvoker.RMI_ONEWAY_MARSHALLING (actual value "rmiOnewayMarshalling") to "true". In fact, the original version has been fixed so that it works with JBossSerialization. Unit tests: org.jboss.test.remoting.transport.rmi.RMIInvokerTestCase has been split into * org.jboss.test.remoting.transport.rmi.RMIInvokerNativeMarshallerTestCase and * org.jboss.test.remoting.transport.rmi.RMIInvokerOnewayMarshallingTestCase Also, two new tests have been added: * org.jboss.test.remoting.transport.rmi.RMIInvokerDecoratorTestCase and * org.jboss.test.remoting.transport.rmi.RMIInvokerOnewayMarshallingTestCase Waiting for hudson results. > RMI Invoker does not use true remoting marshalling/unmarshalling > ---------------------------------------------------------------- > > Key: JBREM-167 > URL: http://jira.jboss.com/jira/browse/JBREM-167 > Project: JBoss Remoting > Issue Type: Bug > Components: transport > Affects Versions: 1.2.0 final > Reporter: Tom Elrod > Assigned To: Ron Sigal > Priority: Minor > Fix For: 2.4.0.CR1 (Pinto) > > > In process of fixing JBREM-165 (RMI support for UnifiedInvoker), have added ability to call on mashaller when making request so that can modify payload before sending. Although the RMIInvokerClient does use the configured marshaller, it does not use the configured unmarshaller (RMIInvokerServer is the opposite). This was done to get JBREM-165 working, but is not a total solution and needs to be fixed so anyone can add a marshaller/unmarshaller for RMI invoker that will be called both ways (in and out) on both the client and server. -- 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

18 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-1436) Filescanner throws NPE when there's a compile error.

by Alex McCarrier (JIRA)

Filescanner throws NPE when there's a compile error. ---------------------------------------------------- Key: JBRULES-1436 URL: http://jira.jboss.com/jira/browse/JBRULES-1436 Project: JBoss Drools Issue Type: Bug Components: Drl Parser/Builder Affects Versions: 4.0.4 Environment: os x, drools 4.0.4 Reporter: Alex McCarrier Priority: Minor Loading a .drl file via the FileScanner, if there is a compile error in the file the FileScanner throws an NPE rather than throwing the compile exception. I had to download the source and examine the exception by setting a breakpoint to figure out what was going on. This is in: org.drools.agent.FileScanner:98-101 -- 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

18 years, 3 months

3
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1428) ClassCastException when comparing BigDecimal fields

by Alexandre Gattiker (JIRA)

ClassCastException when comparing BigDecimal fields --------------------------------------------------- Key: JBRULES-1428 URL: http://jira.jboss.com/jira/browse/JBRULES-1428 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.4 Reporter: Alexandre Gattiker Works on Drools 4.0.2 but not on Drools 4.0.4. java.lang.ClassCastException: java.lang.Long at org.drools.base.evaluators.BigDecimalFactory$BigDecimalGreaterEvaluator.evaluate(BigDecimalFactory.java:318) at org.drools.rule.LiteralRestriction.isAllowed(LiteralRestriction.java:61) at org.drools.rule.LiteralConstraint.isAllowed(LiteralConstraint.java:82) at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:132) at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:22) at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:153) at org.drools.reteoo.Rete.assertObject(Rete.java:175) at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:192) at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:71) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:909) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:881) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:682) at com.sample.DroolsTest.main(DroolsTest.java:27) package com.sample import com.sample.DroolsTest.Message; rule "rule1" when Message(value > 0) then end public class DroolsTest { public static final void main(String[] args) { try { RuleBase ruleBase = readRule(); Message a = new Message(); a.setValue(new BigDecimal(0)); WorkingMemory workingMemory = ruleBase.newStatefulSession(); workingMemory.insert(a); workingMemory.fireAllRules(); } catch (Throwable t) { t.printStackTrace(); } } private static RuleBase readRule() throws Exception { Reader source = new InputStreamReader(DroolsTest.class.getResourceAsStream("/Sample.drl")); PackageBuilder builder = new PackageBuilder(); builder.addPackageFromDrl(source); Package pkg = builder.getPackage(); RuleBase ruleBase = RuleBaseFactory.newRuleBase(); ruleBase.addPackage(pkg); return ruleBase; } public static class Message { private BigDecimal value; public BigDecimal getValue() { return this.value; } public void setValue(BigDecimal value) { this.value = value; } } } -- 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

18 years, 3 months

4
6
0 / 0

[JBoss JIRA] Created: (JBAOP-499) Deadlock on multi-threaded dynamic AOP scenarios

by Flavia Rainone (JIRA)

Deadlock on multi-threaded dynamic AOP scenarios ------------------------------------------------ Key: JBAOP-499 URL: http://jira.jboss.com/jira/browse/JBAOP-499 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.CR2 Reporter: Flavia Rainone Fix For: 2.0.0.GA The main scenario of the dealock happens when a thread executes an AOP weaved code while another thread needs to load a class, when using loadtime weaving. -- 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

18 years, 3 months

2
12
0 / 0

[JBoss JIRA] Created: (JBAOP-501) Deadlock involving exclusively AspectManager and ClassLoader locks

by Flavia Rainone (JIRA)

Deadlock involving exclusively AspectManager and ClassLoader locks ------------------------------------------------------------------ Key: JBAOP-501 URL: http://jira.jboss.com/jira/browse/JBAOP-501 Project: JBoss AOP Issue Type: Sub-task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.CR2 Reporter: Flavia Rainone Fix For: 2.0.0.GA This deadlock involves only the AspectManager and the class loader locks. The scenario, result of a rebuildingchain test execution, follows: -Thread 0 (org.jboss.test.aop.rebuldingchain.SyncThread) When this thread calls the joinpoint SyncThread.checkStatus, its wrapper is executed. This wrapper needs to generate the Joinpoint class to perform the interception and, for that, it has to acquire the read lock for InterceptorChain. This thread starts waiting for Thread1 to release the interceptor chain write lock. - Thread 1 (org.jboss.test.aop.rebuildingchain.RebuildThread) This thread adds a binding to AspectManager. As part of the addBinding method execution, the AspectManager lock is acquired. As soon as the binding is addded to the bindings collection, the affected advisors have to rebuild their interceptor chains. SyncThread advisor is the affected advisor in this scenario and, to rebuild chains, it needs the write lock for the SyncThread.checkStatus inteceptor chain. This lock is acquired and the rebuild chain algorithm starts being executed. During the finalization of fhe chains, interceptors are created. For that, the interceptor class needs to be loaded, so this thread starts waiting for the class loader lock, held by Main Thread. - Main Thread Test tries to finish execution (without joining the other threads) and, for that, it starts loading a class, acquiring the class loader lock. The class loading proccess triggers AOPTransformer, that tries to transform the loaded class. For that, the AspectManager lock, held by Thread1, is required, so thist thread starts waiting for that lock. Notice that the deadlock involves only Thread1 and MainThread (Thread0 is present only for completion). -- 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

18 years, 3 months

2
12
0 / 0

[JBoss JIRA] Created: (JBRULES-1485) Fixes to the documentation

by Bruce Mitchener (JIRA)

Fixes to the documentation -------------------------- Key: JBRULES-1485 URL: http://jira.jboss.com/jira/browse/JBRULES-1485 Project: JBoss Drools Issue Type: Patch Security Level: Public (Everyone can see) Components: Documentation Reporter: Bruce Mitchener Assigned To: Mark Proctor Attachments: docs.diff This fixes various typos in the documentation as well as treating some words like proper nouns (by capitalizing them) and changing 'plug in' to 'plug-in'. -- 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

18 years, 3 months

3
4
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 March 2008