February 2007 - jboss-jira - Jboss List Archives

[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

4
9
0 / 0

[JBoss JIRA] Created: (JBFORUMS-170) Change TopicView

by Ryszard Kozmik (JIRA)

Change TopicView ---------------- Key: JBFORUMS-170 URL: http://jira.jboss.com/jira/browse/JBFORUMS-170 Project: JBoss Forums Issue Type: Sub-task Components: Forum View Layer Reporter: Ryszard Kozmik Assigned To: Ryszard Kozmik Fix For: 1.0.1 RC Change L&F of TopicView to new one. -- 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

1
1
0 / 0

[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

3
10
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1149) Tag header doesn't work

by Vera Mickael (JIRA)

Tag header doesn't work ----------------------- Key: JBPORTAL-1149 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1149 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.4 Final Reporter: Vera Mickael The tag header doesn't work. I started a thread in jbossportal forum but I didn't have many answers, the descritption of the issue can be found at this URL : http://jboss.org/index.html?module=bb&op=viewtopic&t=93920 The jbossportal documentation par 12.6.1 describes the way to inject header content : http://docs.jboss.com/jbportal/v2.4/reference-guide/en/html/themeandlayou... In the example we can see that a property name is used : HEADER_CONTENT But in the whole jboss portal code, this property isn't used. This makes me think that there is a mistake. In my forum thread I give a solution to make the work. Regards, Mickaël -- 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

3
3
0 / 0

[JBoss JIRA] Created: (JBRULES-629) SuggestionCompletionEngine to be populated from rule object model classes

by Michael Neale (JIRA)

SuggestionCompletionEngine to be populated from rule object model classes -------------------------------------------------------------------------- Key: JBRULES-629 URL: http://jira.jboss.com/jira/browse/JBRULES-629 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale -- 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

3
9
0 / 0

[JBoss JIRA] Created: (JBBUILD-340) Create maven plugin to deploy artifacts to the non-maven jboss repository.

by Paul Gier (JIRA)

Create maven plugin to deploy artifacts to the non-maven jboss repository. -------------------------------------------------------------------------- Key: JBBUILD-340 URL: http://jira.jboss.com/jira/browse/JBBUILD-340 Project: JBoss Build System Issue Type: Feature Request Components: Maven Reporter: Paul Gier Assigned To: Paul Gier Fix For: MavenBuild 1.2 Create a maven plugin that will bind to the deploy phase to deploy to the jboss repository. When a developer is ready to deploy a project, the required artifacts should be deployed to both the maven2 repository, and the non-maven repository. -- 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

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-4113) jbossweb 2.0.0

by Scott M Stark (JIRA)

jbossweb 2.0.0 -------------- Key: JBAS-4113 URL: http://jira.jboss.com/jira/browse/JBAS-4113 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Web (Tomcat) service Reporter: Scott M Stark Assigned To: Remy Maucherat Fix For: JBossAS-5.0.0.Beta2 We need a release of the jbossweb 2.0.x to replace the 2.0.0.snapshot. -- 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

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-353) Interoperability between micro versions

by Bela Ban (JIRA)

Interoperability between micro versions --------------------------------------- Key: JGRP-353 URL: http://jira.jboss.com/jira/browse/JGRP-353 Project: JGroups Issue Type: Feature Request Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.5 Micro versions and service packs, like 2.4.1 AND 2.4.2 should work together in the same cluster. SOLUTION: add isCompatible(short) to Version, so we can actually accept packets from a 2.4.2 node in a 2.4.1 node. Needs to be configurable though -- 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

3
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-844) We need a optimistic locking version of TreeCacheProviderHook

by Galder Zamarreno (JIRA)

We need a optimistic locking version of TreeCacheProviderHook ------------------------------------------------------------- Key: EJBTHREE-844 URL: http://jira.jboss.com/jira/browse/EJBTHREE-844 Project: EJB 3.0 Issue Type: Bug Components: Clustering Affects Versions: EJB 3.0 RC9 - Patch 1, EJB 3.0 RC9 - FD Reporter: Galder Zamarreno Assigned To: Galder Zamarreno Attachments: OptimisticTreeCacheProviderHook.java Currently, EJB3/Hibernate cannot take advantage of using a second level cache based in optimistic locking in a EJB3 environment. We only have a TreeCacheProviderHook CacheProvider for pessimistic locking which means that if a customer wants to set up optimistic locking, it's forced to use OptimisticTreeCacheProvider. However, this class was not designed for managed environments and ends up creating another cache, so you end up with two caches for the same job in the same instance which is wrong. I have created a OptimisticTreeCacheProviderHook which creates an org.hibernate.cache.OptimisticTreeCache based on the TreeCacheMBean instance looked up. Please find attached. This could be improved by creating a accessor method for TreeCacheProviderHook.cache, so that I can directly extend it rather than reimplementing CacheProvider. But, I have gone followed the CacheProvider implementation path so that I can quickly pass a patched jar containing this class only to the customer for them to try. -- 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

4
12
0 / 0

[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

2
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 February 2007