[JBoss JIRA] Created: (JGRP-425) Incorrect state transfer in high contention scenarios
by Bela Ban (JIRA)
Incorrect state transfer in high contention scenarios
-----------------------------------------------------
Key: JGRP-425
URL: http://jira.jboss.com/jira/browse/JGRP-425
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.5
State transfer (with digests) works as follows:
- State is requested from a provider
- Provider (1) gets the digest from NAKACK (below) and then (2) the application state from the channel (above)
- Between (1) and (2), some multicast message received can alter the state, as follows:
- Multicast message M is received
- At the same time, a state request is received
- To handle the state request, we ask NAKACK for the digest
- The digest contains M
- Now - before M is passed up - the digest is returned to STATE_TRANSFER and we fetch the state
*WITHOUT* M ! When the state requester gets the state&digest, it will reject a resent M because it thinks
it is in its state (because it is in its digest), however M is not part of the state !
Other issue:
- M is received after the digest has been retrieved by STATE_TRANSFER, but then M passes the state transfer and is received by the channel and applied to the state *before* the state request can fetch the state. Now M is *not* part of the digest, but it *is* part of the state !
SOLUTION:
- When getting the digest, set a flag (in NAKACK) such that all subsequent multicast up-messages are blocked (or add them into a bounded FIFO list)
- Fetch the state from the channel (the application)
- Unblock NAKACK (send down an UNBLOCK event)
- Return the state&digest to the state requester
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 4 months
[JBoss JIRA] Created: (JBAS-3884) Unexpected end of ZLIB input stream for nested JAR files
by Michael Newcomb (JIRA)
Unexpected end of ZLIB input stream for nested JAR files
--------------------------------------------------------
Key: JBAS-3884
URL: http://jira.jboss.com/jira/browse/JBAS-3884
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-5.0.0.Beta1
Environment: Java 5
Reporter: Michael Newcomb
1. Built EJB3 trailblazer.
2. Copied EJB3Trail.ear file to deploy directory.
3. **** started JBoss **** (JBoss was not running when copy occurred)
During the deploy process I kept getting this error. It is similar to when you try to build a war/ear/jar INSIDE the deploy directory. The file is not completly written when it is being deployed.
Well, I copied the file before I started JBoss but was still getting this error.
So, I exploded the ear file and just had EJB3Trail.ear as a directory. Everything works fine.
So, it seems like the files inside the EAR are being processed *before* they are completely unjarred? Perhaps the streams writing the nested jars are not being closed?
Thanks,
Michael
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 4 months
[JBoss JIRA] Created: (JBAS-3867) "java.io.IOException: Read error" when deploying jmx-console on windows
by Ryan Campbell (JIRA)
"java.io.IOException: Read error" when deploying jmx-console on windows
-----------------------------------------------------------------------
Key: JBAS-3867
URL: http://jira.jboss.com/jira/browse/JBAS-3867
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployment services, XML services
Affects Versions: JBossAS-5.0.0.Beta1
Environment: windows xp, sun jdk 1.5.0_06
Reporter: Ryan Campbell
Assigned To: Dimitris Andreadis
15:24:19,734 INFO [TomcatDeployment] deploy, ctxPath=/jmx-console, warUrl=.../deploy/jmx-console.war/
15:24:19,828 ERROR [BaseModelMBean] Exception invoking method addChild
java.lang.RuntimeException: org.jboss.xb.binding.JBossXBException: Failed to parse source: Read error
at org.jboss.web.tomcat.tc6.TomcatInjectionContainer.processMetadata(TomcatInjectionContainer.java:264)
at org.jboss.web.tomcat.tc6.WebAppLoader.start(WebAppLoader.java:104)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4198)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
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:585)
at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:297)
at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.apache.catalina.core.StandardContext.init(StandardContext.java:5285)
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:585)
at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:297)
at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.jboss.web.tomcat.tc6.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:299)
at org.jboss.web.tomcat.tc6.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:126)
at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:355)
at org.jboss.web.deployers.WebModule.startModule(WebModule.java:88)
at org.jboss.web.deployers.WebModule.start(WebModule.java:66)
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:585)
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.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:184)
at $Proxy0.start(Unknown Source)
at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
at org.jboss.system.microcontainer.ServiceControllerContextAction.install(ServiceControllerContextAction.java:46)
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:226)
at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:198)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:709)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:429)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:538)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:472)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:320)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:190)
at org.jboss.system.ServiceController.doChange(ServiceController.java:656)
at org.jboss.system.ServiceController.start(ServiceController.java:431)
at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:124)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:85)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:44)
at org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleRealDeployer.deploy(AbstractSimpleRealDeployer.java:53)
at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.commitDeploy(AbstractSimpleDeployer.java:52)
at org.jboss.deployers.plugins.deployer.DeployerWrapper.commitDeploy(DeployerWrapper.java:145)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:440)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:381)
at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:366)
at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:246)
at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:401)
at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:340)
at org.jboss.Main.boot(Main.java:210)
at org.jboss.Main$1.run(Main.java:508)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: Read error
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:178)
at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:169)
at org.jboss.web.metamodel.descriptor.WebDDObjectFactory.parse(WebDDObjectFactory.java:86)
at org.jboss.web.tomcat.tc6.TomcatInjectionContainer.processMetadata(TomcatInjectionContainer.java:256)
... 65 more
Caused by: java.io.IOException: Read error
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:194)
at org.apache.xerces.impl.XMLEntityManager$RewindableInputStream.read(Unknown Source)
at org.apache.xerces.impl.io.UTF8Reader.read(Unknown Source)
at org.apache.xerces.impl.XMLEntityScanner.load(Unknown Source)
at org.apache.xerces.impl.XMLEntityScanner.skipSpaces(Unknown Source)
at org.apache.xerces.impl.XMLDocumentScannerImpl$TrailingMiscDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:174)
... 68 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 4 months
[JBoss JIRA] Created: (EJBTHREE-736) Duplicating _$$_javassist_ classes after remote - call - OutOfMemory: PermGen
by Piotr Tabor (JIRA)
Duplicating _$$_javassist_ classes after remote - call - OutOfMemory: PermGen
-----------------------------------------------------------------------------
Key: EJBTHREE-736
URL: http://jira.jboss.com/jira/browse/EJBTHREE-736
Project: EJB 3.0
Issue Type: Bug
Components: Documentation
Affects Versions: EJB 3.0 RC9 - FD
Environment: Linux Gentoo 2.6.18, JVM 1.5.0.08, 1.5.0.09, amd64
RedHat Linux EE 4.0. JVM 1.5.0.09, intel
Reporter: Piotr Tabor
I got the same problem...
PermGen in EJB3 client aplication by remote interface.
The application is as sample as it can be:
-get remote interface of stateless EJB3 (by JNDI)
- ask 1000 times to get a Collection of 10 EntityBeans.
After 255 there is OutOfMemory: PermGen.
JVM options changes nothing (eventualy more PermSpace => longer run).
The reason looks like the Javassist create lazyinitializer classes for every EntityBean retrived from the server.
So: When I debug on server-side, I got before sending Entity to client:
I got:
myEntity[0].id=143534
myEntity[0].flow=<FlowEntity_$$_javassist_7> 13434
...
myEntity[0].user=<UserEntity_$$_javassist_15>...
myEntity[0].stage=<StageEntity_$$_javassist_17>...
And every remote call the class names (name)_$..._javassist_(index) got the same
indexes (7,15,17) on server side (end every entity in returned collections of entities)
But when I debug on client site - after return from remote call - the indexes of
all returned entities are different (Each next increments index).
So after first call I got:
myEntity[0].id=143534
myEntity[0].flow=<FlowEntity_$$_javassist_0>...
...
myEntity[0].user=<UserEntity_$$_javassist_1>...
myEntity[0].stage=<StageEntity_$$_javassist_2>...
...
myEntity[1].id=143534
myEntity[1].flow=<FlowEntity_$$_javassist_3>
...
myEntity[1].user=<UserEntity_$$_javassist_4>...
myEntity[1].stage=<StageEntity_$$_javassist_5>...
...
After secund call:
myEntity[0].id=143534
myEntity[0].flow=<FlowEntity_$$_javassist_6>...
...
myEntity[0].user=<UserEntity_$$_javassist_7>...
myEntity[0].stage=<StageEntity_$$_javassist_8>...
...
myEntity[1].id=143534
myEntity[1].flow=<FlowEntity_$$_javassist_9>
...
myEntity[1].user=<UserEntity_$$_javassist_10>...
myEntity[1].stage=<StageEntity_$$_javassist_11>...
...
And so on... ... and permGen after 260 iterations...
I have not idea, how to deal with that...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 4 months
[JBoss JIRA] Created: (JBCACHE-961) Optimistic locking to support more sophisticated merging of child maps
by Manik Surtani (JIRA)
Optimistic locking to support more sophisticated merging of child maps
----------------------------------------------------------------------
Key: JBCACHE-961
URL: http://jira.jboss.com/jira/browse/JBCACHE-961
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 1.4.1.GA
Reporter: Manik Surtani
Assigned To: Manik Surtani
Fix For: 2.0.0.BETA2, 2.0.0.GA
At the moment at commit time parent nodes in a workspace have their child maps used to overwrite the underlying data nodes. As such, version increments are necessary on the parents, very bad for concurrency.
A more sophisticated merging mechanism is needed here, perhaps along the lines of:
1) Children added placed in an addedChildren map
2) Children removed placed in a childrenRemoved map
at commit time, use these 2 maps to look at what exists in the underlying node and merge in accordingly.
Related to JBCACHE-955 and JBCACHE-956.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 4 months
[JBoss JIRA] Created: (JGRP-344) Ignore bind address for (receive) sockets
by Bela Ban (JIRA)
Ignore bind address for (receive) sockets
-----------------------------------------
Key: JGRP-344
URL: http://jira.jboss.com/jira/browse/JGRP-344
Project: JGroups
Issue Type: Task
Affects Versions: 2.4
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.5
For multicast sockets, bind address defines the NIC which will be used to receive and send IP multicast packets. For unicast sockets (e.g. ServerSocket), this is an unnecessary restriction and bind address should be ignored. For example, if we define bind_addr=1.2.3.4, then we will be able to only receive packets on 1.2.3.4, but not 5.6.7.8 etc.
However, currently bind_addr is used to define the *identity* of a member, so we still need to use it (although not set it in a socket). This will be easier once we have logical addresses.
Email by Satya:
Hi,
I have found an issue which is to be fixed in 2.5. I
want to know if my issue is realted to this issue.
The description is as follows:
If -Dbind.address or bind_addr are not set, JGroups
picks the NIC to bind sockets to itself. However,
especially for ServerSockets, this may not be
desirable because we may want to have ServerSockets be
able to receive packets through all interfaces, e.g.
- NICs are 192.168.5.2, 192.168.0.2 and 127.0.0.1
(loopback)
- When the bind address is set to 192.168.5.2, a given
ServerSocket on port 7500 will *only accept packets
from this NIC*
- If someone connects to 192.168.0.2:7500 or
127.0.0.1:7500, the client will not be able to
establish a connection because nobody is listening on
those ports on the given NICs
- If bind address was not set, this would be possible
- Affected: FD_SOCK, FD_PING, TCP, TCP_NIO etc
- We need to think about semantics for
MulticastSockets where a wildcard address (not setting
the bind address) means that the operating system
picks the NIC, and *not* that the MulticastSocket will
listen on all interfaces for incoming packets
Regards,
Satya.
--- satya narayana <satya_461(a)yahoo.com> wrote:
> > Hi Bela,
> >
> > It worked for me as long as I was stopping the NIC's
> > which GMS address doesn't correspond.
> >
> > When I stopped the NIC which has the GMS Address
> > specified by the member, I see them not
> > communicating.
> >
> > If u have tried this and working for you , can you
> > tell me the properties and options which u have
> > specified to your demo ?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 4 months