[JBoss JIRA] Created: (JGRP-357) Unicast messages to unused port result in infinitely retransmission of message
by Vincent Hartsteen (JIRA)
Unicast messages to unused port result in infinitely retransmission of message
------------------------------------------------------------------------------
Key: JGRP-357
URL: http://jira.jboss.com/jira/browse/JGRP-357
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Reporter: Vincent Hartsteen
Assigned To: Bela Ban
In JGroups 2.4 (but probably this also happens in previous versions, did not verify this) we noticed that it is possible to send a message to a host:port that is not part of the group. This member might have been a member of the group but does not need to have been. This results in the retransmission of the message. However this retransmission never seems to end. The attached program demonstrates this.
Use the properties file to assign a host-address and port the program will send messages to.
Properties file:
===========
flood.target.address : 10.220.242.33
flood.target.port : 2715
flood.topic : flood.the.network
flood.stack : UDP(mcast_addr=228.1.2.123;mcast_port=19302;ip_ttl=32;loopback=false;\
mcast_recv_buf_size=1000000;max_bundle_size=64000;max_bundle_timeout=100;use_incoming_packet_handler=false;\
use_outgoing_packet_handler=true;ucast_send_buf_size=1000000;ip_ttl=32;enable_bundling=true/):\
PING(timeout=6000;num_initial_members=8;down_thread=false):\
MERGE2(max_interval=300000;min_interval=60000;down_thread=false):\
FD(timeout=30000;max_tries=5;shun=true):\
pbcast.NAKACK(gc_lag=300;retransmit_timeout=3000,30000,60000,180000;use_mcast_xmit=false;max_xmit_size=8192):\
UNICAST(timeout=3000,30000,60000,180000):\
pbcast.STABLE(desired_avg_gossip=300000;stability_delay=30000;max_bytes=65536;down_thread=false):\
pbcast.GMS(join_timeout=10000;join_retry_timeout=5000;shun=true;print_local_addr=true;down_thread=false):\
FC(max_credits=64000;min_credits=8000;down_thread=false):\
FRAG2(frag_size=8000;down_thread=false;up_thread=false):\
COMPRESS(down_thread=false;min_size=256;compression_level=9;up_thread=true):\
pbcast.STATE_TRANSFER(down_thread=false;up_thread=false)
Program:
=======
public class Flooder implements MembershipListener, RequestHandler, RspCollector {
private static Log log = LogFactory.getLog(Flooder.class);
private static int counter = 0;
private Channel channel = null;
private MessageDispatcher dispatcher = null;
private Timer floodTimer = null;
private InetAddress targetAddr;
private int targetPort;
private String topic;
private String stack;
public Flooder() throws IOException, ChannelException {
Properties properties = new Properties();
InputStream in = ClassLoader.getSystemClassLoader().getResourceAsStream("flooder.properties");
properties.load(in);
in.close();
targetAddr = InetAddress.getByName(properties.getProperty("flood.target.address").trim());
targetPort = Integer.parseInt(properties.getProperty("flood.target.port"));
topic = properties.getProperty("flood.topic");
stack = properties.getProperty("flood.stack");
initialize();
}
public void initialize() throws ChannelException {
channel = new JChannel(stack);
channel.setOpt(Channel.BLOCK, Boolean.TRUE);
channel.setOpt(Channel.GET_STATE_EVENTS, Boolean.TRUE);
channel.setOpt(Channel.AUTO_RECONNECT, Boolean.TRUE);
channel.setOpt(Channel.AUTO_GETSTATE, Boolean.TRUE);
channel.connect(topic);
dispatcher = new MessageDispatcher(channel, null, this, this);
log.trace("Connected to topic " + topic + " w/ stack: " + ((JChannel)channel).getProtocolStack().printProtocolSpec(true));
}
public void startFlooding() {
if (floodTimer != null) floodTimer.cancel();
floodTimer = new Timer();
floodTimer.schedule(new TimerTask() {
@Override
public void run() {
Address address = new IpAddress(targetAddr, targetPort);
Message msg = new Message(address, null, ("Flooooooooood#" + ++counter + "#").getBytes());
Vector<Address> victor = new Vector<Address>(1);
victor.add(address);
dispatcher.castMessage(victor, System.currentTimeMillis(), msg, Flooder.this);
log.trace("Sent Flooding message #" + counter + " to " + address + " @ " + new Date());
}
}, 1000, 10000);
}
public void block() {
log.trace("BLOCK");
}
public void suspect(Address addr) {
log.trace("SUSPECT: " + addr);
}
public void viewAccepted(View v) {
log.trace("VIEW ACCEPTED: " + v);
}
public Object handle(Message msg) {
log.trace("MESSAGE RECEIVED: " + msg);
return "HANDLED";
}
public void receiveResponse(Message m) {
log.trace("RECEIVE RESPONSE: " + m + " hdr=" + m.getHeaders());
}
public void viewChange(View v) {
log.trace("VIEW CHANGE: " + v);
}
public static void main(String[] args) {
try {
Flooder flooder = new Flooder();
flooder.startFlooding();
} catch (Exception ex) {
log.error("Exception occurred: ", ex);
}
}
}
--
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-3923) CMP mixing database columns on high load
by Marius Kotsbak (JIRA)
CMP mixing database columns on high load
----------------------------------------
Key: JBAS-3923
URL: http://jira.jboss.com/jira/browse/JBAS-3923
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-4.0.4.GA
Environment: -Debian Linux sarge (stable)
-Postgresql 8.1.4
-jdbc driver postgresql-8.1-407.jdbc3.jar
Reporter: Marius Kotsbak
This exception appears on high load (stress testing) of a product on JBoss 4.0.4:
2006-12-04 17:46:06,732 ERROR [org.jboss.ejb.plugins.LogInterceptor] EJBException in method: public abstract no.boostcom.sms
fusion.beans.RecurringDataLocal no.boostcom.smsfusion.beans.InboxLocal.getRecurringData(), causedBy:
org.postgresql.util.PSQLException: Bad value for type timestamp : active
at org.postgresql.jdbc2.TimestampUtils.loadCalendar(TimestampUtils.java:232)
at org.postgresql.jdbc2.TimestampUtils.toTimestamp(TimestampUtils.java:307)
at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getTimestamp(AbstractJdbc2ResultSet.java:419)
at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getTimestamp(AbstractJdbc2ResultSet.java:2088)
at org.jboss.resource.adapter.jdbc.WrappedResultSet.getTimestamp(WrappedResultSet.java:943)
at org.jboss.ejb.plugins.cmp.jdbc.JDBCResultSetReader$12.readResult(JDBCResultSetReader.java:255)
at org.jboss.ejb.plugins.cmp.jdbc.JDBCResultSetReader$AbstractResultSetReader.get(JDBCResultSetReader.java:500)
at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgumentResults(JDBCAbstractCMPFieldBridge.j
ava:482)
at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgumentResults(JDBCAbstractCMPFieldBridge.j
ava:432)
at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadInstanceResults(JDBCAbstractCMPFieldBridge.j
ava:393)
at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:207)
at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:88)
at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:646)
at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:628)
at org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPersistenceManager.java:406)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.loadEntity(CachedConnectionInterceptor.java:252)
at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:243)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
at org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentranceInterceptor.java:126)
at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:276)
at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:104)
at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:68)
at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:378)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136)
at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:520)
at org.jboss.ejb.Container.invoke(Container.java:954)
at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:430)
The value "active" is valid for another column in the same entity bean than the timestamp column JBoss is trying to use it on.
We see other similar stacktraces:
2006-12-04 17:46:12,884 ERROR [org.jboss.ejb.plugins.LogInterceptor] TransactionRolledbackLocalException in method: public a
bstract boolean no.boostcom.smsfusion.smsfusionReceiverBeans.MtextHelperLocal.storeSMS(no.polardesign.boostcom.sms.SMSInnMel
ding,no.boostcom.smsfusion.beans.InboxVO) throws javax.ejb.ObjectNotFoundException,javax.naming.NamingException,javax.ejb.Fi
nderException,javax.ejb.CreateException, causedBy:
org.postgresql.util.PSQLException: Bad value for type timestamp : WAP Ordbok
at org.postgresql.jdbc2.TimestampUtils.loadCalendar(TimestampUtils.java:232)
Here another column is exchanged with the timestamp column.
Removing the CMRs between all related CMP beans (which also removes locking) seems to remove this problem, but that can result in much work. Get-fields in the entity beans are set to read only to reduce locking.
The same code worked fine on JBoss 3.2.5 using the same stress tests. It is also working on JBoss 4.0.4 during single accesses (not multitasking).
--
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-386) RequestCorrelator thread safety issue
by Bela Ban (JIRA)
RequestCorrelator thread safety issue
-------------------------------------
Key: JGRP-386
URL: http://jira.jboss.com/jira/browse/JGRP-386
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.4.1
[Dave Oxley]
We have had a deadlock issue with JGroups. The same issue affects 2.2.8 and 2.4.0. The call_stack in blocks.RequestCorrelator is a class variable and is set when a message is processed in util.Scheduler with deadlock_detection set to true. However if multiple threads call sendRequest in blocks.RequestCorrelator then they pick up the call_stack that may not be relevant to that request. This is most evident when concurrent_processing is also set to true as the call_stack grows permanently. The attached patch (against the 2.4 branch) makes call_stack a ThreadLocal and is set by the util.ReusableThread used to process the request. I've also changed the setConcurrentProcessing methods so that they work after the various objects have already been constructed.
--
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: (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