October 2006 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: VirtualFile.toURL() returning vfsfile:

by scott.stark＠jboss.org

Can we extract the zip decompression code from truezip to create our own JarFile easily? In terms of the URL issues, our long term view has been to write our own class loader to get away from the jdk implementation details. Running efficiently in any jdk means dealing with their implementation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980867#3980867 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980867

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Server side HA and failover

by clebert.suconic＠jboss.com

I have *tried* to drive fail over from client side. Last week I could make a state transfer from one node to another, moving all the messages from a failed queue to a new queue. There are implications of doing this way as we will could have more than one Local Queues when a failover occurs. Say if you have two nodes A and B, each node with a client and a durable subscription on that client. Now say if node A fails. Now the clients from node A will be redirect into node B, and Routers will have to treat B's connections as they were still on nodeA but now they are local on node B. Also any producer existent on NodeA will come to nodeB having preferences to send messages to the former NodeA. These are all implications of the Partial Queue implementation existent in our cluster. I'm at this point looking at the code on how we could deal with this. --Clebert View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980866#3980866 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980866

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by clebert.suconic＠jboss.com

Ovidiu wrote : | Let's systematize a bit the cases we need to deal with on fail-over. | | ...... | | Again, for all these cases we should have tests. | I havent thought much about retries and stuff like that. I agree we should create test for these scenarios. At this point I'm concentrating in transfer state from one connection to another in conjunction with server side failover. I will start treating connection events problems after I have finished this state transfer. Ovidiu wrote : | This will help us avoid situation when a "failed-over" message is consumed on the client-side, the consumer delegate sends the acknowledgment and the new server consumer endpoint doesn't know what the client is talking about, because there's no active delivery for that message. I think we can go a step further and also send the IDs of non-persistent messages that have been "failed-over" on the client side. This way, the client will continue to receive (and successfully acknowledge) non-persistent messages that otherwise would have been lost. | Let me make some progress with the server side failover, then we will decide what to do with these IDs. We should do it next week. Ovidiu wrote : | We need to make sure that the "new" connection is then properly discarded so it will eventually garbage collected. Minor thing, anyway, just an observation. | agreed. Ovidiu wrote : | Clebert wrote : | | Creating a new connection on the new server will create a new server Object, consequently a new ServerId. | | | | You probably want to say that creating a new connection will subsequently create a new server-side connection endpoint instance, and because we're connecting to a different server node, we need to use its serverID instead of the "dead node" serverID, right? | Yep... I have recently tried to improved my terminology. That was sent before your request ;-) Ovidiu wrote : | What about the "fail-over protocol"? Your statement above seem to assume that the new server node is called into without any "preparation", as would a completely new client that creates a new connection, session and consumer endpoints. This is not going to work, those server-side objects need to undergo a "post-failover" preparation phase, where deliveries for the client-side failed over messages are created and so forth. | I'm working on the preparation/failover protocol right now. I'm trying to drive it from the client as the first connection fails to a node appears. "Ovidiu" wrote : | At this point, given the way Remoting discussion evolve, we can safely assume we'll use Remoting connection failure facilities to detect our connection failure. | "Ovidiu" wrote : | I have started a list of scenarios at the beginning of this post. The way should be deal with this situation is to create test cases for each of use cases we are going to support. This way we make sure that if we refactor the code later, it still behaves how we originally wanted it to. No new functionality should ideally be added if there is no test case for it. | Yep! I will let Tim comment on the list. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980863#3980863 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980863

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: VirtualFile.toURL() returning vfsfile:

by bill.burke＠jboss.com

also, for truezip we would have to really reengineer and dive into their codebase to layer the VFS on top of it. Currently, MOST of it is married to java.io.File implementations and not URL based. Their nested jar support extracts jars into temporary files. None of it that I saw allows you to provide a InputStream or URL as the implementation is based fully based on RandomAccessFiles. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980861#3980861 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980861

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: VirtualFile.toURL() returning vfsfile:

by bill.burke＠jboss.com

I'm not sure truezip is the answer. From what I've seen, they have only wrapped java.io stuff to make it threadsafe. BTW, this wasn't limited to JarFile problems. Also had problems with regular FileHanders being read through the vfsfile:/ URL indirection. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980858#3980858 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980858

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: VirtualFile.toURL() returning vfsfile:

by bill.burke＠jboss.com

I can only get it to work by doing both the useCaches(false) and pre-reading the stream into a BAIS. But it boots twice as slow as normal. I have to do this trick for FileHandlers, JarHandlers, and JarEntry handlers. I'm really nervous that basing everything on a VFS URL will not work with other VMs. There's all this funky shit caching going on behind the scenes that I can only get a glimpse at by decompiing Sun specific JDK code. Some of the problems are hidden within native methods as well. I got all this to work so far by guessing... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980856#3980856 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980856

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Table object_snap uses Oracle keyword UID

by daniel.brum＠jboss.com

Hmm I better fix this one now... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980852#3980852 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980852

19 years, 5 months

1
0
0 / 0

[Design of JBoss Eclipse IDE (dev)] - Re: JBoss5 integration

by mculpepper＠jboss.com

AFAICT Webtools doesn't and won't have JSR88 support until someone brings something to the table. We had initially tried giving our old JSR88 tools (that Rob wrote when he was a co-op) to Eclipse as an initial contribution, with "someone else" taking on the responsibility after that... but no one stepped up to the plate. It's a weird landscape .. it seems all the major vendors are "interested in having JSR88 tools" yet no one wants to pony up the resources. My guess is this won't change in Webtools 2.0. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980850#3980850 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980850

19 years, 5 months

1
0
0 / 0

[Design of JBoss Eclipse IDE (dev)] - Re: JBoss5 integration

by rob.stryker＠jboss.com

The only thing even mentioning such a thing that I've seen is some article somewhere with a completely unsubstantiated claim that webtools supports JSR-88 for "at least one major J2EE vendor", but there was absolutely no further details given and no demonstration of even a UI for such a thing. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980847#3980847 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980847

19 years, 5 months

1
0
0 / 0

[Design of JBoss Eclipse IDE (dev)] - Re: JBoss5 integration

by max.andersen＠jboss.com

ok - regarding JSR-88 i haven't seen that in context of WTP ....marshall/rob - have you ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980835#3980835 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980835

19 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2006