[JBoss JIRA] Created: (JGRP-652) ReplicaetdHashMapTest fails
by Bela Ban (JIRA)
ReplicaetdHashMapTest fails
---------------------------
Key: JGRP-652
URL: http://jira.jboss.com/jira/browse/JGRP-652
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assigned To: Vladimir Blagojevic
Fix For: 2.7
[email from Robert Newson]
The ViewDeliveryDemo was testing a new feature, it was not the code I sent to Vlad or the code we discussed for the atlanta test. The ViewDeliveryDemo works fine for me once I suppress sending messages after block() as per your change.
The test I'm struggling with is the ReplicatedMapDemo which I gave to Vlad several days before writing the ViewDeliveryDemo, sorry for any confusion, but the atlanta lab were testing before I wrote the VDD, so I'm not sure how we got muddled.
I've reattached the demo in question.
Also, I can confirm that I've written a separate test to demonstrate the losslessness of MessageDispatcher with a zero timeout. It seems to work, though on occasion a VM will block indefinitely on the cast (even though the other boxes are still receiving replies from it), probably a coding error on my part, but fyi.
For clarity, the only test the Atlanta lab should run is ReplicatedMapDemo and with these arguments (5 N 50) where N is the total number of nodes. For more stress, increase the first and last parameter (the first is number of maps, the second the number of entries). All boxes should print "PASSED" within some reasonable number of retries (the retry number indicates how long it took for all the puts everywhere to arrive, it polls). It should be started on all boxes concurrently and needs to be run a number of times. I find that it seldom reaches "PASSED" on all boxes though, curiously can reach passed on some but not others (even though map.put() is synchronous)...
I have a workaround where I multiplex my own maps over a single, non-multiplexed channel, which works but is far from ideal.
--
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
16 years, 2 months
[JBoss JIRA] Created: (JBAS-5742) some date in <jta-data-source> cause the persistence unit to silently fail without any meanfull Exception
by spamolovko spamolovko (JIRA)
some date in <jta-data-source> cause the persistence unit to silently fail without any meanfull Exception
---------------------------------------------------------------------------------------------------------
Key: JBAS-5742
URL: http://jira.jboss.com/jira/browse/JBAS-5742
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-4.2.2.GA
Environment: Windows XP SP2, Sun JDK 1.5.0_15, Sun JRE 1.5.0_15, JBoss 4.2.2 GA.
Reporter: spamolovko spamolovko
Sometimes and usually when redeploy application that application can not locate persistent unit.
if have <jta-data-source>java:VeryLongNameWith22Characters</jta-data-source>, cause the persistence unit deployment to silently fail without any meanfull Exception.
The same with <jta-data-source>java:/VeryLongNameWith22Characters</jta-data-source>.
Also problem appear when application is redeploing. Can work before deploy, can not work after deploy.
Solve: restart full server, application and datasource should be placed before restart.
Real solve: use sorter names.
--
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
16 years, 2 months
[JBoss JIRA] Created: (JBAS-5736) Starting server with predeployed MDB POJO fails
by Dominik Pospisil (JIRA)
Starting server with predeployed MDB POJO fails
-----------------------------------------------
Key: JBAS-5736
URL: http://jira.jboss.com/jira/browse/JBAS-5736
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-5.0.0.CR1
Reporter: Dominik Pospisil
Attachments: mdbtest.tgz
Starting the server with predeployed JEE5 ear with MDP POJO fails. Deploying the application on running server works fine. Errors logged:
10:39:58,520 ERROR [ExceptionUtil] ConnectionFactoryEndpoint[jboss.messaging.connectionfactory:service=ConnectionFactory] createFailoverConnectionDelegate [p2-klj49eif-1-ip839eif-dlwwwk-100j3]
java.lang.RuntimeException: javax.naming.NameNotFoundException: securityManagement not bound
at org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore.authenticate(JBossASSecurityMetadataStore.java:199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy79.authenticate(Unknown Source)
at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint.createConnectionDelegateInternal(ServerConnectionFactoryEndpoint.java:225)
at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint.createConnectionDelegate(ServerConnectionFactoryEndpoint.java:165)
at org.jboss.jms.server.endpoint.advised.ConnectionFactoryAdvised.org$jboss$jms$server$endpoint$advised$ConnectionFactoryAdvised$createConnectionDelegate$aop(ConnectionFactoryAdvised.java:108)
at org.jboss.jms.server.endpoint.advised.ConnectionFactoryAdvised.createConnectionDelegate(ConnectionFactoryAdvised.java)
at org.jboss.jms.wireformat.ConnectionFactoryCreateConnectionDelegateRequest.serverInvoke(ConnectionFactoryCreateConnectionDelegateRequest.java:91)
at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:143)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:847)
at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:101)
at org.jboss.remoting.Client.invoke(Client.java:1685)
at org.jboss.remoting.Client.invoke(Client.java:589)
at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.org$jboss$jms$client$delegate$ClientConnectionFactoryDelegate$createConnectionDelegate$aop(ClientConnectionFactoryDelegate.java:167)
at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeTarget(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:81)
at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect_z_handleCreateConnectionDelegate_11112467.invoke(StateCreationAspect_z_handleCreateConnectionDelegate_11112467.java)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:205)
at org.jboss.jms.client.JBossConnectionFactory.createQueueConnection(JBossConnectionFactory.java:101)
at org.jboss.jms.client.JBossConnectionFactory.createQueueConnection(JBossConnectionFactory.java:95)
at org.jboss.resource.adapter.jms.inflow.dlq.AbstractDLQHandler.setupDLQConnection(AbstractDLQHandler.java:137)
at org.jboss.resource.adapter.jms.inflow.dlq.AbstractDLQHandler.setup(AbstractDLQHandler.java:83)
at org.jboss.resource.adapter.jms.inflow.dlq.JBossMQDLQHandler.setup(JBossMQDLQHandler.java:48)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.setupDLQ(JmsActivation.java:401)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.setup(JmsActivation.java:339)
at org.jboss.resource.adapter.jms.inflow.JmsActivation$SetupActivation.run(JmsActivation.java:692)
at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:204)
at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.naming.NameNotFoundException: securityManagement not bound
at org.jnp.server.NamingServer.getBinding(NamingServer.java:542)
at org.jnp.server.NamingServer.getBinding(NamingServer.java:550)
at org.jnp.server.NamingServer.getObject(NamingServer.java:556)
at org.jnp.server.NamingServer.lookup(NamingServer.java:296)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:669)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:629)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore.lookupSecurityManagement(JBossASSecurityMetadataStore.java:330)
at org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore.authenticate(JBossASSecurityMetadataStore.java:195)
... 42 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 2 months
[JBoss JIRA] Created: (JBAS-5715) -ds.xml not trimming whitespace in jboss5
by Adrian Brock (JIRA)
-ds.xml not trimming whitespace in jboss5
-----------------------------------------
Key: JBAS-5715
URL: http://jira.jboss.com/jira/browse/JBAS-5715
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JCA service
Affects Versions: JBossAS-5.0.0.CR1
Reporter: Adrian Brock
Assigned To: Jesper Pedersen
Fix For: JBossAS-5.0.0.CR2
See JBAS-5173
Here's an example where it is being used:
org.jboss.resource.metadata.mcf.ManagedConnectionFactoryDeploymentMetaData
/** The connectionDefinition */
@XmlElement(name="connection-definition")
@XmlJavaTypeAdapter(CollapsedStringAdapter.class) // HERE!
protected String connectionDefinition;
But this should be on every String.
--
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
16 years, 2 months
[JBoss JIRA] Created: (JBAS-5728) Upgrade jboss remoting to v2.2.2.SP8 (from v2.2.2.SP5)
by Ron Sigal (JIRA)
Upgrade jboss remoting to v2.2.2.SP8 (from v2.2.2.SP5)
------------------------------------------------------
Key: JBAS-5728
URL: http://jira.jboss.com/jira/browse/JBAS-5728
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Ron Sigal
EAP 4.2/4.3 are currently shipping with Remoting 2.2.2.SP7 and testing with 2.2.2.SP8 for the next CP releases. We could just update to 2.2.2.SP7, but I think JBREM-949 in 2.2.2.SP8 is important to JBossMessaging.
Many of the other bug reports arose in support cases: JBREM-962, JBREM-965, JBREM-981
Reported by Galder: JBREM-954, JBREM-960
Reported by Ovidiu: JBREM-972, JBREM-973
========================================================================================================
Release Notes - JBoss Remoting - Version 2.2.2.SP8 - Text format
Bug
* [JBREM-949] - CLONE [JBREM-947] - ConnectionValidator hangs when server dies
* [JBREM-954] - InterruptedException should not be rethrown as CannotConnectionException
* [JBREM-960] - Remoting configured with Servlet invoker can return misleading Exceptions when Servlet path is incorrect
* [JBREM-962] - Remote classloading does not work with Isolated EARs
* [JBREM-965] - Fix PortUtil.getRandomStartingPort()
* [JBREM-981] - CLONE [JBREM-980] - ServerInvokerServlet should retrieve ServletServerInvoker based on updated InvokerLocator
* [JBREM-1003] - Verify IPv6 addresses are handled correctly, part 2
Feature Request
* [JBREM-972] - CLONE [JBREM-971] - Enhance client-side connection error handling so certain (potentially revealing) socket-related exceptins are not discarded
* [JBREM-973] - CLONE [JBREM-970] - Enhance client-side error reporting so a misspelled truststore file name required by SSL can be easily spotted
Release
* [JBREM-948] - Release 2.2.2.SP8
Task
* [JBREM-950] - Assure version compatibility with earlier versions of Remoting
* [JBREM-995] - Apply unit test timing fixes
* [JBREM-1001] - Update Remoting Guide
* [JBREM-1002] - Allow ServerThread to keep running after SocketTImeoutException, part 2
* [JBREM-1004] - Run manual servlet unit tests
--
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
16 years, 2 months
[JBoss JIRA] Created: (JBCACHE-1357) Root nodes of marshalled regions won't be loaded correclty from cache loaders
by Galder Zamarreno (JIRA)
Root nodes of marshalled regions won't be loaded correclty from cache loaders
-----------------------------------------------------------------------------
Key: JBCACHE-1357
URL: http://jira.jboss.com/jira/browse/JBCACHE-1357
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.1.SP9
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Yesterday while looking at a support case, I discovered an awkward
behavior when it came to root region based marshalling nodes and
cache loaders.
Let's say you have a cache configured with a cache loader and have
a region marshaled called starting at /me. I have created an MBean
so that I can register/unregister classloader and activate/deactivate
the region upon deployment/undeployment of the classes I wanna
put under /me.
Now, let's say that I put a k,v in /me which will get stored in the cache
loader. If I know touch the deployment archive to force a redeployment
and check the contents of the cache, they're empty. If I try to get the k I
put under /me, it'll return nothing. Why?
Simple: The cache instance is configured to preload from root (/) but
when the region is activated, /me node is created. When the preloading
phase comes, a check is made to see whether the node needs to be
loaded:
private boolean mustLoad(DataNode n, Object key)
{
if (log.isTraceEnabled())
{
log.trace("mustLoad called with key=" + key + " and datanode=" + n);
}
return n == null ||
(n.containsKey(TreeCache.UNINITIALIZED) && (key == null || !n.containsKey(key)));
}
The problem is that nothing will be preloaded for at least the /me node,
because the node is not null, and it's not TreeCache.UNINITIALIZED. Any
child nodes under the region node do not have issues like this.
This is likely a bug: maybe when the region is activated, the node should
probably be created as TreeCache.UNINITIALIZED? I think this would work).
It's true that you could say that putting data at the root node of the region is
not a good idea regardless, but I think deep down this is a bug.
p.s. This is at least present in 1.4.x, need to check trunk.
Manik: I agree this is a bug. Could you raise a JIRA for this? Also agree with
your solution, that when a region is activated and if a node needs to be
created, it should be uninitialized.
If you create a unit test, could you add it to trunk as well?
--
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
16 years, 2 months